ISPs Removing Their Customers' Email Encryption

Presto Vivace points out this troubling new report from the Electronic Frontier Foundation: 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 U.S. 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.

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.

Comments

Re:Most severs shouldn't be vulnerable

[PAjamian]

Look, most severs these days are configured in such a way that STARTTLS runs on a different port than the plain-text connection.

Wrong. STARTLS specifically allows for both plain text and TLS on the same port.

The server will reject login requests until the STARTTLS handshake is completed.

Partially correct. A well configured server will behave this way on the *submission* port (587) but if the MX port (25) were configured this way then you would be blocking a lot of legitimate email from old servers on the internet that do not support STARTTLS and as such is is not recommended to require STARTTLS for port 25 MX to MX communication. Also even when STARTTLS is used the connection is still plain text until STARTTLS is negotiated.

But take it from a guy who worked on an email client

Thanks for giving me a link to yet another piece of software written by someone who doesn't understand the technology behind it.

(Also: STOP USING STARTTLS!!!)

Wrong again. The only way to have an encrypted SMTP submission channel without STARTTLS (other than tunnelling through ssh or something like that) is via SMTPS (port 465). SMTPS is long ago deprecated and should not be used. Port 465 was *never* officially registered for this use and was essentially "hijacked" and there are only a very small number of old email clients that support SMTPS but do not support STARTTLS. You *should* be using STARTTLS over port 587 which is the submission port. Also STARTTLS is the only legitimate means of encryption between a submission server and an MX.

Of note (which I've also said elsewhere), the real reason the author of the original article had problems is because he is trying to use port 25 for submission. He should be using the submission port (587) and it is highly unlikely that his ISP would be blocking the STARTTLS flag on that port.

Authentication

[kiite]

Stripping out STARTTLS may mean that you can't authenticate to the mail server --- which is frequently required --- over an encrypted channel. Some unfortunate individuals set (or don't unset) an option that tells their e-mail clients that encryption is preferred, but not required, which they assume to be sufficient --- because they know that their mail server supports encryption. When those individuals use an ISP that strips out STARTTLS, they are transmitting authentication data in plaintext. Still don't feel like getting angry?

s/flag/command/

[Cramer]

It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.

The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.

Re: DMCA (Defamation)

[rthille]

The headline is wrong. The ISP is removing the mail server's announcement that it supports STARTTLS, and your mail client/server sends your email unencrypted.
The solution to that is using SMTPS on 465, where encryption is presumed, not negotiated. But that was deprecated soon after the RFC came out in favor of TLS. It's almost like someone was thinking ahead and wanted the internet to be less secure:
http://cr.yp.to/talks/2014.10....