Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google disables compression for OpenSSL in Chrome - SSL exploit coming?

chromiumcodereview.appspot.com

Post reply on HN
Print view View original

41–50 of 137 posts

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#41

Post by tptacek »

sanxiyn wrote: post #38
tptacek wrote: post #26

Earlier quoted context omitted.

Can you point to an instance where you said anything like that, here or anywhere else, before last week? It's easy for me to believe that you've internalized "minimize data-dependent branches in crypto code" and thus wouldn't have designed a compressed encrypted transport. It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression.…

This paper published in 2002 does discuss this attack. http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091 "... both the SSH and TLS protocols support an option for on-the-fly compression. Potential security implications of using compression algorithms are of practical importance to people designing systems that might use both compression and encryption."

Yep. Great paper. Thanks for finding this.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#42

Post by cperciva »

tptacek wrote: post #32
ZoFreX wrote: post #30

Earlier quoted context omitted.

Note to anyone that doesn't do much crypto: You have to compress before encrypting, compressing after encrypting has no effect. (Reason: because encrypted data is [should be] indistinguishable from random data, and random data does not compress)

You're right, but again: there's advice people get to compress deliberately, not to save space in messages but to make cryptanalysis more difficult.

FWIW, that advice made more sense pre-internet, when compression formats were tighter and encryption was weaker -- the idea was that an attacker might find the key but not recognize that he successfully decrypted the data.

These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an attacker to recognize if he has the right key... and he isn't going to be running a brute-force attack anyway.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#43

Post by tptacek »

cperciva wrote: post #35
tptacek wrote: post #26

Earlier quoted context omitted.

Can you point to an instance where you said anything like that, here or anywhere else, before last week? It's easy for me to believe that you've internalized "minimize data-dependent branches in crypto code" and thus wouldn't have designed a compressed encrypted transport. It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression.…

It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression. I'm not claiming that I'd have noticed this particular attack. I'm saying that having compression in a supposedly secure transport layer was an obviously bad idea even before it was clear how it could be exploited. I don't need to get into a car accident to know that drivin…

These are things that are obvious in hindsight. They may have been obvious to you before; or, as I'm claiming, they may just fit snugly into your (probably correct) philosophy about secure channel design.

But compression in TLS is not a relic of the 1990s; it's something that looks to have gained its earliest adoption in SSL/TLS at about the same time as Elliptic Curve.

My issue here isn't that you're wrong; it's that I think this is an extremely clever attack that says something profound about designing cryptosystems, and I wouldn't want to see Thai's and Juliano's (or Pornin's, if he's "wrong" about the prediction) work minimized by a glib comment about TLS.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#44

Post by cryptbe »

Problem 1 in Stanford's crypto class [1]:

Data compression is often used in data storage or transmission. Suppose you want to use data compression in conjunction with encryption. Does it make more sense to

A. Compress the data and then encrypt the result, or

B. Encrypt the data and then compress the result.

Now we know the correct answer is Neither.

[1] http://crypto.stanford.edu/~dabo/cs255/hw_and_proj/hw1.pdf

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#45

Post by tptacek »

cperciva wrote: post #42
tptacek wrote: post #32

Earlier quoted context omitted.

You're right, but again: there's advice people get to compress deliberately, not to save space in messages but to make cryptanalysis more difficult.

FWIW, that advice made more sense pre-internet, when compression formats were tighter and encryption was weaker -- the idea was that an attacker might find the key but not recognize that he successfully decrypted the data. These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an…

Strong agree. One of the big philosophical problems in cryptographic engineering seems to be that much of it was designed to address data-at-rest, but most of the practical problems are about data-in-motion, and those are two different problems.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#46

Post by tlb »

cperciva wrote: post #25
tptacek wrote: post #22

Earlier quoted context omitted.

What, compressing before encrypting?

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

You'd have the same problem if HTTP supported compression of the request headers & body. It's because it only supports compression of the response body that there isn't any leakage already.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#47

Post by tptacek »

zurn wrote: post #40
cperciva wrote: post #25

Earlier quoted context omitted.

Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.

The excuses I've heard for it include 1) can't do compression after the crypto, and 2) it reduces ciphertext available to attackers. SSH and PGP do it too.

What it does is eliminate the structure of the plaintext. Lots of practical crypto implementation attacks depend on plaintext structure, especially in their most naive and straightforward implementations.

A conceptual purist like Colin Percival would argue, correctly, that if there's an attack against a cryptosystem that benefits from knowing the distribution of bytes in the plaintext, that's a damning statement about the cryptosystem itself.

But compression does "break" some exploits.

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#48

Post by cperciva »

tptacek wrote: post #43
cperciva wrote: post #35

Earlier quoted context omitted.

It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression. I'm not claiming that I'd have noticed this particular attack. I'm saying that having compression in a supposedly secure transport layer was an obviously bad idea even before it was clear how it could be exploited. I don't need to get into a car accident to know that drivin…

These are things that are obvious in hindsight. They may have been obvious to you before; or, as I'm claiming, they may just fit snugly into your (probably correct) philosophy about secure channel design. But compression in TLS is not a relic of the 1990s; it's something that looks to have gained its earliest adoption in SSL/TLS at about the same time as Elliptic Curve. My issue here isn't that you're wrong; it's tha…

compression [...] looks to have gained its earliest adoption in SSL/TLS at about the same time as Elliptic Curve

I guess by that point they had thrown in everything but the kitchen sink, and decided they might as well throw in the kitchen sink too.

I wouldn't want to see Thai's and Juliano's (or Pornin's, if he's "wrong" about the prediction) work minimized by a glib comment about TLS.

Oh, of course. I'm just irritated (as usual) by the fact that people continue to use SSL/TLS "because it's the standard" despite the fact that it's a phenomenally broken standard. There's places where you can't avoid it (HTTPS), but where it can be avoided...

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#49

Post by tlrobinson »

Reflejo wrote: post #34

Relevant: http://www.ekoparty.org/2012/juliano-rizzo.php

"The good news is we've got working patches for most of the issues. The bad news is some of them might contribute to global warming"

Disabling compression could certainly contribute to global warming in a relatively small way...

Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?

#50

Post by tptacek »

cryptbe wrote: post #37
nitrogen wrote: post #4

Earlier quoted context omitted.

Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.

> Hollywood "guess the password one character at a time" animations Did you see the BEAST attack? Exactly one byte at a time: http://www.youtube.com/watch?v=BTqAIDVUvrU

Serge Vaudenay's CBC padding oracle attack plays out the same way, as does the simplest attack on ECB mode crypto.
Post reply on HN