3 ms·
The paper goes on to describe why. The short version is a big part of HTTP/2's performance comes from header compression via the HPACK algorithm. Anything that
by rubiquity 10y ago
The paper goes on to describe why. The short version is a big part of HTTP/2's performance comes from header compression via the HPACK algorithm. Anything that compresses can be compromised if the attacker can inject data into the compressed output. This paper does a really nice job of concisely explaining BREACH and CRIME.
- Animats 10y agoThere's a provision in RFC 7541 that applies here. There's a way to indicate that a header field must not be compressed. Security-critical header fields such as keys and nonces should not be compressed. The RFC notes: "Note that these criteria for deciding to use a never-indexed literal representation will evolve over time as new attacks are discovered." So the protocol has a feature for this. Everything that sends HTTP2 needs to update the list of fields not to compress, but that can be done by the sending end without any change to the receiving end. [1] https://tools.ietf.org/html/rfc7541#section-7.1.3 https://tools.ietf.org/html/rfc7541#section-7.1.3
- cperciva 10y ago"Note that these criteria for deciding to use a never-indexed literal representation will evolve over time as new attacks are discovered." Or, in other words: "We know that this is insecure. Maybe someone will fix it later."
- madgar 10y agoThat casual dismissal can be applied just as casually to the entire history of networking technologies, and it would be just as lazy and intellectually dishonest.
- Animats 10y agoTrue, but the HTTP/2 people were building a wrapper for data, not a security protocol. At least they put in a feature to suppress compression. Because of that, this can be fixed from one end; it's not necessary to deploy new browsers.