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.”
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.