Well deployed encrypted email transport techniques are a very important component of the Email Security landscape.
Participants in industries with strong privacy requirements are prime candidates to implement — and enforce — email security protocols.
As most current protocol implementations, encrypted email transmissions are built on top of Transport Layer Security (TLS). This is the same protocol used by your browser to read this post and when properly configured and implemented, ensures that the content you’re reading — or the email you’re receiving — was not tampered with or observed in transit.
Most mail server software used today is capable of using TLS to transmit email. In its current form, SMTP STARTTLS technically defined by RFC-3207 provides a way for a receiving Mail Transfer Agent to advertise the willingness and availability of TLS to the sending MTA, which in turn may choose to initiate a TLS session to protect the email transmission.
For most email senders, enabling STARTTLS is a simple decision with little cost. Large freemail providers including Google, Microsoft and OATH support STARTTLS so from the start, a significant fraction of the total email flow can be encrypted pretty quickly. Indeed, to cite but a source, recent Google Transparency Report data show more than 90% of email being consistently encrypted while in transit.
What is the risk?
STARTTLS suffers from an interesting weakness though. Since the initial stages of the protocol are not encrypted, an attacker placed between client and server could thinker with the traffic. It could simply modify the server’s response to remove the announcement of STARTTLS availability, which would then cause the sender to skip this step and just send the email without encryption, allowing the intruder to covertly read the email while in transit. This scenario is the textbook definition of a man in the middle attack (MITM).
Since for all parties concerned a successful MITM attack results in email being delivered with no signs to the contrary — that is, the security mechanism fails open — this situation
Security conscious senders can configure their MTAs to refuse email transmission without STARTTLS. But using Google’s numbers from before, this would render more or less a 10% of total email traffic as undeliverable. The same would apply to receivers refusing email sent without the protection of TLS. This might be acceptable for some scenarios, but the approach has plenty of caveats and isn’t for everybody.
The sweet spot seems to be for receivers to signal the availability and desire — this is commonly referred to as a policy — to receive email via TLS, in a way that renders MITM attacks impractical. Aware senders could then use that signal to enforce the delivery policy and loudly complain when something interferes with the policy, such as when a nefarious actor attempts to block TLS.
What to do as a sender?
By all means, make sure your MTAs use STARTTLS whenever available. If your mailing lists depend on an Email Service Provider, make sure they support STARTTLS. This is the very first, basic step you can take. While you’re at it, make sure that all MTAs processing your email have valid TLS certificates, issued by a recognized CA. Self signed or Snakeoil certificates cannot be verified and add nothing to your credibility. At least until TLSA (RFC-6698) is widely supported.
TLS certificates are cheap and thanks to Let’s Encrypt, free even. Obtaining them and configuring them in your MTAs should be easy. And solutions such as our Managed Email Tunnel will automatically generate and maintain TLS certificates automatically.
What to do as a receiver?
Again, make sure all your MX hosts support STARTTLS. This ensures that any sender with the capability can start sending encrypted email right away.
Your next step is consider deploying TLSA (RFC-6698) — this requires DNSSEC — or MTA-STS (RFC-8461). These protocols, which we’ll discuss in later posts, provide a standardized way to signal your senders about your policy of making STARTTLS mandatory.
Future direction
Please keep an eye on this space as we’ll be adding further posts about the topics discussed here.