29 ms·

CRIME

63 points by stalled 14y ago

duskwuff 14y ago
Interesting -- looks as though the speculation as to the nature of CRIME was pretty much dead-on. Took years for anyone to realize that compression introduced a vulnerability into HTTPS, but as soon as everyone knew that there was something there, the nature of the attack was immediately guessed. (Although I'd be much more worried if the community had discovered a different vulnerability!)
- __alexs 14y ago
  People have been thinking about this sort of attack since at least 2002 http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091 http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091
stalled 14y ago
(Previous discussion: http://news.ycombinator.com/item?id=4510829 http://news.ycombinator.com/item?id=4510829)
mjs 14y ago
It seems like the solution is to special case sensitive headers like "Cookie", so that the compressed version doesn't leak information. But isn't every byte equally worthy of protection? What if there's sensitive information in the body? (I get that the format of the Cookie header is probably much more structured/predictable than usernames or account details that might appear in the body, but surely a good cryptosystem would be 100% resistent to these sorts of side-channel attacks, without any need to guess which headers need to be handled more carefully.)
- daeken 14y ago
  This attack depends on being able to control the requests made; cookies are automatically added to the request, which makes them vulnerable. There aren't many times when you'll have enough control over a portion of the body to make non-cookie attacks viable.
- agl 14y ago
  SPDY header compression only compresses the headers. Bytes in the body might be vulnerable to a similar attack if the server is doing gzip compression, and that would be a fun extension to the attack, but headers and body are never compressed together.
honest0pinion 14y ago
I've never been attracted to SPDY as I have doing HTTP 1.1 pipelining for years before SPDY appeared. It's great for getting lots of data from the same source, though I don't know about the way typical webpages are these days with so many connections to pull-in offiste resources, many of which offer the user zero value (they benefit the site owner only). That's a problem with how people are deisgning websites. Not something that's solved with a transmission procotol. SPDY did offer a couple of new things over 1.1. SPDY wants to compress headers, but I asked "Why?" What exactly are they planning to put in the headers to make them so big they need to be compressed? Normal headers are not large. And headers can actually be quite useful after pipelining a large amount of data when you want to carve into pieces later. They are like record separators. Another new addition was de-serialization. But I see nothing wrong with receiving the data in the order I requested it. If the transmission is interrupted, at least then I can restart where I left off. I'm just not convinced compressing headers or de-serializing adds such a speed boost as to justify a new protocol. And now, with this exploit, I don't need to even think about SPDY anymore. Except has a potential security hole. Sorry SPDY fans, but this is just my opinion as a dumb end user. Pipelining worked just fine before SPDY. Alas, no one used it. Why? Maybe because it didn't have a catchy acronym and a corporate brand behind it. I honestly don't know. Because it's efficient and makes perfect sense. I used it. And I still do. I will never use SPDY, especially not now. (It's on by default in Firefox but you can disable it.)
- __alexs 14y ago
  CRIME works equally well against HTTP/TLS too when compression is enabled.
  - honest0pinion 14y ago
    "when compression is enabled" SPDY compresses everything, together, by default. CRIME relies on lots of things, one of which is a browser that makes requests for offsite resources automatically. Sure, Chrome does that, but not all broswers do, and certainly not simple http clients unless you're spidering. It's pretty easy to not be vulnerable to CRIME, but not when you use SPDY; since SPDY was compressing everything. The protocol takes away the control that the HTTP 1.1 user had through specifying desired options in headers, such as whether or not to use compression. And compression was never the default in HTTP/HTTPS. I wish that I liked SPDY. It's easier to go along with the crowd. But I just don't. IMO, it's something that should stay internal to Google and not be pushed on the rest of the web. Exactly for reasons like this exploit. It's way too easy to screw this stuff up.
LoseThosMan 14y ago
http://www.losethos.com/LTWeb/OSMain/Compress.html http://www.losethos.com/LTWeb/OSMain/Compress.html http://www.losethos.com/LTWeb/Adam/Gr/GrSpritePlot.html http://www.losethos.com/LTWeb/Adam/Gr/GrSpritePlot.html

63 points by stalled 14y ago

Interesting -- looks as though the speculation as to the nature of CRIME was pretty much dead-on. Took years for anyone to realize that compression introduced a vulnerability into HTTPS, but as soon as everyone knew that there was something there, the nature of the attack was immediately guessed. (Although I'd be much more worried if the community had discovered a different vulnerability!)

__alexs 14y ago
People have been thinking about this sort of attack since at least 2002 http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091 http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091

stalled 14y ago

(Previous discussion: http://news.ycombinator.com/item?id=4510829 http://news.ycombinator.com/item?id=4510829)

mjs 14y ago

It seems like the solution is to special case sensitive headers like "Cookie", so that the compressed version doesn't leak information. But isn't every byte equally worthy of protection? What if there's sensitive information in the body? (I get that the format of the Cookie header is probably much more structured/predictable than usernames or account details that might appear in the body, but surely a good cryptosystem would be 100% resistent to these sorts of side-channel attacks, without any need to guess which headers need to be handled more carefully.)

daeken 14y ago
This attack depends on being able to control the requests made; cookies are automatically added to the request, which makes them vulnerable. There aren't many times when you'll have enough control over a portion of the body to make non-cookie attacks viable.
agl 14y ago
SPDY header compression only compresses the headers. Bytes in the body might be vulnerable to a similar attack if the server is doing gzip compression, and that would be a fun extension to the attack, but headers and body are never compressed together.

honest0pinion 14y ago

I've never been attracted to SPDY as I have doing HTTP 1.1 pipelining for years before SPDY appeared. It's great for getting lots of data from the same source, though I don't know about the way typical webpages are these days with so many connections to pull-in offiste resources, many of which offer the user zero value (they benefit the site owner only). That's a problem with how people are deisgning websites. Not something that's solved with a transmission procotol. SPDY did offer a couple of new things over 1.1. SPDY wants to compress headers, but I asked "Why?" What exactly are they planning to put in the headers to make them so big they need to be compressed? Normal headers are not large. And headers can actually be quite useful after pipelining a large amount of data when you want to carve into pieces later. They are like record separators. Another new addition was de-serialization. But I see nothing wrong with receiving the data in the order I requested it. If the transmission is interrupted, at least then I can restart where I left off. I'm just not convinced compressing headers or de-serializing adds such a speed boost as to justify a new protocol. And now, with this exploit, I don't need to even think about SPDY anymore. Except has a potential security hole. Sorry SPDY fans, but this is just my opinion as a dumb end user. Pipelining worked just fine before SPDY. Alas, no one used it. Why? Maybe because it didn't have a catchy acronym and a corporate brand behind it. I honestly don't know. Because it's efficient and makes perfect sense. I used it. And I still do. I will never use SPDY, especially not now. (It's on by default in Firefox but you can disable it.)

__alexs 14y ago
CRIME works equally well against HTTP/TLS too when compression is enabled.
- honest0pinion 14y ago
  "when compression is enabled" SPDY compresses everything, together, by default. CRIME relies on lots of things, one of which is a browser that makes requests for offsite resources automatically. Sure, Chrome does that, but not all broswers do, and certainly not simple http clients unless you're spidering. It's pretty easy to not be vulnerable to CRIME, but not when you use SPDY; since SPDY was compressing everything. The protocol takes away the control that the HTTP 1.1 user had through specifying desired options in headers, such as whether or not to use compression. And compression was never the default in HTTP/HTTPS. I wish that I liked SPDY. It's easier to go along with the crowd. But I just don't. IMO, it's something that should stay internal to Google and not be pushed on the rest of the web. Exactly for reasons like this exploit. It's way too easy to screw this stuff up.

LoseThosMan 14y ago

http://www.losethos.com/LTWeb/OSMain/Compress.html http://www.losethos.com/LTWeb/OSMain/Compress.html http://www.losethos.com/LTWeb/Adam/Gr/GrSpritePlot.html http://www.losethos.com/LTWeb/Adam/Gr/GrSpritePlot.html