SendGrid and the Future of Email Security

UPDATED: 5 June 2014, 16:00 MDT to reflect Hotmail’s new TLS support!

Here at SendGrid, we get a lot of questions about email security. Recent revelations about widespread nation state dragnet surveillance have raised awareness about email security to new levels.

We are excited to announce, that effective today, all email sent via SendGrid will utilize opportunistic encryption using TLS. For a long time now we have supported encryption for submitting messages to SendGrid, either via our HTTPS API, implicit SMTP-SSL, or SMTP with STARTTLS. Now when we deliver your message to its recipient we will attempt to negotiate a TLS connection with the recipient’s mail server.

This means that so long as your recipients’ mail servers are configured to properly support TLS, it will be impossible [1] for a passive adversary along the route to intercept and/or modify the message.

So, which recipient mailbox providers properly support TLS?

 

AOL, Gmail and Hotmail are the mainstream mailbox providers that correctly and comprehensively implement TLS for mail sent to their users.

Yahoo’s case is a bit more nuanced. Yahoo does support TLS, but they are incorrectly presenting a wildcard certificate for *.yahoodns.net, which per RFC-2818 is valid for am0.yahoodns.net, but not mta5.am0.yahoodns.net. We have reached out to Yahoo about this problem and they are working on a fix.

Testing and Results

So that covers the big four mailbox providers, but what about the rest of the mail exchangers on the Internet? Well, at SendGrid, deliverability is so important to us that we wanted to do extensive testing before enabling TLS on our outbound mail flow. Our Co-founder and CTO, Tim Jenkins, performed some exhaustive testing about TLS capabilities for over 8M recipient domains that we have sent email to over the past month.

What Tim found is astonishing…

The weekend of May 10th, 2014, we attempted SMTP connection to the mail exchangers for roughly 8 million domains that we regularly deliver email to.

Those 8 million domains presented 3.4 million unique mail exchangers, 2,614,380 (76.1%) of which claimed to support TLS.  We attempted to connect to all of them, and failed to successfully negotiate a trusted TLS connection with 223,800 of them (8.5%).

Digging deeper into the failure cases, we found that:

• 145,951 (65.2%) of the hosts failed due to a CN name mismatch
• 50,293 (22.5%) of the hosts failed due to being signed by an unknown authority
• 19,755 (8.8%) of the hosts presented expired certificates
• 4628 (2.0%) of the hosts had connection problems.
• 1280 (0.5%) of the hosts presented certificates with negative serial numbers.

As a consequence of these findings, we have made the decision to implement Opportunistic Encryption, which means that we will attempt to negotiate a TLS connection to the destination mail server. If that’s not possible, we will fall back to an unencrypted connection.

We have also notified the postmasters of the recipient mail servers that aren’t correctly configured to support TLS so that they can remediate their systems.

 

Up next: Opportunistic Crypto not good enough? Check out a follow-up series on how to configure end to end email encryption (for free!) on your laptop, phone and tablet here on the blog next week.

——————————————————————————————————————————————–

[1] Unless the adversary is able to present a trusted certificate for the recipient mail exchanger.