HPACK Security Considerations

[martinthomson]

I have written what I think is a slightly more robust Security Consideration for HPACK. This covers:

• the attack in the general sense,
• how the attack might apply in HPACK and HTTP,
• particular areas of concern,
• how HPACK inherently mitigates these attacks,
• what environments might need additional mitigation, and
• some suggested mitigation strategies.

Mitigation strategies that I have described are:

• actor-based isolation (a generalized application of the origin isolation principle)
• destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess
• specific protection for "special" header fields

There are a few formatting changes in the first commit, sorry.

[hruellan]

I'm not sure I fully understand the limit set by SETTINGS_MAX_CONCURRENT_STREAMS.
For a passive attacker, once this number of requests has been reached, it needs for response to be sent and streams to be closed before having the client make new requests. This slows down the attack but may not help detecting it (its more the total number of requests, the similarity of the requests, and/or the changes in the probed value that would hint that an attack is under way).
For an active attacker, blocking packets, it could sent fake answers to close the requests, allowing more to be done. Here the client would have to detect that something is suspicious, probably by using the strategies described in the Mitigation section below.

I see three possibilities:

• Removing this paragraph entirely
• Making clear why there is a limit imposed by SETTINGS_MAX_CONCURRENT_STREAMS
• List the suspicious behaviour that could help detecting an attack is under way.

[martinthomson]

Yes, this is fairly tricky, and I'm not sure how to best explain this one. It is important though. One of the key considerations in any attack of this sort is whether the attack can be detected. If it can be detected, then measures can be taken.

In this attack, the attacker allows for the header table to be primed without interference from the attacker, allowing packets to pass normally. Then, when they start guessing, they block further progress, which does not prevent a client from initiating more requests, until they reach SETTINGS_MAX_CONCURRENT_STREAMS, after which the client needs to receive feedback from the server to continue.

I also just realized that this limit is only effective for client-based attacks. An attack by a server is limited only to 2^30 attempts, since PUSH_PROMISE isn't limited in the same way.

Note also that the TCP congestion window doesn't limit the attack, because the attacker can forge TCP acknowledgements.

I will expand on this.