3 ms·

One surprising thing about HTTP/3 is that QPACK (the compression algorithm used to transmit HTTP fields) has a static Huffman table based on the most common hea

One surprising thing about HTTP/3 is that QPACK (the compression algorithm used to transmit HTTP fields) has a static Huffman table based on the most common header values [1]! The other day I was implementing a HTTP/3 client and I wanted to test the header encoding, so I just sent an example value "content-type: text/plain" and checked the output. The entire header was just 3 bytes! I then spent an hour looking for bugs in my code, as I assumed there must be a problem with it as no regular compression algorithm can compress text that much. Then I finally opened the IETF draft and discovered the table there. So yeah, it's a compression algorithm that's really specifically geared towards HTTP. [1]: https://greenbytes.de/tech/webdav/draft-ietf-quic-qpack-15.html#static-huffman-encoding https://greenbytes.de/tech/webdav/draft-ietf-quic-qpack-15.h...

tialaramex 4y ago
As the link you provided implies (it's in the Security Considerations section of the document) this decision also prevents QPACK becoming an effective Oracle. Attacks like CRIME or BREACH abuse compression with dynamic behaviour as an Oracle. The attacker can't see the secret token, but they can send arbitrary data over the wire with the secret token and the dynamic compression will adjust based on the attacker's inputs and the secret token, changing the compressed data size. Over many iterations they can learn what the token must be this way, but QPACK effectively defeats that, for HTTP/3 headers, while still delivering compression (you can of course also defeat these Oracle attacks by never using compression).
zasdffaa 4y ago
Does this kind of header compression mean anything of value, am asking seriously. I'm not an HTTP person but typically I'd expect the body to dwarf the header, and if you are doing many small requests such that the header is larger then the rest, then I wonder if maybe that's not the right way. If header compression is worth anything much then ok, if it isn't then why might it be being done.
- ThePhysicist 4y ago
  I think so, it really save a lot of bandwidth as almost all HTTP requests have multiple of these common headers encoded in the Huffman table.

tialaramex 4y ago

As the link you provided implies (it's in the Security Considerations section of the document) this decision also prevents QPACK becoming an effective Oracle. Attacks like CRIME or BREACH abuse compression with dynamic behaviour as an Oracle. The attacker can't see the secret token, but they can send arbitrary data over the wire with the secret token and the dynamic compression will adjust based on the attacker's inputs and the secret token, changing the compressed data size. Over many iterations they can learn what the token must be this way, but QPACK effectively defeats that, for HTTP/3 headers, while still delivering compression (you can of course also defeat these Oracle attacks by never using compression).

zasdffaa 4y ago

Does this kind of header compression mean anything of value, am asking seriously. I'm not an HTTP person but typically I'd expect the body to dwarf the header, and if you are doing many small requests such that the header is larger then the rest, then I wonder if maybe that's not the right way. If header compression is worth anything much then ok, if it isn't then why might it be being done.

ThePhysicist 4y ago
I think so, it really save a lot of bandwidth as almost all HTTP requests have multiple of these common headers encoded in the Huffman table.