SSL/TLS compression attacks on mail servers (smtp)

Question

Currently, we know few compression attacks on the SSL/TLS protocol (such as Crime or Breach). I wonder for few days if these attacks are practicable on a mail server (smtp). Is CRIME attack practicable on a mail server ?

Answer 1

Compression attacks like CRIME and BREACH work by triggering repeated transmission of almost the same message with only slight modifications, with these modifications controlled by the attacker. By watching the compressed size of the message the attacker can then reason if the attacker controlled string is contained in the message or not. This is used to guess the value of sensitive data, like the session cookie or CSRF tokens in case of HTTP.

With HTTP these attacks work against cases where the response from the server reflects input from the client (to guess CSRF token in response) or by making the client submit the same request with slight variants of the URL or body data to guess the cookie in the HTTP request. Attacker controlled input is possible since HTTP allows cross-site requests, i.e. the attacker can cause the client to do a specific request and then watch the encrypted request and response.

But SMTP works different. There is usually no way for the attacker to make the client send a specific mail again and again with only slight and attacker controlled modifications. Although one might construct scenarios where almost the same mail gets sent in an automatic way with some attacker controlled input in (see answer from @Giles) in my opinion in all practically relevant cases such compression attacks will not work with SMTP.

Still, it is better to not use TLS level compression (used by CRIME) which is hopefully the default in modern crypto libraries anyway. As for the application level compression used by BREACH: while it is common to use such compression in HTTP (declared by Content-Encoding header) there is no application level compression defined in SMTP or MIME (which is the encapsulation format for mails). While there is an proposed x-gzip64 I've never seen it used in practice or supported by actual mail clients.

Answer 2

The basic principle underlying underlying compression+encryption attacks is that the attacker can cause the sender to send many encrypted messages containing the same text, including a secret value that the attacker wants to find, except for a segment which is controlled by the attacker. The canonical example for CRIME and BREACH is a web response, including a cookie (secret that the attacker wants to find) and some input that the attacker injects via a third-party resource (e.g. an ad).

You may be able to carry out a similar attack against SMTP if you can gather the same ingredients: almost-identical emails, all of them containing the secret that you want to obtain, and differing only or mainly in some value that you can control. Note that SMTP is used on the sending side, which is usually harder to attack: it's easy to snoop on wifi users (just plant a fake hotspot), but it takes a fairly high-level attacker to snoop on connections in a datacenter.

For example, suppose that you're trying to find the email address of a user of a service, and the service is configured to send the user some alerts over email, such as an RSS-to-email feed. If you can inject data into the RSS feed (wibble waffle To: a@gmail.comTo: a@gmail.comTo: a@gmail.comTo: a@gmail.com), then you can carry out a CRIME-like attack to find the email address. This particular attack has many practical issues: it relies on the email being delivered to the victim so it's rather conspicuous (you may try to aim for the spam bin though), and it may run into rate limits (thousands of web requests is nothing but thousands of emails to the same account is likely to be caught by spam protection).

Here's another example with a news-to-email feed where you can inject fake news. This time, assume that the email contains an “unsubscribe” link that contains a secret token. Send a lot of fake news and find the secret token from the “unsubscribe” link. It's fairly common for servers to accept unsubscribe requests without authenticating the user, especially when all the server knows is the user's email (plus associated marketing data) and there's no associated account that the user can log into. This way you could fraudulously unsubscribe a user from their feed. Hopefully, if the server has a user account, the secret token alone doesn't allow you to do anything else on the account.

Another secret you may be interested in is some kind of authorization token. Suppose that a server uses a secret token sent by email (or any other communication method really) as factor to confirm a transaction, and you can snoop on that server's traffic, or on the recipient's traffic. Suppose that this token is all you need to confirm the transaction. Your goal is to trigger a transaction to your benefit (e.g. a money transfer to you) and find the associated token. You get to initiate the transaction so you can control its description. There's a wrong way for the server to do it: use a time-based OTP, which will be repeated across many transactions. Hopefully the server does it right, with a proper random value that is different in each transaction.

Note that except for the case where the secret you want to find is the recipient's email address, you may carry the attack on the client side, against encrypted IMAP or POP rather than SMTP.