Starttls
The feds are deploying DMARC
The US National Cybersecurity Assessments & Technical Services Team have issued a mandate on web and email security, including TLS+HSTS for web servers, and STARTTLS+SPF+DKIM+DMARC for email.
It’s … pretty decent for a brief, public requirements doc. It’s compatible with a prudent rollout of email authentication.
STARTTLS and misplaced outrage
About a month ago someone posted a heavily elided screenshot that they claimed was evidence of their ISP, AT&T, sabotaging SMTP connections being sent over their network, meaning that anyone could sniff their passwords and traffic.
This is it:
Most email people looking at that saw the asterisks in the banner and went “Oh. That’s not the ISP tampering with the traffic, the person running the mailserver doesn’t know how to configure their PIX firewall.”
It’s a very, very, very, well known issue.
But some groups who should know better, such as Ars Technica and the EFF, don’t seem to understand – even when they know about PIX fixup – that this isn’t tampering by intermediate ISPs, it’s just the operator of the mailserver in question not knowing how to configure his firewall. And it’s not a general attempt by consumer ISPs to “tamper with email encryption”, it’s just the operator of one mailserver not knowing how to configure his firewall.
PIX is a simple NAT/firewall appliance from Cisco. It’s a reasonable firewall, but it has some quirks. One of them is it’s “MailGuard” or “SMTP fixup” feature. When that’s turned on, it intercepts SMTP traffic and “sanitizes” it, to protect the mailserver from hostile traffic. To do this, it does a couple of things. One is that it blocks any attempt at sending a command that’s not one of the bare basic SMTP commands, by intercepting them and rejecting them with the error “502 5.5.2 Error: command not recognized”. The other is that it hides the software that’s running on the mailserver, removing any mention of it from the banner string sent when you connect. In fact, it replaces any character other than “2” or “0” with an asterisk.
I had an old PIX that I’ve not used in years, so I thought I’d set it up to show you. Here it is, being guarded by Freddy Chimpenheimer.
I set it up as though it was protecting our mailserver.
Here’s what happens when I connect to the mailserver with the PIX configured correctly:
And here’s what happens when I configure the PIX to use “fixup protocol smtp 25” and try and connect to the mailserver again:
Looks pretty similar to the “ISP tampering with the traffic” screenshot this all started with. I’m using an older PIX firmware image (I really didn’t want to spend the time and money to upgrade my PIX) so it errors out on EHLO, rather than just on STARTTLS. And because this old firmware doesn’t support EHLO, you also don’t see it using “XXX” to block out the string “STARTTLS” in the response to EHLO – the line in the original that says “250-XXXXXXXXA” said “250-STARTTLSA” before the PIX censored it.
Now I have those screenshots I’m going to disconnect my PIX and put it back in the pile of spare networking gear.
So the whole issue is just a mailserver operator who has a badly misconfigured firewall in front of his mailserver, nothing more.
TLS and Encryption
Yesterday I talked about STARTTLS deployment, and how it was a good thing to support to help protect the privacy of your recipients.
STARTTLS is just one aspect of protecting email from eavesdropping; encrypting traffic as the mail is being sent or read and encrypting the message itself using PGP or S/MIME are others. This table shows what approaches protect messages at different stages of the messages life:
[table nl=”~”]
Compromise point,SUBMIT~+IMAPS,TLS,PGP /~SMIME
Sender’s computer as mail is sent,,,
Sender’s computer later,,,[icon name=check-square]
Sender’s network,[icon name=check-square],,[icon name=check-square]
Sender’s ISP,,,[icon name=check-square]
Global Internet (passive),,[icon name=check-square],[icon name=check-square]
Global Internet (active),,[icon name=question-circle],[icon name=check-square]
Global Internet (later),,[icon name=question-circle],[icon name=check-square]
3rd party mail services,,,[icon name=check-square]
Recipient’s ISP,,,[icon name=check-square]
Recipient’s network,[icon name=check-square],,[icon name=check-square]
Recipient’s computer as mail is read,,,
Recipient’s computer later,,,[icon name=check-square]
[/table]
You can see that if you’re sending really sensitive data, you should be encrypting the entire message with PGP or S/MIME (or not sending the message via email at all). Doing so will protect the content of the mail against pretty most sorts of attack, but is pretty intrusive for the sender and recipient so can’t really be used without prior agreement with the recipient.
The other approaches will make some sorts of passive surveillance much more difficult, though.
Encrypting the connection a user uses to send mail ([rfc 6409]using the SUBMIT protocol[/rfc]) and to read mail ([rfc 2595]using TLS to protect IMAP or POP3[/rfc]) will protect against passive sniffing when the user is on possibly hostile network, such as public wifi or an employers network. That’s an easy place to try and sniff traffic, and if that traffic isn’t protected an attacker can not only read someone’s email, they can steal their credentials and cause all sorts of havoc. All general purpose mail clients and all ISPs support encryption here, so it’s almost universally used.
STARTTLS use with SMTP is all about protecting email traffic when it’s being sent between ISPs – both between the sender’s ISP and the recipient’s and also between any 3rd party mail services (outsourced spam filtering, mailing list providers, vanity domain fowarders, etc.).
I’ve listed three different sorts of attack on that inter-ISP traffic – passive, active and “later”.
A passive attack is where the attacker has the ability to listen to bytes as they go by, but isn’t able to modify or intercept them. While you might think of this as something a nation state would do, via secret agreements with backbone providers or high-tech fiber optic cable taps, there are ways a smaller attacker might be able to compromise an intermediate router and tap that traffic with little risk of detection. Deploying any sort of STARTTLS will protect against this, even if it’s misconfigured, using expired certificates or even just the default setup of a newly deployed mailserver. Facebook describe these weaker forms of STARTTLS as “opportunistic” in their survey – it’s not perfect, but it’s a lot better than nothing.
An active attack is one where the attacker has the ability to intercept and modify traffic between the two ISPs. This seems like it would be harder to do than a passive attack, but it’s often easier, though not as stealthy. Once that’s done, the attacker can pretend to be the recipient ISP and have full access to read, modify or discard messages. To protect against this sort of attack TLS needs to be used not just to encrypt the traffic in-flight, but also to allow the sender to validate that the mailserver they’re talking to really is who they think it is. This is what Facebook describe as “strict” – it requires that the mailserver have a valid certificate, issued by a legitimate certification authority for the domain that the mail is being sent to.
What about “later”? It’s easy to imagine a case where an attacker has been passively monitoring and recording encrypted traffic for a while, and then later they manage to acquire the encryption keys that were used (by, for example, issuing a subpoena to the recipient ISP, or using a compromise to rip them out of your servers memory). With many forms of encryption once you have those private keys it’s possible to decrypt all the traffic you’ve already captured. There are a few algorithms, though, that have what’s known as perfect forward secrecy – knowing the private keys that were used at the time the mail was transferred doesn’t allow you to decrypt them at a later time. If you’re concerned about the privacy of your messages, you should definitely read up on how to set that up.
All of these techniques are a great way to defend against ubiquitous or casual attempts to read your messages, but none of them are proof against a determined attacker. If all else fails, there’s always a wrench attack.
Protect your email with TLS
You probably use TLS hundreds of times a day. If you don’t recognize the term, you might know it better by it’s older name, SSL.
TLS is what protects your data in transit whenever you go to Google, or Yahoo or even this blog. The little padlock in your browser address bar tells you that your browser has used the TLS protocol to do two things. First, it’s decided that the server you’re connecting to really is operated by Google, or Yahoo or us – you’re (probably) not having your session intercepted by someone in the middle between you and the webserver, either to read your traffic or modify it en-route. Second, it is encrypting all the traffic between you and the webserver, so that it can’t be passively monitored while in transit. Because of concerns about ubiquitous surveillance many websites – including ours – are moving to use TLS for everything, not just for protecting a login page or a credit card number.
That’s great for the web, but how does it apply to email? One place it’s used is for connections between your mail client and your local mailserver – sending mail to the smarthost via [rfc 4409]SUBMIT[/rfc] and fetching mail using [rfc 2595]IMAP or POP3[/rfc] almost always use TLS. That protects the privacy of your messages between you and your ISP and also protects the username and password you use to authenticate with.
Mail traveling between ISPs didn’t used to be encrypted “on the wire” , but about 15 years ago [rfc 3207]an extension to SMTP was proposed[/rfc] that would allow ISPs to negotiate during each session whether they should encrypt it or not. This extension, often referred to as STARTTLS after the command it uses, allows gradual rollout of encryption of mail traffic between ISPs without requiring any sort of flag day. A mailserver that supports STARTTLS will tell everyone who connects to it “Hey! I support STARTTLS!”. When a smarthost that also supports it connects to that mailserver it will go “Great! I support STARTTLS too! Lets do this!” and convert the plain text SMTP session into an encrypted session protected by TLS.
Fifteen years seems like a long period in Internet time, but non-intrusive protocol changes can take a long time to deploy. Facebook Engineering have done the work to see how that deployment is going with their survey of the current state of SMTP STARTTLS deployment. The results are really quite positive – over three quarters of the mailservers they sent mail to supported STARTTLS, covering nearly 60% of their users. That’s definitely enough to make supporting STARTTLS worthwhile.
More about TLS and encryption tomorrow.