3 ms·

I know this may be a bit off-topic, but since we're discussing HTTP/2 already, I can't help but wonder. The recent attacks (BEAST, CRIME, etc.) have all relied

by bostik 13y ago

I know this may be a bit off-topic, but since we're discussing HTTP/2 already, I can't help but wonder. The recent attacks (BEAST, CRIME, etc.) have all relied on being able to build an oracle from (sent) body content and uncover header elements. The attacks only get better in time, so I expect to see even more attacks like this. If we're going to overhaul the HTTP spec in any case and go for framed messaging - why not go for separate header/body compression AND separate encryption keys? As far as I understand, that would block the whole family of attacks. Separate compression contexts would prevent the attacker from building an oracle from body to attack the header. Separate keys and encryption contexts should prevent padding and mode oracles against the header. I know crypto is hard, and I know there would be devilishly tricky details to figure out. So I have to assume someone has already thought of this, has had it vetted out for flaws and then discarded the idea. But if so, why? Apart from requiring at least twice the key size in negotiation (compute oversized shared key, split for header/body and likely HMAC keys), are there any other obvious or non-obvious technical reasons not to do this?

AnthonyMouse 13y ago
I think the focus on the dichotomy between the header and the body is misguided. If you separate them then an attacker can't attack the header using the body, but that's just inviting the attacker to find a way to insert data into the header to attack other header fields, or find secrets in the body that shouldn't be revealed. Also, it seems like you could get the same benefit as using a separate key and encryption context by just padding the header to a block boundary. The real problem with these attacks is that they aren't attacks on the cipher at all. You could be using a one time pad and the attacks would still be effective. What they really are is an attack on content-revealing efficiency. The only defense is to prevent the length of the message from depending on the existence of matches between attacker-supplied plaintext and secrets, and doing that in a way that allows non-cryptographer web developers to not screw it up basically comes down this: You have to disable TLS protocol compression. It exists at the wrong layer of abstraction because the TLS layer doesn't know what data is acceptable to compress against what other data. But you still want to use compression, so the compression has to exist at a higher level in the stack, i.e. in HTTP or even HTML, where the web developer can specify exactly which data has come from an untrustworthy source so that it won't be compressed against secrets.

by bostik 13y ago

AnthonyMouse 13y ago

I think the focus on the dichotomy between the header and the body is misguided. If you separate them then an attacker can't attack the header using the body, but that's just inviting the attacker to find a way to insert data into the header to attack other header fields, or find secrets in the body that shouldn't be revealed. Also, it seems like you could get the same benefit as using a separate key and encryption context by just padding the header to a block boundary. The real problem with these attacks is that they aren't attacks on the cipher at all. You could be using a one time pad and the attacks would still be effective. What they really are is an attack on content-revealing efficiency. The only defense is to prevent the length of the message from depending on the existence of matches between attacker-supplied plaintext and secrets, and doing that in a way that allows non-cryptographer web developers to not screw it up basically comes down this: You have to disable TLS protocol compression. It exists at the wrong layer of abstraction because the TLS layer doesn't know what data is acceptable to compress against what other data. But you still want to use compression, so the compression has to exist at a higher level in the stack, i.e. in HTTP or even HTML, where the web developer can specify exactly which data has come from an untrustworthy source so that it won't be compressed against secrets.