TAKING A BITE OUT OF CRIME —

Internet architects mull changes to fight SSL-busting CRIME attacks

IETF proposes change to long-standing practice of compressing encrypted data.

Dan Goodin - Oct 18, 2012 10:20 pm UTC

Engineers who help oversee Internet standards are proposing changes to long-standing website practices in order to guard against a new attack that exposes user login credentials even when they are transmitted through encrypted channels.

The tentative recommendations are included in a draft document filed earlier this week with the IETF, or Internet Engineering Task Force. It is among the first technical documents to grapple with an attack unveiled last month that allowed white hat hackers to decrypt the contents of encrypted session cookies used to log in to user accounts on Dropbox.com, Github.com, and other sites. (The sites took measures to block the exploit after researchers Juliano Rizzo and Thai Duong gave them advanced notice of their exploit.) Short for Compression Ratio Info-leak Made Easy, CRIME provided a reliable and repeatable means for attackers to defeat the widely used secure sockets layer and transport layer security protocols. Together, they form the basis of virtually all encryption between websites and end users.

CRIME is able to deduce the contents of encrypted communications that use data compression to reduce the amount of time it takes to move packets from one point to another. By injecting different pieces of known data into a compressed SSL data stream over and over and then comparing the number of bytes each time, attackers can use the method to deduce the encrypted contents character by character. The method worked against protected Web communications that used TLS compression or SPDY, an open networking protocol developed by Google engineers.

"It is RECOMMENDED to disable compression when communications are not trivial, unless traffic increase is considerable," IETF members B. Kihara and K. Shimizu wrote in the draft, which was billed as a "work in progress." "If data are confidential and other mitigations are inapplicable, compression MUST be disabled, especially when the compression is applied in the lower layer like TLS compression."

When compressing whole data in the same context is unavoidable, the draft continued, encryption schemes must insert random paddings to prevent disclosure of the original size of the compressed data. "Note that this mitigation cannot prevent attackers from guessing secrets by statistical approaches," the authors continued. The ineffectiveness of padding wasn't lost on other cryptographers. "Adding random padding to hide the length of compressed/encrypted data is like setting your Prius on fire because it doesn't pollute enough," Johns Hopkins University professor Matthew Green said in a Twitter dispatch. Marsh Ray, a software developer with two-factor authentication provider PhoneFactor, replied: "Or like adding noise to electric cars so hearing impaired people can cross the street?"

This week's draft will expire in the middle of April and could be updated, replaced, or obsoleted by other documents at any time.

Promoted Comments

marshraySmack-Fu Master, in training
jump to post

Fearknot wrote:
Maybe his analogy wasn't that padding is cryptographically ineffective, but that adding padding is ineffective when your goal is compression.

That's how I understand it.

article wrote:
Marsh Ray, a software developer with two-factor authentication provider PhoneFactor, replied: "Or like adding noise to electric cars so hearing impaired people can cross the street?"

Fearknot wrote:
Did he intentionally mix this up?

It certainly made a lot more sense in my head than it does looking at it now and I would have thought about it longer had I known it was going to end up in Ars!

There was also a link in my tweet to an article showing this was a very real situation in practice. The NHTSA is actually mandating something like this.

Imagine a world where hearing impaired people were being publicly run down and maimed by electric cars. The media and population are all in a dilemma about whether or not the benefits of electric cars are worth the costs. The idea is that adding noise to electric cars is seemingly a waste of good silence (channel bandwidth, get it?), but it still helps enough in practice that it enables us to gain the main benefits of electric cars without feeling guilty.

Fearknot wrote:
I'll add one of my own, sticking with the theme: Adding padding when encrypting compressed data is like adding a gasoline engine to your electric car so blind people can hear you coming.

Works for me.

And, in fact, the Prius does have a gasoline engine due to the various tradeoffs involved.

3 posts | registered Oct 18, 2012
AhtapsSmack-Fu Master, in training
jump to post

Fearknot wrote:
iregisteredjusttosaythis wrote:
article wrote:
The ineffectiveness of padding wasn't lost on other cryptographers. "Adding random padding to hide the length of compressed/encrypted data is like setting your Prius on fire because it doesn't pollute enough," Johns Hopkins University professor Matthew Green said in a Twitter dispatch

And perhaps if I understood why the padding was ineffective, then I would be able to understand this analogy...

Maybe his analogy wasn't that padding is cryptographically ineffective, but that adding padding is ineffective when your goal is compression.

article wrote:
Marsh Ray, a software developer with two-factor authentication provider PhoneFactor, replied: "Or like adding noise to electric cars so hearing impaired people can cross the street?"

That one makes even less sense. Did he intentionally mix this up? (Adding noise to electric cars is for the benefit of blind people, not for deaf people who can just look left and right before crossing.)

I'll add one of my own, sticking with the theme: Adding padding when encrypting compressed data is like adding a gasoline engine to your electric car so blind people can hear you coming.

I think what's trying to be communicated is that adding padding just means that it takes a little longer for the attacker to decrypt because it's just extra content to test against. Hence setting your Prius on fire because it doesn't pollute enough. It's still the same problem, you're just adding more to it. Same with sound for deaf people. You're adding more, but the problem still remains.

To add my own analogy, it's like trying to fix a research paper by adding more words when it is about the wrong topic in the first place.

20 posts | registered Aug 8, 2011
marshraySmack-Fu Master, in training
jump to post

Ahtaps wrote:
I think what's trying to be communicated is that adding padding just means that it takes a little longer for the attacker to decrypt because it's just extra content to test against.

I'm not ready to give up on padding yet. Maybe we can make it take more than "a little longer" for the attacker.

Yes, padding simply means the attacker must take more samples to gather more statistics. But one could make a similar claim about key lengths today: they just make it take more work. Of course, padding won't be able make the attacker's job 2^128 times harder like we might by lengthening our crypto keys from 128 to 256 bits.

But what if padding could make the difference between CRIME requiring a handful of HTTP requests per decrypted byte to needing millions? I think that could be worthwhile, even if we'll still have to give up on secure transport layer compression in general. Having some nonzero amount of plaintext length hiding seems like a nice, conservative, choice that could occasionally save some higher-level protocols from their mistakes as well.

3 posts | registered Oct 18, 2012
toast0Wise, Aged Ars Veteran
jump to post

frankie1969 wrote:
Quote:
It also allowed them to transport layer security protocols

I think you accidentally a verb here.

I still don't get how this attack works. How can Eve inject arbitrary data pre-encryption, then watch the resulting encrypted output, if they don't already have control over that end of the connection?

The attack basically works like this:

Requirements:
The victim's browser is known to have an HTTPS cookie for a known site.
The victim's browser and the known site enable SSL compression.
The attacker can cause the victim's browser to load the attacker's javascript. (could be phishing, MITM on HTTP, linkbait on articles, etc)
The attacker can observe the amount of data sent to the known site.

The attacker causes the victim's browser to make repeated requests to the HTTPS site with attacker controlled data via image urls, javascript get or post, etc. If the data matches the cookie value, it will be compressed and the amount of data sent to the known site will be reduced. Note that while data size may not be easily observable, data size influences transfer time, and transfer time is observable within javascript.

115 posts | registered Oct 18, 2006

Promoted Comments

marshraySmack-Fu Master, in training
jump to post

Fearknot wrote:
Maybe his analogy wasn't that padding is cryptographically ineffective, but that adding padding is ineffective when your goal is compression.

That's how I understand it.

article wrote:
Marsh Ray, a software developer with two-factor authentication provider PhoneFactor, replied: "Or like adding noise to electric cars so hearing impaired people can cross the street?"

Fearknot wrote:
Did he intentionally mix this up?

It certainly made a lot more sense in my head than it does looking at it now and I would have thought about it longer had I known it was going to end up in Ars!

There was also a link in my tweet to an article showing this was a very real situation in practice. The NHTSA is actually mandating something like this.

Imagine a world where hearing impaired people were being publicly run down and maimed by electric cars. The media and population are all in a dilemma about whether or not the benefits of electric cars are worth the costs. The idea is that adding noise to electric cars is seemingly a waste of good silence (channel bandwidth, get it?), but it still helps enough in practice that it enables us to gain the main benefits of electric cars without feeling guilty.

Fearknot wrote:
I'll add one of my own, sticking with the theme: Adding padding when encrypting compressed data is like adding a gasoline engine to your electric car so blind people can hear you coming.

Works for me.

And, in fact, the Prius does have a gasoline engine due to the various tradeoffs involved.

3 posts | registered Oct 18, 2012
AhtapsSmack-Fu Master, in training
jump to post

Fearknot wrote:
iregisteredjusttosaythis wrote:
article wrote:
The ineffectiveness of padding wasn't lost on other cryptographers. "Adding random padding to hide the length of compressed/encrypted data is like setting your Prius on fire because it doesn't pollute enough," Johns Hopkins University professor Matthew Green said in a Twitter dispatch

And perhaps if I understood why the padding was ineffective, then I would be able to understand this analogy...

Maybe his analogy wasn't that padding is cryptographically ineffective, but that adding padding is ineffective when your goal is compression.

article wrote:
Marsh Ray, a software developer with two-factor authentication provider PhoneFactor, replied: "Or like adding noise to electric cars so hearing impaired people can cross the street?"

That one makes even less sense. Did he intentionally mix this up? (Adding noise to electric cars is for the benefit of blind people, not for deaf people who can just look left and right before crossing.)

I'll add one of my own, sticking with the theme: Adding padding when encrypting compressed data is like adding a gasoline engine to your electric car so blind people can hear you coming.

I think what's trying to be communicated is that adding padding just means that it takes a little longer for the attacker to decrypt because it's just extra content to test against. Hence setting your Prius on fire because it doesn't pollute enough. It's still the same problem, you're just adding more to it. Same with sound for deaf people. You're adding more, but the problem still remains.

To add my own analogy, it's like trying to fix a research paper by adding more words when it is about the wrong topic in the first place.

20 posts | registered Aug 8, 2011
marshraySmack-Fu Master, in training
jump to post

Ahtaps wrote:
I think what's trying to be communicated is that adding padding just means that it takes a little longer for the attacker to decrypt because it's just extra content to test against.

I'm not ready to give up on padding yet. Maybe we can make it take more than "a little longer" for the attacker.

Yes, padding simply means the attacker must take more samples to gather more statistics. But one could make a similar claim about key lengths today: they just make it take more work. Of course, padding won't be able make the attacker's job 2^128 times harder like we might by lengthening our crypto keys from 128 to 256 bits.

But what if padding could make the difference between CRIME requiring a handful of HTTP requests per decrypted byte to needing millions? I think that could be worthwhile, even if we'll still have to give up on secure transport layer compression in general. Having some nonzero amount of plaintext length hiding seems like a nice, conservative, choice that could occasionally save some higher-level protocols from their mistakes as well.

3 posts | registered Oct 18, 2012
toast0Wise, Aged Ars Veteran
jump to post

frankie1969 wrote:
Quote:
It also allowed them to transport layer security protocols

I think you accidentally a verb here.

I still don't get how this attack works. How can Eve inject arbitrary data pre-encryption, then watch the resulting encrypted output, if they don't already have control over that end of the connection?

The attack basically works like this:

Requirements:
The victim's browser is known to have an HTTPS cookie for a known site.
The victim's browser and the known site enable SSL compression.
The attacker can cause the victim's browser to load the attacker's javascript. (could be phishing, MITM on HTTP, linkbait on articles, etc)
The attacker can observe the amount of data sent to the known site.

The attacker causes the victim's browser to make repeated requests to the HTTPS site with attacker controlled data via image urls, javascript get or post, etc. If the data matches the cookie value, it will be compressed and the amount of data sent to the known site will be reduced. Note that while data size may not be easily observable, data size influences transfer time, and transfer time is observable within javascript.

115 posts | registered Oct 18, 2006

Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene.

Channel Ars Technica

← Previous story Next story →

Promoted Comments

Promoted Comments

reader comments

Channel Ars Technica