Home > Encryption, Privacy > STARTTLS for SMTP


Okay, I don’t really mean to advocate this as a privacy solution because it is and it isn’t.  If you truly want privacy of your email you must use end-to-end encryption like PGP/GnuPG or S/MIME.  That said, I think it’s good to encrypt things, even ciphertext, over the network.  So STARTTLS for SMTP is a good start.

What, exactly, is STARTTLS?  Well, it’s an opportunistic protocol that goes out and asks a server in which I want to talk with if it supports encryption.  If it does then we negotiate the terms (ciphers, keys, certs) and then we establish a circuit and exchange the information.  If it doesn’t support encryption I just skip the setup of the encrypted circuit and transmit the data in the clear.  Yeah, not a great solution and I really hate the thought of STARTTLS as it isn’t a guarantee that the data transferred will be encrypted (unlike, say, HTTPS).

Earlier today Kurt pointed me at a study done by Facebook.  Yeah, everyone knows I hate FB but really they are in a great position to do such a study.  According to their study, “Facebook sends several billion emails to several million domains every day”.  Okay, that’s a lot of email.  And with that amount of exposure to the worlds’ SMTP servers I’m guessing they’ve hit most of the servers out there.  Turns out 76% of those servers support STARTTLS and most actually use a good cipher suite and PFS.  Unfortunately it appears that most mail is routed to providers that aren’t supporting good crypto suites.  The report doesn’t name them so I figured I’d go out and see if I could find some of the deficient setups.

The obvious first choice was Google’s Gmail.  As long as the incoming server connects to port 465 587* they should get an encrypted circuit supporting TLSv1.2 protocol with a cipher of ECDHE-RSA-AES128-GCM-SHA256.  Great, I have no complaints here.  Hmmm, so who is next?  I guess Hotmail is still a biggie and Microsoft does have all those B2B services as well.  It seems TLSv1.2 with a cipher of ECDHE-RSA-AES256-SHA384 is being used on at least some of their SMTP servers.  What’s next?  Ahh, yes, Yahoo! is still in business (although I seriously don’t know how).  Yahoo! just implemented encrypted connections for their webmail users so clearly they should have fixed their backend connections as well, correct?  Well, they are the first to make my bad list by using the TLSv1 protocol with the cipher of RC4-SHA.  Come on guys, get it together!  Let me see what my provider, Bluehost, is doing here.  It appears that, like Google, they support TLSv1.2 and are using the cipher of DHE-RSA-AES256-GCM-SHA384.  Again, a great choice (although the AES256 is a bit much but that’s a different post all together).

I might, one day, setup a scanner to more thoroughly collect this data and make it available in more real-time but for now I think the Facebook data is awesome and quite timely.


*As was pointed out in the comments port 587 is a user port and is used for authenticated SMTP access from clients.  Once the SMTP server has the message to be delivered the server will connect over to the distant SMTP server over port 25 unauthenticated.  Port 25 can be just plaintext or can use STARTTLS.  As an aside, why port 25 outbound (and inbound?) is blocked for many residential customers is because it is unauthenticated and a present a good entry point for spam.

Categories: Encryption, Privacy Tags: , , ,
  1. 2014-05-15 at 10:29 EDT

    Reblogged this on oogenhand.

  2. 2014-05-15 at 15:35 EDT

    Uhm, your article’s title and what you’re actually looking at don’t really match. You’re referring to STARTTLS (which is used to *upgrade* a connection to TLS) but then you refer to port 465 (which is SMTPS and deprecated by the specs).

    • 2014-05-15 at 16:01 EDT

      Thanks for the catch. This is what I get for writing past my bedtime. Fixed.

  3. Aaron
    2014-05-15 at 18:01 EDT

    Your discussion of what Facebook sees when delivering email makes it sound like you’re talking about transport of mail from one server to another. But then you talk about connecting to port 587 which should never be used for that, and if the receiving server is configured correctly that port won’t work for that type of client. The appropriate port for that would be 25.

    Port 587 is for message submission from user agents, and it should always require some type of authentication of the client which isn’t going to work for another mail server. The authentication step is one of the reasons that STARTTLS is especially important for this port. It’s also good to have encryption of the content for this step, since many user agents often connect from open wifi networks where network sniffing is especially easy.

    Mail server to mail server connections, which are handled by port 25, would generally be over networks that are at least somewhat more secure and will not use authentication information; so those may be seen by some people as less important to enable STARTTLS.

    • 2014-05-15 at 19:45 EDT

      Yes, I’m discussing what I’m testing basically because Comcast blocks port 25. I’m making the assumption that the crypto would be similarly setup but perhaps I should rework that particular section of my post and do some additional testing. That said, I’m not sure why you think that information passing to port 25 is magically passed over a more secure network. It still being passed across the Internet and you aren’t avoiding any insecure spots simply by using port 25.

      • Aaron
        2014-05-15 at 20:35 EDT

        It’s actually not only the ports that would be different, for large mail providers it’s also likely different machines handling port 25 versus 587 and could even be completely different SMTP server software since these roles are vastly different. So the crypto setup could also be much different.

        I know that using port 25 rather than 587 wouldn’t make any difference in the amount of security. But, I still think that using a laptop or mobile device on some possibly unknown WIFI network will be less secure than the connections between most mail servers. Although I certainly wouldn’t consider those server to server connections to be particularly secure either.

      • 2014-05-15 at 21:51 EDT

        Oh I’m sure that many email providers have many servers. I’m suggesting that there will likely be some common configurations between all servers.

        I don’t worry so much about that WiFi network as I prefer to think about that core router as the perfect place to abscond with traffic. That said, I believe everything should be encrypted when it goes across a network whether it’s the first hop or the server-to-server hop. I also prefer to use end-to-end encryption as you can’t trust a STARTTLS circuit for protection.

  4. 2014-05-19 at 06:56 EDT

    So how a mailserver verifies the validity of a certificate? On http(s) broswsers do that using CAs. Do email systems (eg. Postfix) have a similar mechanism?

    • 2014-05-19 at 21:56 EDT

      Yes, SMTP servers (and really any system that uses certificates for encryption) should attempt to validate the certificate. The circuit should fail if the certificate comes back belonging to the wrong domain or is expired or is revoked (your systems are checking the OCSP databases, riiiigggghhhtttt?). If the software isn’t doing these checks report it upstream. This is a security vulnerability and may warrant a CVE.

    • Aaron
      2014-05-20 at 17:06 EDT

      That’s one option. Another option, which unfortunately isn’t very well supported yet, is to verify the certificate information through DNSSEC using DANE http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities .

      This has a couple of advantages over using a CA. First, there’s no need to spend money to get a certificate, so it can be an easier sell. Secondly, it can be more secure, since with CAs and attacker only needs to con, coerce or crack one of the large number of CAs which are generally trusted; with DANE the attack points are all ones that can be chosen by the owner of the domain.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s