HPACK vulnerabilities #373

Closed
martinthomson opened this Issue Jan 31, 2014 · 2 comments

Comments

Projects
None yet
3 participants
Member

martinthomson commented Jan 31, 2014

Analysis suggests that there might be some issues with HPACK that at least need documenting.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0233.html

The most serious concern is the use of reference sets or the header table to confirm guesses about header contents. This doesn't require a server oracle, which reduces the potential cost to an attacker.

This isn't constant time like CRIME, but there are headers with low entropy secrets out there (basic auth, for example). Thus, we need to be very cautious about this. It may be that in a browser, the only way we are able to mitigate this is to prevent use of the header table for requests that are controlled by different origins.

enygren commented Mar 3, 2014

As part of this we should also consider the risks of HPACK if multiple schemes are allowed on a single connection (which may just be another reason to be careful when mixing schemes, especially http and https).

Owner

mnot commented Mar 5, 2014

Discussed in London; agreed to have a single bit in the header format indicating that it can't be compressed, and add Security Considerations about this attack, with potential options.

@mnot mnot added the editor-ready label Mar 5, 2014

@mnot mnot added this to the Fourth Implementation Draft milestone Mar 5, 2014

hruellan pushed a commit that referenced this issue Mar 31, 2014

Adds 'uncompressable' headers.
Targets format part of #373.

@hruellan hruellan closed this in f4ec4e3 Mar 31, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment