ISPs Removing Their Customers’ Email Encryption

Via EFF.org

Nov. 11, 2014

Recently, Verizon was caught tampering with its customer’s web requests to inject a tracking super-cookie. Another network-tampering threat to user safety has come to light from other providers: email encryption downgrade attacks. In recent months, researchers have reported ISPs in the US and Thailand intercepting their customers’ data to strip a security flag—called STARTTLS—from email traffic. The STARTTLS flag is an essential security and privacy protection used by an email server to request encryption when talking to another server or client.1

By stripping out this flag, these ISPs prevent the email servers from successfully encrypting their conversation, and by default the servers will proceed to send email unencrypted. Some firewalls, including Cisco’s PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.

This type of STARTTLS stripping attack has mostly gone unnoticed because it tends to be applied to residential networks, where it is uncommon to run an email server2. STARTTLS was also relatively uncommon until late 2013, when EFF started rating companies on whether they used it. Since then, many of the biggest email providers implemented STARTTLS to protect their customers. We continue to strongly encourage all providers to implement STARTTLS for both outbound and inbound email. Google’s Safer email transparency report and starttls.info are good resources for checking whether a particular provider does.
Several Standards for Email Encryption

The SMTP protocol, the underpinning of email, was not originally designed with security in mind. But people quickly started using it for everything from shopping lists and love letters to medical advice and investigative reporting, and soon realized their mail needed to be protected from prying eyes. In 1991, Phil Zimmerman implemented PGP, an end-to-end email encryption protocol that is still in use today. Adoption of PGP has been slow because of its highly technical interface and difficult key management. S/MIME, with similar properties as PGP, was developed in 1995. And in 2002, STARTTLS for email was defined by RFC 3207.

While PGP and S/MIME are end-to-end encryption, STARTTLS is server-to-server. That means that the body of an email protected with, e.g. PGP, can only be read by its intended recipient, while email protected with STARTTLS can be read by the owners of the sending server and the recipient server, plus anyone else who hacks or subpoenas access to those servers. However, STARTTLS has three big advantages: First, it protects important metadata (subject lines and To:/From/CC: fields) that PGP and S/MIME do not. Second, mail server operators can implement STARTTLS without requiring users to change their behavior at all. And third, a well-configured email server with STARTTLS can provide Forward Secrecy for emails. The two technologies are entirely compatible and reinforce each other. The most secure and private approach is to use PGP or S/MIME with a mail service that uses STARTTLS for server-to-server communication.

There are several weak points in the STARTTLS protocol, however. The first weakness is that the flag indicating that a server supports STARTTLS is not itself encrypted, and is therefore subject to tampering, which can prevent that server from establishing an encrypted connection. That type of tampering is exactly what we see today. EFF is working on a set of improvements to STARTTLS, called STARTTLS Everywhere, that will make server-to-server encryption more robust by requiring encryption for servers that are already known to support it.

It is important that ISPs immediately stop this unauthorized removal of their customers’ security measures. ISPs act as trusted gateways to the global Internet and it is a violation of that trust to intercept or modify client traffic, regardless of what protocol their customers are using. It is a double violation when such modification disables security measures their customers use to protect themselves.

Update: the footnote in an earlier version of this post incorrectly described port 587 as “TLS-wrapped.”

1. If you have netcat (nc) installed, you can test your connection for STARTTLS downgrades using the commands shown here.
2. Desktop email clients like Thunderbird generally send outbound email on a different port, 465 or 587, and may not be commonly affected. But there are some exceptions, like the software used by the Golden Frog engineer who spotted an issue on AIO Wireless.