Security downgrade with IMAP STARTTLS leads to information leakage | Hacker News Reader

Security downgrade with IMAP STARTTLS leads to information leakage

mozilla.org

28 pointsbased222 comments

That is why one should always use the appropriate "s" port if possible, like in imaps, pop3s or smtps. Then downgrade to TLS-less via fiddling with the STARTTLS exchange maliciously or through a bug is impossible.

Imho STARTTLS needs to die. Maybe thats impossible for SMTP, but for everything else we can and should get rid of it!

Any sysadmin worth their salt would’ve seen this coming from a mile off.

My self hosted mail server only runs {smtp,imap}s, due to encryption being required from the get-go. Any other way seems foolish.

Well, I do run possibly unencrypted smtp on port 25, because I want to receive all my email, not just a tiny fraction of it. Most mails will use smtp and starttls, some plaintext smtp. Nothing uses smtps on 465...

Oh, and the smtp submission port 587 of course still uses starttls, which, together with mandatory authentication on that port, also makes for wonderful misconfiguration opportunities on the server. Of course in addition to clients stupidly sending auth over plaintext on 587.

A ton of embedded systems and software relies on having an open SMTP relay to send emails. Network printers and monitoring solutions are a prime culprit.

Companies very often have open SMTP relays, actively used by these. It's a plague to remove SMTP because how can you remove open SMTP when these things don't support TLS nor authentication?

This bug could have an equivalent in imaps if the client decided to send plaintext data under some conditions.

Yes, but TLS downgrade bugs that revert to plaintext are getting rarer due to better TLS libraries preventing the use of NULL ciphers and the like. I would say it is possible but far less likely than a starttls downgrade, where the plaintext stuff is an integral part of every connection, and the dangerous codepath is right next to the encrypted happy path with frequent crossings...

It's a similar story with LDAPS, in that LDAP+TLS starts off on a plain text connection to negotiate TLS, and it can be all the same port 389 (can be different port 636 too). You might be able to query too much info from a poorly configured LDAP server if it downgrades or sustains that TLS-less connection.

You still see people and software libraries preferring LDAP+SSL on the dedicated SSL port 636 even though the LDAPS+TLS is suppose to be the "modern" method and apart of the LDAP spec.

SMTP needs to die too. Is there even a competing protocol in the pipeline that would mandate encryption and prevent the spoofing of the sender? Every piece of duck tape on top of smtp (startrls, spf, dkim) are optional, cannot be relied on, and often isn’t relied on.

Agreed on everything but SPF. SPF is very simple and works really well.

But it is so often misconfigured or not configured that it is not that useful. Something like a strict spf should be part the mandatory protocol so you can safely reject incoming mails who fail the rules.

Just use any modern IM protocol for that, like matrix, xmpp or maybe even one of the proprietary ones. They all do what SMTP does and more, you would just need to skin the client to look like a mail client to fool your users.

I meant rather with the aim of progressively replacing smtp.

We complain about these protocols that are too widespread to ever be retired but the reality is that TLS and http are managing the pace, ftp, pop and imap are almost gone, and smtp is probably the last of the 1990s protocols that is frozen in time while being a backbone of communications (and attack vectors) on the internet.

Maybe, but progressive replacement also got us dkim, spf and all that. So I'm not sure that there is a possible way to do this for SMTP in any "good" way...

Not aware of an SMTP replacement, that will be a real doozy. Maybe one day FastMail or Google will write a new overcomplicated poorly-documented API-driven cant-do-anything-without-15-layers-of-abstraction replacement and we can spend a couple trillion dollars on replacement gear and new features.

I still like SMTP. Just last year I was able to find the owner of a random smtp box that nobody knew where it was or who it belonged to, by telnet-ing to port 25 and typing out an e-mail to 'root'. Got a response from an admin an hour later. You gotta respect a protocol that you can use directly with nothing but a network socket and a terminal, using the same protocol syntax you learned two decades before.

I once billed $majorAustralianBank about $70k for time spent debugging (and proving to their IT team) that an edge router in their internal network was a Cisco box that was running a specific (and well out of date) version of the OS that in default configuration was intentionally munging any STARTTLS commands that went through it, so all mail passing through was force downgraded to plain text across int internet (into their Microsoft Office hosted mail system).

Nobody involved at $bank even knew of the existence of this router, and they spent several weeks not believing they even owned that model of Cisco gear or that they had any Cisco gear that wasn't fully updated.

It was "fun times" debugging that and documenting/proving exactly what was breaking with no more access than sftp to a web server running non root privileged PHP.

(We may have gone fairly dark-grey hat and broken quite a few internal rules to achieve that... Then had to "parallel construct" our investigation (before I even knew that term) to explain to their tech people haw we'd identified the root cause.)

I'd never heard the term "parallel construct" before either, but I've definitely walked that grey line carefully when disclosing privilege escalation discovery methods.

Can you say anymore? I'm curious what you came up with.

For the benefit of others (from Wikipedia)

> Parallel construction is a law enforcement process of building a parallel, or separate, evidentiary basis for a criminal investigation in order to conceal how an investigation actually began.

ASA Version 8.3(3)?

Or were they actually using the IOS Firewall on a router instead of a firewall?

PIX and ASA appliances used to ship with "ESMTP inspection" enabled by default -- which would strip out the "STARTTLS" advertisement (replacing it with "X"s) from a server's response.

For a new protocol there's no reason an unencrypted variant would exist. Even for HTTP/2 which is fairly old at this point, there aren't in practice unencrypted servers.

So STARTTLS only matters for protocols that already existed, like SMTP and IMAP, and as a result your advice isn't useful without a time machine.

I'd be impressed if as much as 50% of the world's IMAP clients would actually prevent a trivial MITM attack today regardless of this bug, because usually it's left to the user and we know users just want to see the funny cat pictures.

I believe Dovecot can be configured not to even advertise AUTH capability until after you've upgraded to TLS capability. Does anyone know if that would stop this problem?

Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help.

The correct response is to require TLS before auth clientside (as well) unless expressly configured to not attempt TLS auth.

> Does anyone know if that would stop this problem?

Based on my experiences with Dovecot, I believe it would,

> Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help.

Well, hopefully your client isn't braindead and will negotiate an encrypted session first, before sending credentials unencrypted -- especially if you've configured it to use STARTTLS.

Very helpful subtitle: "Security Vulnerabilities fixed in Thunderbird 68.9.0"

Reply on news.ycombinator.com