CRIME: Information Leakage Attack against SSL/TLS

It seems that it is that time of year again, when Juliano and Thai present their most recent attack against crypto system. Last year, it was BEAST. This year, it’s CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated.

Initially, it was only known that the attack builds on top of an information leakage weakness, and the full results were going to be revealed at the talk at Ekoparty on September 21. Funnily enough, the details that were revealed themselves “leaked” and were sufficient for the experts to understand what is going on: On StackExchange, Thomas Pornin speculated that it was about compression. An academic paper from 2002 (PDF) was revealed. A proof of concept was submitted by xorninja, and improved by Krzysztof Kotowicz. Dan Goodin wrote a great summary of what was known at the time, and included a video of the demonstration. Finally, Threat Post published a confirmation from Juliano and Thai that was indeed compression.

What is the problem?

The root cause of the problem is information leakage that occurs when data is compressed prior to encryption. If someone can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then she will be able to extract the unknown data from it.

In practice, the attack works best against session cookies. If a man-in-the-middle (MITM) attacker 1) can observe network traffic, and 2) manipulate the victim’s browser to submit requests to the target site, she can, as a result, steal the site’s cookies, and thus hijack the victim’s session. In the current form, the exploit uses JavaScript and needs 6 requests to extract one byte of data. The use of JavaScript is desired, but not required: simple <img> tags can do the job just as well, although with a performance penalty.

How bad is it?

Several aspects need to come together for CRIME to be widely exploited. First of all, there has to be server-side support for compression of request data before encryption. TLS supports DEFLATE compression (not to be confused with HTTP response compression, which is very popular, but not vulnerable to CRIME), but not all servers implement it. SSL Labs tests across the SSL Pulse data set indicate that about 42% of the servers support TLS compression. The servers include some of the most popular sites in the world.

Another possibility is that the newer protocol, SPDY, is also vulnerable, because it has a separate mechanism for request header compression. In that case, all servers that support SPDY would be potentially vulnerable. SPDY is a young protocol and not very widely supported, but the sites that do support it are typically larger properties. SSL Labs is currently half way in measuring the support for SPDY across the SSL Pulse data set, but we’re currently seeing SPDY support at 0.8%2%.

The second requirement is that client-side also supports compression, and here we will find that the situation is much better. The only browser to properly support TLS compression is Chrome. As for SPDY, both Chrome and Firefox support it. However, it is understood that both Chrome and Firefox have removed support for TLS compression in their most recent updates. (For Firefox, it’s even not clear if it was ever enabled.) SSL Labs runs a passive SSL fingerprinting tool called sslhaf. Using it we were able to estimate that only about 7% of browsers support compression at this point. This is on our site, which gets a higher portion of the traffic from Chrome and Firefox users. Analysing the logs, we could see traces of Chrome, and, looks like, some mobile browsers. It is not clear if there were any changes to the SPDY implementation in Chrome and Firefox, but it is reasonable to expect that there will be.

The third requirement for wide exploitation is an easy to use exploitation tool. Unlike BEAST, CRIME seems much easier to exploit; we’ve already seen a simple proof of concept, and so it’s likely that we will see a complete tool soon, maybe as a fork of sslstrip.

Taking all of the above in the account, CRIME will be easy to exploit, but it will be harder to find vulnerable clients. Internet Explorer, Safari, and Opera do not seem to be affected. Chrome and Firefox seem to be, but they use automatic updates, so I expect that the majority of the user base will upgrade to the patched versions. The vulnerable clients will thus be restricted to those using older clients.

Further, unlike BEAST, which requires a manual intervention to mitigate, CRIME will be easier to patch. I expect most vendors will simply disable TLS compression.

What to do?

First of all, if you’re using an older Chrome or Firefox, upgrade to the most recent version. If you’re operating a web site, use the SSL Labs assessment tool to determine if your site supports TLS compression and SPDY (look for Compression and Next Protocol Support on the results page, towards the bottom). If you think the risk is too high, disable compression if your web software allows you to do it. (If they don’t today, they will soon.)

Update (15 Sep 2012) In Details on the “CRIME” attack, iSec Partners give a very good overview of which browsers are vulnerable, and how to disable compression server side.