rfc9931v1.txt   rfc9931.txt 
Internet Engineering Task Force (IETF) B. Schwartz Internet Engineering Task Force (IETF) B. Schwartz
Request for Comments: 9931 Meta Platforms, Inc. Request for Comments: 9931 Meta Platforms, Inc.
Updates: 9112, 9298 February 2026 Updates: 9112, 9298 March 2026
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
Abstract Abstract
In HTTP/1.1, the client can request a change to a new protocol on the In HTTP/1.1, the client can request a change to a new protocol on the
existing connection. This document discusses the security existing connection. This document discusses the security
considerations that apply to data sent by the client before this considerations that apply to data sent by the client before this
skipping to change at line 110 skipping to change at line 110
In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for
many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these
requests can be multiplexed, as each request is distinguished requests can be multiplexed, as each request is distinguished
explicitly by its stream ID. However, in HTTP/1.1, requests are explicitly by its stream ID. However, in HTTP/1.1, requests are
strictly sequential, and each new request is distinguished implicitly strictly sequential, and each new request is distinguished implicitly
by the closure of the preceding request. by the closure of the preceding request.
HTTP/1.1 is also the only version of HTTP that allows the client to HTTP/1.1 is also the only version of HTTP that allows the client to
change the protocol used for the remainder of the connection. There change the protocol used for the remainder of the connection. There
are two mechanisms to request such a protocol transition. One are two mechanisms to request such a protocol transition. One
mechanism is the Upgrade request header field ([HTTP], Section 7.8), mechanism is the Upgrade header field ([HTTP], Section 7.8). When
which indicates that the client would like to use this connection for included in a request, this field indicates that the client would
a protocol other than HTTP/1.1. The server replies with a 101 like to use this connection for a protocol other than HTTP/1.1. The
(Switching Protocols) status code if it accepts the protocol change server replies with a 101 (Switching Protocols) status code if it
([HTTP], Section 15.2.2). accepts the protocol change ([HTTP], Section 15.2.2).
The other mechanism is the HTTP CONNECT method (Section 9.3.6 of The other mechanism is the HTTP CONNECT method (Section 9.3.6 of
[HTTP]). This method indicates that the client wishes to establish a [HTTP]). This method indicates that the client wishes to establish a
TCP connection to the specified host and port. If accepted, the TCP connection to the specified host and port. If accepted, the
server replies with a 2xx (Successful) response to indicate that the server replies with a 2xx (Successful) response to indicate that the
request was accepted and a TCP connection was established. After request was accepted and a TCP connection was established. After
this point, the TCP connection is acting as a TCP tunnel, not an this point, the TCP connection is acting as a TCP tunnel, not an
HTTP/1.1 connection. HTTP/1.1 connection.
Both of these mechanisms also permit the server to reject the Both of these mechanisms also permit the server to reject the
skipping to change at line 205 skipping to change at line 205
4. Possible Security Issues 4. Possible Security Issues
When there are only two distinct parties involved in an HTTP/1.1 When there are only two distinct parties involved in an HTTP/1.1
connection (i.e., the client and the server), protocol transitions connection (i.e., the client and the server), protocol transitions
introduce no new security issues: Each party must already be prepared introduce no new security issues: Each party must already be prepared
for the other to send arbitrary data on the connection at any time. for the other to send arbitrary data on the connection at any time.
However, HTTP connections often involve more than two parties if the However, HTTP connections often involve more than two parties if the
requests or responses include third-party data. For example, a requests or responses include third-party data. For example, a
browser (party 1) might send an HTTP request to an origin (party 2) browser (party 1) might send an HTTP request to an origin (party 2)
with the path, headers, or content controlled by a website from a with the path, headers, or content controlled by a website from a
different origin (party 3). Post-transition protocols such as different origin (party 3). Post-transition protocols, such as
WebSocket [WEBSOCKET] similarly are often used to convey data chosen WebSocket [WEBSOCKET], are also frequently used to convey data chosen
by a third party. by a third party.
If the third-party data source is untrusted, then the data it If the third-party data source is untrusted, then the data it
provides is potentially "attacker-controlled". The combination of provides is potentially "attacker-controlled". The combination of
attacker-controlled data and optimistic protocol transitions results attacker-controlled data and optimistic protocol transitions results
in two significant security issues. in two significant security issues.
4.1. Request Smuggling 4.1. Request Smuggling
In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the
skipping to change at line 419 skipping to change at line 419
behaviors are vulnerable to a trivial Request Smuggling attack behaviors are vulnerable to a trivial Request Smuggling attack
([HTTP/1.1], Section 11.2). ([HTTP/1.1], Section 11.2).
At the time of writing, some proxy clients are believed to be At the time of writing, some proxy clients are believed to be
vulnerable as described. As a mitigation, proxy servers MUST close vulnerable as described. As a mitigation, proxy servers MUST close
the underlying connection when rejecting a CONNECT request without the underlying connection when rejecting a CONNECT request without
processing any further requests on that connection. This requirement processing any further requests on that connection. This requirement
applies whether or not the request includes a "close" connection applies whether or not the request includes a "close" connection
option. option.
Note that this mitigation will frequently impair the performance of Note that this mitigation will frequently cause slower connection
correctly implemented clients, especially when returning a 407 (Proxy establishment for correctly implemented clients, especially when
Authentication Required) response. This performance loss can be returning a 407 (Proxy Authentication Required) response. This
avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this performance loss can be avoided by using HTTP/2 or HTTP/3, which are
attack. not vulnerable to this attack.
As a performance optimization, proxy servers MAY disable this As a performance optimization, proxy servers MAY disable this
mitigation if the client is known to wait for a 2xx (Successful) mitigation if the client is known to wait for a 2xx (Successful)
response before forwarding untrusted TCP payload data (i.e., response before forwarding untrusted TCP payload data (i.e.,
complying with item 1 above). Proxy servers can identify compliant complying with item 1 above). Proxy servers can identify compliant
clients using the request's User-Agent header field and the user clients using the request's User-Agent header field and the user
agent vendor's documentation regarding its compliance. agent vendor's documentation regarding its compliance.
9. Security Considerations 9. Security Considerations
 End of changes. 4 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48.