10. Security Considerations
10.1. Server Authority
HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is authoritative in providing a given response (see Section 17.1 of [HTTP]). This relies on local name resolution for the "https" scheme and the authenticated server identity for the "https" scheme (as defined in Section 4.2.2 of [HTTP]). Alternative services ([ALT-SVC]) used to establish authority might introduce considerable additional complexity.
10.2. Cross-Protocol Attacks
In TLS, HTTP/2 uses the Application-Layer Protocol Negotiation (ALPN) extension [TLS-ALPN] to negotiate the use of the protocol. This creates a positive signal that the server supports HTTP/2 and reduces exposure of HTTP/2 to cross-protocol attacks.
However, in cleartext or where ALPN is not used in TLS, the HTTP/2 client connection preface (Section 3.4) could be confused with other protocols. The HTTP/2 connection preface is designed to minimize this possibility by selecting a sequence that is unlikely to be a valid start for other protocols.
Any protocol that is accessible to an HTTP/2 endpoint can be used to establish what appears to be a valid HTTP/2 connection. For this reason, the connection preface received by a server-side endpoint needs to be valid for the protocol to form a cross-protocol attack.
The client connection preface (Section 3.4) is not sufficient to ensure that the protocol is not confused, but it provides some protection. HTTP/2 client implementations might also need to perform additional checks before applying HTTP semantics. In particular, clients need to ensure that the initial response is a legitimate response to a message the client sent.
A server could attack a client by sending a request to a target server that the client wanted to send to a different server. If the receiving server supports an HTTP scheme other than HTTP/2, the server can read and echo a request sent to another server. An attacker can intercept and modify the response that the client receives, causing the client to associate information in the response with a response to a request that it does not belong to.
10.3. Intermediary Encapsulation Attacks
The HTTP/2 field encoding allows the expression of field names and values that are not valid field names and values in HTTP/1.1 or that cannot be expressed in HTTP/1.1. Requests or responses containing invalid field names or values cause implementations that perform insufficient validation on field names and values to become vulnerable. An attacker might be able to use an intermediary to encapsulate a request or response such that an invalid message appears valid.
An HTTP/2 to HTTP/1.1 translator that does not fully validate requests and responses might allow a malicious client to smuggle field values or create fields with misleading field names.
10.4. Cacheability of Pushed Responses
Pushed responses do not have an explicit request from a client; the request is provided by the server in a PUSH_PROMISE frame.
Caching pushed responses can be problematic. Depending on the information used to establish the connection, a pushed response might be inadvertently made available to a new client that shares the connection but unintentionally requested the resource.
For instance, in the case of using TLS for authentication, a malicious client could receive a pushed response about sensitive information of an authenticated user using the same connection.
Servers MUST only include values that are cacheable in requests that are pushed (see Section 9.2.3 of [HTTP]); pushed requests do not include values for request content. Pushed responses are marked as uncacheable by including a Cache-Control header field containing the no-cache or private cache response directive (see Section 5.2.2.4 of [HTTP-CACHING]).
If the same pushed response can be provided for responses that are both cacheable and uncacheable, clients might incorrectly cache the pushed response using the cacheable response.
Therefore, servers SHOULD include a Cache-Control header field with a value of "no-cache" in the HEADERS frame of a pushed stream, unless there is an explicit signal indicating that the client is caching the response.
10.5. Denial-of-Service Considerations
The use of HTTP/2 introduces several new denial-of-service (DoS) opportunities.
10.5.1. Limits on Field Section Size
A field section containing a large number of fields or long field names or values can cause an implementation to consume excessive amounts of memory, CPU time, or both.
Implementations SHOULD impose limits on the total number and size of field lines they will accept and the total number and size they will send, thereby limiting the total size of the frames that comprise a field section. Servers might wish to maintain a whitelist of field lines, and clients might want to reject field lines, but both SHOULD log and take into account limits that might hamper interoperability.
10.5.2. CONNECT Issues
The CONNECT method can be used to create a connection for untrusted destinations. The TCP connection for CONNECT is not subject to control, and it could attempt to connect to endpoints or other devices, creating a connection flood. Implementations SHOULD set limits on the destinations that are permitted as CONNECT targets, and SHOULD log these limits.
10.5.3. Use of Compression
Compression of field blocks in HTTP/2 relies on algorithms and state that can be used by an attacker to cause denial of service.
An attacker can send requests with carefully crafted fields to create a field section that requires large amounts of decoder resources. This can be done by using large amounts of Huffman-encoded strings or by making many updates to the dynamic table. Immediately starting a new field section after terminating one (e.g., empty DATA frames followed by a HEADERS frame) could also be used to limit decoder resources available.
Similar attacks can be sent to aggressively use the field section compression state to create responses that require large amounts of encoder resources.
Implementations SHOULD set limits on the size of the fields they decompress.
10.5.4. Use of Flow Control
Flow control in HTTP/2 allows an adversary to limit the amount of data a peer can send. The implementation of window updates or flow control window management could cause streams to not gain available window, making the stream unable to make progress.
10.5.5. Use of Settings
A SETTINGS frame can be used to cause a peer to expend additional processing time. This might be done by pointless changing of settings, sending SETTINGS frames without changing any settings, or changing settings frequently.
Other SETTINGS parameters that limit values might be used to consume resources, such as disabling the HPACK dynamic table by setting a very small value for the SETTINGS_HEADER_TABLE_SIZE parameter.
Endpoints SHOULD detect these behaviors and treat them as a connection error (Section 5.4.1) of type ENHANCE_YOUR_CALM.
10.5.6. Use of Priorities
Priorities might be used to cause a peer to expend excessive resources. Frequent changes to the priority tree or unreasonable complexity in priority trees can both result in excessive CPU consumption.
10.5.7. Use of HTTP/2 Without TLS
HTTP/2 can be deployed without using TLS. This mode has the same vulnerabilities to certain attacks as HTTP/1.1. Implementations that use this mode of operation SHOULD apply protections applicable to HTTP/1.1.
Implementations also need to be aware that many HTTP/2 features might be more vulnerable to attacks without TLS. In particular, the absence of confidentiality protection and integrity protection provided by TLS means that encryption or integrity of the data is at risk.
10.6. Use of Compression
Compression can allow an attacker to recover secret contents of encrypted communication when that compression is combined with data that is controlled by an attacker and secret data that the attacker can observe the transmission size of.
HTTP/2 provides compression in several places: field blocks use HPACK [COMPRESSION], and the contents of DATA frames can use content coding (see Section 8.4.1 of [HTTP]).
HPACK is designed to make exploiting disclosure of secrets more difficult; however, the trade-off between implementation choices or application protections that can be realized in some cases is imperfect. Attacks can exploit the reuse of field compression state across multiple requests. Implementations and applications can choose to limit the amount of compression state used across requests to improve protection, but at the cost of increasing the size of messages.
Compressing the contents of DATA frames is generally considered safer because the contents of DATA frames are less likely to be mixed with attacker-controlled data across multiple requests. However, compression content coding combines information from different origins. Although using a different origin identifier distinguishes information from different sources (see Section 11.5 of [HTTP]), compression can remove these separators, as described in [BREACH].
Disabling or limiting compression for content coding is generally considered sufficient for mitigating these attacks, but this might not be adequate to prevent all attacks.
10.7. Use of Padding
Padding can be used to obscure the exact size of frame and message content. Padding can be used to mitigate attacks that rely on using traffic analysis to infer information about messages, which is of particular importance for HTTP, where the length of compressed messages might reveal information about the content they contain.
One example of using padding would be to send a large number of HEADERS and DATA frames with payload sizes that vary between frames to obscure the exact size of a message. Using padding can reduce some attacks (e.g., [BREACH]).
In general, the existence of traffic analysis attacks means that padding to a fixed size for every field or frame is insufficient to provide protection. To be efficient and provide some level of protection, padding SHOULD be chosen randomly.
Padding is not a perfect protection for obscuring message size. An attacker might be able to use statistical properties about the size of messages, which could allow an attacker to use the length of messages, whether padded or not, to infer information about the content with some probability.
10.8. Privacy Considerations
Several characteristics of HTTP/2 provide an observer an opportunity to correlate a set of requests. These include the value of settings, the compression context for field blocks, management of the flow control window, and the timing of messages arriving.
In particular, HTTP fields containing information about user identity can be correlated with other communications, even when using different servers.
HTTP/2 does not provide specific mechanisms to protect user privacy.
Chapter 10 complete!
References
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"