« STARTTLS has a glaring problem: it's negotiated over the plaintext channel.
The S: 250 STARTTLS line is sent on the clear so an attacker performing a MitM attack can just block it, prevent it from ever reaching the client. At that point the client will simply go ahead with unencrypted SMTP, unaware that the server supports TLS, and the server will think it's the client that came short in supporting it.
In browser world, it's as if you always connected over HTTP and relied on the 301 redirect to switch to HTTPS. An attacker can do a SSL stripping attack where they just answer to your HTTP query. It's also what HSTS is designed to prevent.
[...]
At this point you might think you can make a choice: "I'll require encryption on all my connections and accept the tradeoff of only receiving from and delivering to servers that support STARTTLS". Or, "I'll make a whitelist of known domains for which I require STARTTLS because I know they support it".
You actually can't.
The problem is in certificate verification: what hostname do you verify a certificate against? That is, what name do you require on the certificate to make sure you are not talking with an attacker?
The answer is "whatever the target of the MX record is". And this makes certificate validation—and signed certificates—completely useless. (Indeed, all mail servers will accept expired, self–signed certificates.)
First, let's see why we can't verify against the domain portion of the email address. Take my email: it's @filippo.io but it's handled by FastMail. FastMail doesn't have a certificate for filippo.io. How it works instead is that a client will perform a MX lookup
[...]
STARTTLS can't be secured in any way against an active attacker. So, what is it good for? Well, it's opportunistic encryption and it's not worthless.
Opportunistic encryption changes the attack requirement from simple passive observation to risky active interception. It stops dragnet collection that we know too well some agencies perform.
So, bring it on with STARTTLS, just don't bother with getting a CA issued certificate and know that a targeted MitM–capable attacker can totally intercept your mail on the wire.
[...]
There is actually a solution and it's DNSSEC. SMTP is the use case where it really shines!
Mail servers can perform DNSSEC verification to make sure the MX is not tampered with, and then use DANE to retrieve the intended certificate fingerprint. This would give SMTP a fighting chance against an active attacker.
[...]
So this is it. The Internet is terrible and until DNSSEC sees wide deployment SMTP will have at best opportunistic encryption.
A practical note on active attacks: MitM on a server-to-server connection is not a common capability but it's very possible for a determined attacker. For example BGP hijacks happen frighteningly often and there are agencies with taps on the Internet backbones.
Still, STARTTLS is better than allowing dragnet surveillance, so please, please support it. You don't even have to get a signed certificate! There are no excuses. »
Via
http://seenthis.net/messages/377113