HTTTP/2 (D)DoS prevention

[krizhanovsky]

HTTTP/2 flood prevention

Low-Rate Denial-of-Service Attacks against HTTP/2 Services paper studies HTTP/2 floods using PING and WINDOW_UPDATE frames. It's not good to fight against the attacks using packet rate limit since a client can send large POST requests for example. From the other hand requests rate in such attacks could be zero. So a new limits with burst, just the same as for current request limiting, must be developed.

It makes sense to apply the limit to service frames only since HEADERS and DATA obey existing HTTP request limits. We can limit all the service frames at once, there is no need to limit them separately.

HTTTP/2 slow read

Slow Read Attack (CVE-2016-1546) uses many concurrent streams with little window updates, so

1. The HTTP limits must be extended by stream_rate, stream_burst and concurrent_streams just similar to equal connection limits.

2. response_timeout limit must be introduced for both the HTTP/1 and HTTP/2. The limit specifies how long we can be sending a given response to a client. To not to rate limit valid Comet responses one must specify the limit for vhosts other than servicing Comet resources.

HPACK bomb

Huffman decoding is an expensive operation and we must check http_field_len Frang limit before Huffman decoding execution (see also HPACK bomb). Considering implementation variants - it seems that the simplest and most effective way is to embed a hook into HTTP/2-parser (or into HPACK-decoder) directly to catch the long headers immediately.

Also see corresponding TODO comment for __frang_http_field_len() in http_limits.c - we should do the same for HTTP/1.

We have separate issue for this #1780

Header list size limit

HTTP limiting module provides important for HTTP/2 security limit http_header_cnt. According to RFC 7540 chapters 10.5.1 and 6.5.2 having the limit set, Tempesta should send SETTINGS_MAX_HEADER_LIST_SIZE settings parameter to a client.

Testing

• HTTP/2 streams rate limit to prevent HTTP/2 slow read. See #88
• HTTP/2 frames rate limit to prevent HTTP/2 floods. See #88

Test to reproduce for concurrent streams.

Documentation

Please update https://github.com/tempesta-tech/tempesta/wiki/HTTP-security#frang-security-limits-enforcing-module with the reference to the paper.

[RomanBelozerov]

The HTTP limits must be extended by stream_rate, stream_burst and concurrent_streams just similar to equal connection limits.

Tempesta should send SETTINGS_MAX_CONCURRENT_STREAMS in SETTINGS frame when initializing connection with client.

Please enable http2_general.test_h2_streams.TestH2Stream.test_max_concurrent_stream test after fixes