Yes. See: http://security.stackexchange.com/a/19914
Compressed Redundancy in Message Exploit?
Compression Reveals Information Meant (to be) Encrypted?
Google disables compression for OpenSSL in Chrome - SSL exploit coming?
51–60 of 137 posts
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#52Yes. See: http://security.stackexchange.com/a/19914
Interesting. The attacker would also need to push the request size up to the next block boundary, but it should work.
At least we can still do compression at the HTTP (or other higher-level protocol) level. That gets us most of the benefit anyway.
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#53Earlier quoted context omitted.
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 irritat…
Your perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is poorly designed.
My perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is the most carefully studied cryptosystem in human history.
I agree to disagree with you on this.
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#54Does the attack apply to SPDY as well?
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#55Yes. See: http://security.stackexchange.com/a/19914
Heh, anyone else notice the proposed attack strongly resembles Level 8 in the last Stripe CTF?
That Stripe CTF was deceptively excellent. If you (the reader of this comment) got through it and had fun, I promise, we'd be both interested to talk to you and an interesting company for you to talk to. www.matasano.com/careers.
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#56Earlier quoted context omitted.
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 irritat…
Your perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is poorly designed. My perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is the most carefully studied cryptosystem in human history. I agree to disagree with you on this.
My perspective is that we know how to design protocols which are provably secure.
Your perspective is... I'm not quite sure, actually. Maybe you just don't believe in mathematical proofs?
As you say, agree to disagree -- but I'm not going to stop pointing and laughing every time a new SSL/TLS vulnerability comes out. :-)
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#57Yes. See: http://security.stackexchange.com/a/19914
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.
You also need the client and server to both support TLS compression. But there aren't any major sites (that I know of) which do support TLS compression.
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#58Earlier quoted context omitted.
What, compressing before encrypting?
Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.
What's the issue with that ? Isn't it possible to design a compression algorithm that is efficient and less predictable at the same time ? Or is it more of a general concept that I don't know of ?
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#59Earlier quoted context omitted.
Your perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is poorly designed. My perspective on HTTPS/TLS is that it has a history of vulnerabilities because it is the most carefully studied cryptosystem in human history. I agree to disagree with you on this.
My perspective is that we know how to design protocols which are provably secure. Your perspective is... I'm not quite sure, actually. Maybe you just don't believe in mathematical proofs? As you say, agree to disagree -- but I'm not going to stop pointing and laughing every time a new SSL/TLS vulnerability comes out. :-)
That protocols without security proofs can survive in the real world, and protocols with security proofs still fall to implementation bugs, and that if you were going to bet on incidence of protocol design flaws vs. implementation flaws, the safe bet is on implementation flaws.
Re: Google disables compression for OpenSSL in Chrome - SSL exploit coming?
#60Problem 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
If you're encrypting and storing files, the answer is (A). The question is, in light of this result, frustratingly imprecise.