POP, IMAP, SMTP, and the POODLE SSLv3.0 vulnerability.

[fanf]

A lot of my day has been spent on the POODLE vulnerability. For details see the original paper, commentary by Daniel Franke, Adam Langley, Robert Graham, and the POODLE.io web page of stats and recommendations.

One thing I have been investigating is to what extent mail software uses SSLv3. The best stats we have come from our message submission server, smtp.hermes, which logs TLS versions and cipher suites and (when possible) User-Agent and X-Mailer headers. (The logging from our POP and IMAP servers is not so good, partly because we don't request or log user agent declarations, and even if we did most clients wouldn't provide them.)

Nearly 100 of our users are using SSLv3, which is about 0.5% of them. The main culprits seem to be Airmail, Evolution, and most of all Android. Airmail is a modern Mac MUA, so in that case I guess it is a bug or misuse of the TLS API. For Evolution my guess is that it has a terrible setup user interface (all MUAs have terrible setup user interfaces) and users are choosing "SSL 3.0" rather than "TLS 1.0" because the number is bigger. In the case of Android I don't have details of version numbers because Android mail software doesn't include user-agent headers (unlike practically everything else), but I suspect old unsupported smart-ish phones running bad Java are to blame.

I haven't decided exactly what we will do to these users yet. However we have the advantage that POODLE seems to be a lot less bad for non-web TLS clients.

The POODLE padding oracle attack requires a certain amount of control over the plaintext which the attacker is trying to decrypt. Specifically:

1. The plaintext plus MAC has to be an exact multiple of the cipher block size;
2. It must be possible to move the secret (cookie or password) embedded in the plaintext by a byte at a time to scan it past a block boundary.

In the web situation, the attacker can use JavaScript served from anywhere to make repeated POST requests to an arbitrary target host. The JS can manipulate the body of the POST to control the overall length of the request, and can manipulate the request path to control the position of the cookie in the headers.

In the mail situation (POP, IMAP, SMTP), the attacker can make the client retry requests repeatedly by breaking the connection, but they cannot control the size or framing of the client's authentication command.

So I think we have the option of not worrying too much if forced upgrades turn out to be too painful, though I would prefer not to go that route - it makes me feel uncomfortably complacent.

Comments

[pir.livejournal.com]

Sadly for general apps on Android (K9 included) currently it's all "wait for Lollypop".

https://code.google.com/p/android/issues/detail?id=61085

[hairyears.livejournal.com]

Well, the Android clients are all phones and tablets, with half the tablets owned by mobile telcos.

None of them will be patched. Ever.

What's the next step for the common-or-garden sysadmin?

SMTP

[(Anonymous)]

Thank you for your post. I basically came to the same conclusion when analysing the subject. Now I'm happy to have found someone else who came to the same conclusion.

I work a lot with SMTP/POP3/IMAP at work. We have not messured yet, but I would not be supprised if a higher percentage of our users use SSL3 dual to the old software that they use. But even a small percentage would not allow us to simply disable SSL3.

We will communicate to our clients an end date for the support of SSL3. And provide them with a duplicate of our interfaces (different IP) with SSL3 turned of, so they can verify their own software before we disable it.

Evolution

[(Anonymous)]

My comment is sort of tangential to the actual blog post, which was good in it's own right.

Since my provider seemingly just disabled SSLv3, I have some insight into the Evolution interface. In the "Receive" tab of the account preferences your choices for "Encryption" are None, SSL, and TLS. Unfortunately there's little advice in the interface about what to choose. Worse, when you've been successfully using SSL and it goes away (as your provider drops it in favor of TLS) the only indication is that sending and receiving of e-mail stops working and you get a "helpful" popup saying "Input Output Error".

So I both understand why people would set it to SSL without understanding why TLS would be better, and why changing may be pretty painful. I vaguely recall when I first set it AGES ago, my provider didn't support TLS. But I could be remembering incorrectly.

My real goal with this comment is to get a search engine to associate Input Output Error and Evolution with this blog post so that anyone else in this predicament has a chance at figuring out that they need to change the option to TLS to fix their e-mail.

Re: Evolution

[fanf]

Thanks for that information!