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.
STARTTLS and misplaced outrage
S
RSS - Posts
Well, it’s not white or black like you say.
What if the same SMTP server allow me to use STARTTLS when I’m connected via one provider but not when I’m connected via AT&T ? What if every SMTP server I try when I’m connected via AT&T gives me this error when the STARTTLS is attempted?
A screenshot can’t tell you if we have a misbehaving server, a blocking firewall on THAT server, o a firewall on the CLIENT or a firewall on one of the paths from the client to the server.
From my readings there are more that simple screenshots supporting
http://www.goldenfrog.com/blog/fcc-must-prevent-isps-blocking-encryption
and the filing where you can see that screenshot:
http://www.goldenfrog.com/downloads/pdf/Golden-Frog-Comments-FCC-GN-14-28-Final.pdf
It is pretty black and white.
What you’re seeing is a PIX NAT with MailGuard turned on. There’s no real question about that – the symptoms are very distinctive.
MailGuard only applies when you’re using port forwarding to tunnel a port from outside the NAT to inside the NAT, and have explicitly turned it on.
The most likely scenario, by far, is that the mailserver operator is behind a PIX, and has it configured like that. As port forwarding is specific to the interface that traffic comes in on, it’s quite possible that it’s only misconfigured for traffic coming over some networks.
Drastically less likely is that there was a PIX installed – backwards – on the cellular providers network.
Somewhat less likely still is that they’re simply lying about what they’re seeing. But those are the only three options.
PIX NATs are end user gear, and fairly low-end end user gear at that. It’s extremely unlikely you’d find it in a transit network.
The article you link to is simply them explaining that they can’t replicate what they claim to have seen previously. Reading the PDF submitted to the FCC reveals something I didn’t know previously – that they’re a commercial VPN provider, and have a strong commercial incentive to claim that ISPs are doing terrible things to consumer traffic.
At the very least, that explains why they’re less interested in considering the obvious explanation (“the mailserver operator screwed up their firewall configuration”) and went straight to “major consumer ISPs are blocking encrypted traffic”.
When I hear hoofbeats I think horses, not zebras.
I’m not saying that the whole incident, from the press releases to the FCC filings is just a marketing exercise, but it has that appearance.
SANS just reported the original story like it was news, with editorial commentary from Dr. Ulrich that echoed what you said. …that it’s not news.
“While using his laptop tethered to his phone and connected via Cricket, he was unable to send email securely. He switched to the coffee shop’s Wifi and was able to send encrypted email. They concluded that STARTTLS was being intercepted.”
This should not have happened if the block is a PIX on the server side. So, maybe you are right and they are lying, but the story (IF TRUE) doesn’t match the “PIX on the server” conclusion, IMHO.
If someone tells you he saw an horse with white and black stripes you think to zebras 😉 Or you can think he’s lying.