3 ms·
I believe that qpack(like hpack) still has some sharp edges. As in...low entropy headers are still vulnerable to leakage via a CRIME[0] style attack on the HTTP
by d-z-m 3y ago
I believe that qpack(like hpack) still has some sharp edges. As in...low entropy headers are still vulnerable to leakage via a CRIME[0] style attack on the HTTP/3 header compression.
In practice, high entropy headers aren't vulnerable, as an attacker has to match the entire header:value line in order to see a difference in the compression ratio[1].
[0]: https://en.wikipedia.org/wiki/CRIME https://en.wikipedia.org/wiki/CRIME
[1]: https://www.ietf.org/archive/id/draft-ietf-quic-qpack-20.html#section-7 https://www.ietf.org/archive/id/draft-ietf-quic-qpack-20.htm...
- RenThraysk 3y agoGiven that Qpack has a dedicated stream for dynamic table updates, can atleast limit which header:value combinations are inserted. And there are bit flags in the encoder instructions that carry header values that signal they should never be inserted into a dynamic table.
- d-z-m 3y ago> And there are bit flags in the encoder instructions that carry header values that signal they should never be inserted into a dynamic table. My understanding is that these header values have to be known to the Qpack implementation beforehand. As a result, it isn't possible for an HTTP/3 client to signal to Qpack to treat a particular custom header as a never-indexed literal.