Email security has been around forever, you just need to turn it on

Email security has been around forever, you just need to turn it on

Summary: This information is also available as a TechRepublic download.As much as I respect my colleague and mentor David Berlind who taught me the news business, I have to say that he's got it all wrong when it comes to Internet mail security.


This information is also available as a TechRepublic download.

As much as I respect my colleague and mentor David Berlind who taught me the news business, I have to say that he's got it all wrong when it comes to Internet mail security. Berlind is reeling over his incorrect perception that the Internet still lacks secure email. The problem is that he's got it all wrong and the solution has been under his nose all this time and it really isn't the non-interoperable nightmare he paints it to be. Secure connections between Server to Client, end to end, and Server to Server communications have all been around for a long time. The technology is already baked in to existing software and it's simply a matter of installing, configuring, or merely enabling the technology. [Update 7/26/2007 - Berlind follows up here. I respond here. Awesome and informative response from Ani Shrotri]

Server to Client encryption is a check mark away: The most likely way to get eavesdropped on is in the last 100 feet whether that's through a wire (through layer 2 hijacking) or wireless LAN connection. To enable Server to Client encryption, you simply check a simple option to enable SSL and type a different port number for your POP3 (inbound) and SMTP (outbound) Mail Server settings in your email client. My current DSL provider AT&T like most ISPs supports SSL encryption on POP3 and SMTP and it's as simple as a checkmark and using ports 995 for POP3 and 465 for SMTP instead of the usual ports 110 and 25. The problem is that AT&T doesn't disable unencrypted mode which means the vast majority of users won't use the secure transport mode. Secure POP3 and SMTP email with SSL

If you happen to be a Gmail kind of guy or gal, simply typing in (not http://) and your entire authentication and web mail session is encrypted with export-restricted grade SSL encryption. The problem with Google (similar to AT&T not disabling regular POP3 and SMTP) is that they don't disable http mode which means 99% of the population will continue using unencrypted http mode. Hotmail doesn't support payload encryption so Hotmail users out of luck (are you listening Microsoft?).

End to End email cryptography: End to end cryptography which encompasses authentication, non-repudiation, and encryption has been baked in to every email client in the form of S/MIME for a decade with push button simplicity and full interoperability. In fact an email client without S/MIME support is like a web browser that doesn't support HTTPS SSL mode. All you need to do is obtain a FREE Personal Digital Certificate from a Certificate Authority like Thawte through a web enrollment process. In that enrollment process, you get to generate your own Public and Private Key pair and Thawte will digitally sign your Public Key after and email round trip where you demonstrate control and possession of your email account.

Once you've obtained that Certificate, you can digitally sign any email and everyone in the whole world using an email client less than a decade old will be able to read and trust that digital signature to have truly come from the purported "from" email address. The other side doesn't even need their own Digital Certificates to read your signatures. This is the "authentication" component.

Note that I said they can trust that it came from the purported email address and I didn't say the digital signature proves the message came from you. If you want to prove it came from you, you're going to have to go to the WOT (Web Of Trust) and get someone acting as a Thawte Notary to bind your identity to your email address and Digital Certificate. With your identity bound to your email and Digital Certificate, you now have non-repudiation and your signed emails can be treated as contracts under the eyes of the law. Non-repudiation means that when you send out a message with your digital signature bound to your email and identity, you cannot claim anyone else falsified that message because only the owner of your private key could have generated that digital signature.

To enable encryption, both sides must have their own Digital Certificate which also means both sides can digitally sign. Once the Digital Certificates are installed on each end, you simply need to click the "encrypt" button built in to your email client. The beauty of this encryption scheme is that it doesn't care if the network and server infrastructure in the middle is trusted or not because only the end points can decrypt the messages. This however does not negate the need for Server to Client encryption because we don't want someone else to be able to take over the email account on either end even if they can't read the encrypted messages.

S/MIME is so universal that even companies like PGP Corporation which offer solutions that manage an Enterprise's cryptography infrastructure will support technologies like S/MIME in addition to PGP and GPG. PGP and GPG are alternatives to S/MIME but the technology isn't baked in every email client and must be installed as an add-on.

Server to Server cryptography: Sniffing traffic between two SMTP servers is REALLY difficult to pull off unless you have access to the ISP's (Internet Service Provider) infrastructure, or you've hacked in to a server on one end, or you've hacked a router or firewall between the company and the ISP. In fact if you could hijack someone's email server, you can actually steal their domain name or obtain SSL certificates on behalf of the actual owner. But we can mitigate these types of attacks by enabling Server to Server encryption even if a hacker manages to place themselves between your server and the Internet. Enabling Server to Server encryption is actually quite simple and requires nothing more than enabling SSL or TLS on the SMTP server and obtaining a $20 publicly trusted digital certificate on each server (tutorial on obtaining Digital Certificates). Unfortunately, not all companies and organizations have enabled Server to Server SSL or TLS communications but the technology is already there and the price of obtaining Digital Certificates has dropped to almost nothing.

The bottom line is that there is a lesson here for any individual or mail administrator who wants secure email. The technology is already baked, it often costs little or nothing to set it up and you just have to be willing to turn it on.

Topics: Servers, Collaboration

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • IMAP secure port number?

    What is the IMAP secure port number?
    • Could be something like 993, but it's deployment specific

      Sometimes it's 993. This is admin configurable.

      Here is one example:
      Problem is that these guys are using a non-trusted Digital Certificate which means users get in the habbit of trusting anonymous certs that any hacker can generate. This is why I tell people to at least go out and buy one of those $20 GoDaddy certs.
      • It's 993

        All ports are admin configurable. In all the services files I've ever read, imaps is defaulted to 993.
    • Port 993

      The original IMAP specification used port 993 for SSL transport, but this has since been deprecated. Modern IMAP implementations will use port 143 for all traffic, with the client specifying whether or not to use encryption during the negotiation with the server. In practice, many servers will still respond on port 993, but this may not be supported indefinitely.
    • Don't even need "real" certificates

      I sign my X.509 certificates using my own CA-in-a-box. Other mail servers are
      happy to use TLS connection with these self-managed certificates - I think the
      hardest part is just enabling TLS and making sure your mail server will attempt to
      use TLS before other mechanisms.

      I've done my bit, now it's up to the thousands of ISPs out there to configure their
      mail servers to handle TLS connections! Of course, nothing beats actually
      encrypting the message being sent, but at least I can rest comfortably at night
      knowing that my mail server will do its best to help keep my users' email safe from
      prying eyes.
  • Gmail is impressive

    For a web based email client, Gmail is impressive. Though I agree that http:// should be shut off. Even though I am re-routed to a secure connection unlike with Hotmail, I still feel that gmail could bump up the standards just a bit more.
  • George, that's irrelevant

    You've just proven David's point.

    The fact that *anything* has to be done to generate a secure email proves that it doesn't exist (in practical terms).

    I'll go further. It's not possible for it to exist, since there's no practical way to get everyone a non-repudiable (is that a word? :) ) digital signature--and even IF you could do that it's a dangerous thing to do in general because of the possibility of bad guys obtaining private keys, through hook or crook.
    • David's point is that it's not simple or interoperable, he's wrong about th

      David's point is that it's not simple or interoperable, he's wrong about that. Client to server SSL is as simple as turning it on for the user. If you can't even do that even after I've told you to do that, you deserve what you get.

      FYI, you don't get a "digital signature", you get a "digital certificate" which lets you create digital signatures.
      • I stand corrected...

        But getting full-blown secure email isn't just checking a box, it requires obtaining a certificate, from a trusted authority, and having someone at that authority somehow verify you are who you say you are.

        I think you mentioned it could be done via email? How much verification is that, really?
        • It only requires a Digital Certificate on the Server end

          It only requires a Digital Certificate on the Server end. The $20 cert from has no less verification than the $200 certficate from Verisign. You get an email sent to the domain administrator (listed in whois for your domain) and only the domain admin can reply to that email to verify. Not anyone in the company can obtain Digital Certificates. I explain this in my SSL Certificate article last week which I link to in the end of this blog.

          The beauty of this approach is that it only requires a cert on the Server end (same for HTTPS SSL) and nothing on the client end.
          • If that's true...

            then certificates (which can be generated in seconds?) are a massive rip off. $20 or $200, how can Verisign justify charging 10x the amount for the exact same service?

            And if *that's* true, why can GoDaddy justify $20?

            George, this is yet another reason the current "secure email" situation will never be universal. Without universal adoption, you do not have interoperability. If I (as Joe Smith, computer user) receive a digitially signed email, and have used the default settings out of the box on my mail client, how can I be sure the signature is genuine?

            Also, paying $20 (or $200!!!!) to a third party for a "universal" service smells of fraud, or at least rampant greed.

            No thank you.

            And thus, you see why this approach is not going to work--ever.

            You want universal secure email, every ISP is going to have to provide it--as part of the normal monthly fee.

            Also, what happens to the trust issuers if this becomes universal? Hundreds of *millions* of certificates?

            Hackers will win. Again. And we're back to untrustworthy email...
          • No that's not an IF, that's a fact. Certs were always a massive ripoff

            No that's not an IF, that's a fact. Certs were always a massive rip-off. We're talking about an automated email round-trip verification process and a few automated math operations and all of a sudden they charge you $200 (use to be $700). for example gives away certificates using the same verification process for free though their Root Certificate isn't globally trusted so its usage is limited. GodDaddy also uses the exact same email verification process.

            Read at least of the top of this page and you'll understand why it's a rip-off.
            "If you are under the impression that buying a $200 VeriSign certificate is more secure, understand that any breach of security at the cheaper CA shops mean that all of us are compromised equally since the GoDaddy Root Certificate carries as much weight in our factory installed CTL (Certificate Trust List) as the VeriSign Root Certificate. So ultimately it doesn?t matter where you buy your Digital Certificate from a security standpoint."
  • Sounds complicated. I just use Hushmail.

    Myself and my colleagues use Hushmail now when we need to talk in private. End-to-end encryption, no need to configure servers and port numbers and SSL certificates and what not.
  • Thanks for the Gmail tip...

    Sounds like a no-brainer and a very well-kept secret.

    Chris Dawson
  • Ugh! The Google toolbar doesn't use https for Gmail

    Great Gmail tip, thanks. Was dismayed to discover that the Gmail button on the Google toolbar (for Firefox) doesn't use https. Fortunately I usually use the Gmail Notifier add-on for Firefox to access my Gmail and it does use https (kudos to the author). I also use the Gmail This javascript (that has been widely circulated on the web) to forward pages and noticed it did not use https. Well, mine does now. It was as simple as right clicking on the link, selecting properties, and inserting the s after http in the location field. I'm sure others will want to do likewise.
    • Ouch, that sucks

      At least gmail lets you use https mode instead of http. But I guess they're not perfect.
  • Enable X, get digital cert Y (forget adoption).. proves my point


    As much as I appreciate the kind words, as wolf_z states, you've really just proven my point. You may have picked gmail (which I use), but that implementation is by no means standard amongst POP3 providers (many of which don't support encyrption as an option) not to mention that accessing their Web interfaces is not through HTTPS, but rather unsecure HTTP. As a user of POP3 services, I have zero control over how they configure their server to server communications and have you ever seen how S/MIME messages end up by the time they arrive in certain e-mail clients? It's a friggin' mess.

    But even if it did work as smoothly as you suggest, the fact that a user has to go through all this to get it working is the reason it doesn't work.

    Not to mention the fact that your post doesn't deal with the fact that even if there is a way to digitally sign a document that's been sent to me for my signature (ones that I know must return via fax or snail mail), that businesses simply haven't embraced that approach the way they've embraced e-mail itself. The reason? It isn't easy enough. Ease of use begets adoption.

    Under the current circumstances, the situation will never improve.

    • One other point

      In your headline, you say "YOU" have to turn it on.

      Given that it's so easy, could YOU please turn on Hotmail's payload encryption or show me how to do it?

      Perhaps now you understand what I mean. The Internet's email infrastructure isn't nearly under our personal control as you are suggesting and as long as some number of Internet users don't have the same secure functionality as others, secure e-mail that's as simple as pressing the SEND button, regardless of what system you're on, is a myth.

      • Here's your fix:

        For Hotmail and other providers who don't support TLS/SSL connections: find another provider. If you don't want to give up your old address, forward your mail to a provider that does support SSL/TLS and fetch it from there.
      • I criticized Hotmail for not doing that

        I criticized Hotmail for not doing that. That's why I wrote in bolded text (are you listening Microsoft?). It takes more people like us to shame Microsoft for not doing this. It takes more people like us to shame Google for not disabling regular HTTP mode.