The 'CRIME' attack announced last week exploits the data compression scheme used by the TLS (Transport Layer Security) and SPDY protocols to decrypt user authentication cookies from HTTPS (HTTP Secure) traffic, one of the attack's creators confirmed Thursday.
The 'CRIME' attack was developed by security researchers Juliano Rizzo and Thai Duong, who plan to present it next week at the Ekoparty security conference in Buenos Aires, Argentina.
Rizzo and Duong revealed last week that CRIME abuses an optional feature present in all versions of TLS and SSL (Secure Sockets Layer) -- the cryptographic protocols used by HTTPS. However, they declined to name the feature at that time.
On Saturday, Thomas Pornin, a cryptography architect from Quebec, Canada, suggested on a technical question-and-answer website that the feature abused by CRIME might be the SSL/TLS data compression. Pornin even proposed an attack that matched the general description of CRIME.
Rizzo confirmed Thursday via email that CRIME exploits that data compression feature of SSL and TLS. However, SPDY -- a networking protocol that uses a similar compression scheme -- is also vulnerable, he said.
The SPDY (pronounced speedy) protocol was developed by Google and uses techniques like compression, multiplexing and prioritization to reduce the latency of Web pages. It doesn't replace HTTP or HTTPS, but can be used to speed them up.
SPDY has been implemented in Google Chrome and Firefox and is supported by several popular websites including Google search, Gmail and Twitter.
CRIME decrypts HTTPS cookies set by websites to remember authenticated users by means of brute force. The attack code forces the victim's browser to send specially crafted HTTPS requests to a targeted website and analyzes the variation in their length after they've been compressed in order to determine the value of the victim's session cookie.
This is possible because SSL/TLS and SPDY use a compression algorithm called DEFLATE, which eliminates duplicate strings.
For example, if we generate a request that contains a "cookie = 123" string and a "cookie = 456" string and then we compress it with DEFLATE, the compression algorithm will replace the "cookie =" part from the second string with a small token that points to the location of the "cookie =" part from the first string. This will result in a smaller request.
If we then generate another request but with "cookie = 556" instead of "cookie = 456," the compression algorithm will again replace "cookie =" because it matches the identical part from the existing "cookie = 123" string. This will result in a compressed request that is almost identical in length to the first one.
However, if we generate a third request, but with "cookie = 156" instead of "cookie = 456," the compression algorithm will now replace the "cookie = 1" part because it will match "cookie = 1" from the existing "cookie = 123" string. The resulting request will be shorter than the previous two requests because a longer part was replaced.
If we were to assume that we didn't know the 123 value from the first string in advance, the variation in compression ratio for the third request will indicate that we just guessed the first character of that value -- 1.
We can then start the same process again, but now using the already known character and trying different variants for the second one until we see a new variation in compression ratio. CRIME is based on the same principle.
The attack code can't read the session cookie included in the requests because of security mechanisms in the browser. However, it can control the path of every new request and can insert different strings into it in an attempt to match the value of the cookie.
The attacker needs to be able to compare the compressed HTTPS requests as they leave the victim's computer. Therefore, he needs to either be on the same open wireless network as the victim, be in control of the victim's home router or be on the same local area network as the victim, in which case other attack techniques like ARP spoofing can be used.
Session cookie values can be quite long and are made up of uppercase letters, lowercase letters and digits. As a result, the CRIME attack code has to initiate a very large number of requests in order to decrypt them, which can take several minutes.
However, the researchers have developed some algorithms that make the attack more efficient. "One of the CRIME algorithms makes less than 6 request to decrypt each byte. Sometimes 4 is enough, we can tune it," Rizzo said Wednesday on Twitter.
Support for TLS compression among websites is pretty widespread. Forty-two percent of servers tracked by SSL Pulse -- a project that monitors SSL/TLS implementations on the world's top 180,000 HTTPS-enabled websites -- support compression, Ivan Ristic, director of engineering at security vendor Qualys, said Thursday.
However, the level of support for TLS or SPDY compression is not very good on the client side, Ristic said. One source of data suggested that 10 percent of clients support TLS compression, he said.
In order for the CRIME attack to work, both the server and the client need to support the compression feature.
Internet Explorer never supported TLS compression or SPDY. Mozilla Firefox only supports SPDY, but compression was removed in Firefox 15, so the latest stable version of the browser is now protected against CRIME, Rizzo said.
Google Chrome supported both TLS compression and SPDY compression, but the features were removed from the latest version.
It's not yet clear if the Android versions of Chrome and Firefox have been patched.
Ristic believes that in the case of CRIME, the problem is not very serious because compression can easily be disabled both on clients and servers by applying patches.
BEAST -- a different attack against SSL/TLS developed by Rizzo and Duong last year -- is potentially more dangerous than CRIME because it can't be fixed with a patch, Ristic said. You have to fix it manually, he said.
According to SSL Pulse data, more than 70 percent of the world's top 180,000 HTTPS-enabled websites are still vulnerable to BEAST, Ristic said.
"Gmail and Twitter use SPDY, Dropbox and Yahoo Mail use TLS compression," Rizzo said. "We contacted Dropbox and they disabled compression yesterday."
In the future SPDY can be redesigned to use compression but avoid CRIME attacks, Rizzo said. In fact, Google has already developed a solution for this, he said.
"TLS compression could be enabled for some applications protocols but enabling it for HTTP is problematic," Rizzo said.