Many ways to break SSL with CRIME attacks, experts warn

Despite browser fixes, disabling SSL compression on servers may be best defense.

A hexadecimal representation of a compressed POST Web request. By changing characters in attacker-controlled data and comparing the different sizes of the compressed request that results, hackers can figure out the encrypted values of authentication cookies.

As previously reported by Ars, browsers from Microsoft, Google, Mozilla, Apple, and Opera aren't vulnerable to the exploit dubbed CRIME, which is short for Compression Ratio Info-leak Made Easy. But until recently both Chrome and Firefox users were susceptible to attacks that allowed hackers to decrypt secure cookies used to log in to e-mail and online bank accounts. Given the number of smaller browsers in use, or the possibility some end users may be using out-of-date software, website operators may want to proactively disable compression used during sessions protected by the SSL, or secure sockets layer, protocol.

"It's clear that there are an uncountable number of ways to exploit the vulnerability if it is present," researchers for security firm iSEC Partners wrote in a recent blog post. "Rather than trying to block individual avenues to exploitation—which is likely impossible—we recommend you mitigate the issue at the source by disabling SSL Compression (and SPDY Compression is used.)"

SSL compression is turned on by default in Apache, the Internet's most widely used webserver application. It can be easily turned off in version 2.4.3, but the method for disabling it in the still widely used version 2.2 is less straightforward, the blog post warned. It's also unclear if compression is supported by Amazon's Elastic Load Balancers. Microsoft's competing Internet Information Services doesn't support compression at all. There was no advice offered concerning server-side settings for SPDY.

The iSec Partners blog post provides a simplified overview of how CRIME is able to brute-force crack the secret value of encrypted cookies. It works by comparing the size of compressed data chunks contained in web requests when they contain slightly different attacker-controlled inputs. When the inputs contain values that are also found in the cookie value, the compressed chunk is smaller. "An attacker who can observe the size of the SSL packets can use this technique in an adaptive fashion to learn the exact value of the cookie," the blog post explained.

How often does an attacker have enough control of a PC to make the required requests, but not just key log the real password? This attack is purely academic until it's usable from packet captures only.

It's also unclear if compression is supported by Amazon's Elastic Load Balancers.

The default ELB SSL configuration doesn't enable compression, but is vulnerable to BEAST and client-initiated renegotiation DoS. Per the SSL Labs report card. I haven't bothered to dig further into the configuration, though, to see what's possible.

...browsers from Microsoft, Google, Mozilla, Apple, and Opera aren't vulnerable to the exploit dubbed CRIME, ... But until recently both Chrome and Firefox users were susceptible to attacks

Seriously? How does something like this make it through editing?

How about writing something something clear like:

...CURRENT browsers from Microsoft, Google, Mozilla, Apple, and Opera aren't vulnerable to the exploit dubbed CRIME, ... But until recently both GOOGLE Chrome and MOZILLA Firefox users were susceptible to attacks...

As written it's unclear and confusing. Better yet how about reporting what versions of Chrome and FireFox are actually secure vs insecure? Further how about mentioning by name some of these mysterious browsers that are still vulnerable to this attack? Are we really supposed to infer something useful from this, as in Mobile Safari is insecure? Silk? IE8? etc... because it's painfully short on facts.

browsers from Microsoft, Google, Mozilla, Apple, and Opera aren't vulnerable to the exploit

Surely that means the advice should be to _make no changes at all_ since all change is risky and should be avoided unless there is some significant benefit?

If I was a sysadmin, I wouldn't be changing my server configuration over this exploit.

Chrome has auto-update, so pretty much everyone is on the latest version. FireFox should make a bugfix update to old-but-popular versions (3.2.x, etc).

No kidding, it's a bit of jumping at shadows. Plus compression on internet traffic is a good thing. The internet has a lot less headroom for more throughput than people think. At the provider level, they have just enough fibre techs running around dropping lines to keep things going.

The correct solution is to block unpatched browsers and take users to a page explaining why they need to use a different browser to access and which browsers are acceptable. Educating the end-user at minimal overhead on either end should always be the default approach to such issues, not kludging the servers with suboptimal configurations to work around issues which can be fixed.