I don't think IMAP protocol is very vulnerable. The vulnerable part of IMAP is the password string, but clients always use the same commands before logging in. After login the only way for attacker to affect the output is by sending emails that the client downloads. So, I guess if:
1) Attacker finds out which IMAP client is being used.
2) Attacker finds out how to send emails there, and what exactly they look like (the Received headers etc.)
3) Keeps tracking when IMAP client is connecting to server, possibly even forces streams to disconnect to make this faster.
4) Whenever client logs in, send a special mail that tries to crack the password.
That's pretty difficult to do reliably and assumes that clients immediately download new mails.
But yeah, I guess it would be good for security to flush the dictionary after login. But does OpenSSL even support that?.. Luckily COMPRESS extension isn't vulnerable to this. And I don't think there's anything worth protecting post-login (clients don't redownload the same old mails - at best you could get LIST reply and message flags).
On 30.9.2012, at 14.40, Jan Kundr?t wrote:
> Hi,
> recently, there's been an attack on TLS connections which carry the HTTP traffic -- "CRIME" [1]. I'm not a cryptographic expert (although I like to play one occasionally), but to my understanding, the attack combines adaptive stream compression leaking data about the plaintext with the attacker being able to control what gets transferred through the stream. Together, these can reveal a secret HTTP cookie in just 6 requests per each byte of the plaintext. Basically, when a secret cookie of "foo=123456789" is passed in the HTTP headers (which happens to be automatically included by the browser), an attacker-chosen payload later in the stream like "foo=123xxx" will compress better than "foo=120xxx", revealing one byte of the plaintext at a time.
>
> The browser vendors have reacted by disabling the TLS compression unconditionally. The Qt library which my IMAP client Trojita [2] uses has changed to disable TLS compression by default [3].
>
> To my non-expert understanding, this attack could probably be limited by explicitly flushing the compressor's dictionary before and after sending the sensitive data over the wire. However, this is only my quick analysis of how the attack works, and I cannot guarantee that it is reasonably correct.
>
> I was wondering if any IMAP vendor has evaluated the risk here. Do you ship with the TLS compression on by default? (Both clients and servers can refuse the compression.) Do you reset the zlib compressor's dictionary around "sensitive" parts? What is sensitive for you -- a password, message payload in FETCH responses and APPEND commands? What else? If you support the COMPRESS extension, do you employ the same safeguards?
>
> With kind regards,
> Jan
>
> [1] http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor
> [2] http://trojita.flaska.net/
> [3] http://qt.digia.com/en/Release-Notes/security-issue-september-2012/
>
> --
> Trojita, a fast e-mail client -- http://trojita.flaska.net/
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>