Back in June, SendGrid joined a large group of Internet companies in the effort to prevent dragnet surveillance of customer traffic. On our part this specifically involved adding opportunistic TLS—encrypting traffic to any mail server that supports it.
While this does move us closer to the goal of complete customer privacy, there are some caveats that aren’t often talked about. Opportunistic TLS does provide better privacy than sending everything cleartext, but it does not provide any protection against an attacker attempting to hijack traffic to a specific domain. All an attacker needs to do is take over the domain, not advertise TLS capabilities, capture, and then proxy the data back to the real mail server, and no one would be the wiser.
In order to truly guarantee email privacy, Enforced TLS would have to be required for all connections. This of course means that email to servers that do not support TLS would have to go undelivered. Since this is not a choice SendGrid can make for our customers, opportunistic TLS is the best that we can provide by default.
That being said, we are happy to announce that SendGrid now allows customers to create a TLS policy, which will allow you to make that choice. If you feel that privacy is of greater concern than delivering email to domains that don’t have that option, go for it. The good news is that 92% of SendGrid traffic is sent over TLS, with more mail servers starting to allow encryption, so this is not the same level of loss that it would have been five months ago.
While simply requiring a TLS connection improves the security of your email sent from end to end, there is another flaw in opportunistic TLS: the handling of certificate errors. Roughly 3% of those messages sent over TLS are sent to a server that has some kind of problem with their SSL certificate. This can range from them having a self-signed cert, to them having one that is expired. While browsers deal with this by asking you if you want to continue anyway, there is no way for us to do that. We default to accepting the certificate and encrypting the email anyway, the logic being that it is still more secure to accept the certificate then it would be to fall back to plain text.
Fortunately, SendGrid now also allows you to control this behavior. It is now possible to require a valid certificate, and if so, then the email will be deferred when a bad certificate is presented. This option only has real meaning when combined with requiring TLS, as an attacker could still just not advertise TLS capabilities and bypass the certificate completely.
Currently you can only activate this feature through our WebAPI v3. In order to get your current TLS setting you can make a GET request to the following (remember that all SendGrid users have Opportunistic TLS activated without having to do anything):
In order to activate Enforced TLS you must make the following API call:
Header: “Content-Type: application/json”
Setting these items to true, will enable the ability to only send these emails if the recipient email service provider accepts a TLS connection and has a valid TLS certificate. If one or both of these parameters is false we will drop the mail and send a block event indicating the following:
500 TLS required but not supported
To get more info please visit our documentation page.
With these two features combined you can ensure that email is not being intercepted by an untrusted third party. We log explicitly when email is either dropped or deferred for these reasons, and by either consuming the Event API or looking in the Email Activity section of our website you can see which servers aren’t getting with the program.
As an interesting note, while doing research on the impact to customers who would enable this feature, we examined our log data to identify the largest email servers that do not support TLS and the results were pretty surprising. A number of the big Japanese and European mail receivers made the list, as well as many of the home ISPs here in the US. We’ll be working to make this information available to our customers, and to the Internet as a whole, so that change can begin to happen. Our hope is that we, as the Internet community, will start to demand that companies take steps to ensure our privacy.