Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
draft-ietf-httpbis-optimistic-upgrade-01

HTTPBIS                                                   B. M. Schwartz
Internet-Draft                                      Meta Platforms, Inc.
Updates: 9298 (if approved)                              21 October 2024
Intended status: Standards Track                                        
Expires: 24 April 2025

Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
                draft-ietf-httpbis-optimistic-upgrade-01

Abstract

   In HTTP/1.1, the client can request a change to a new protocol on the
   existing connection.  This document discusses the security
   considerations that apply to data sent by the client before this
   request is confirmed, and updates RFC 9298 to avoid related security
   issues.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-
   upgrade/.

   Source for this draft and an issue tracker can be found at
   https://github.com/httpwg/http-extensions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 April 2025.

Schwartz                  Expires 24 April 2025                 [Page 1]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Possible Security Issues  . . . . . . . . . . . . . . . . . .   4
     3.1.  Request Smuggling . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Parser Exploits . . . . . . . . . . . . . . . . . . . . .   5
   4.  Operational Issues  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Impact on HTTP Upgrade with Existing Upgrade Tokens . . . . .   6
     5.1.  "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  "WebSocket"/"websocket" . . . . . . . . . . . . . . . . .   6
     5.3.  "connect-udp" . . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  "connect-ip"  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Guidance for Future Upgrade Tokens  . . . . . . . . . . . . .   7
     6.1.  Selection of Request Methods  . . . . . . . . . . . . . .   8
   7.  Guidance for HTTP CONNECT . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Schwartz                  Expires 24 April 2025                 [Page 2]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

2.  Background

   In HTTP/1.1, a single connection is often used for many requests, one
   after another.  After each request, the connection is returned to its
   initial state, ready to send more HTTP requests.  However, HTTP/1.1
   also contains two mechanisms that allow the client to change the
   protocol used for the remainder of the connection.

   One such mechanism is the "Upgrade" request header field ([RFC9110],
   Section 7.8), which indicates that the client would like to use this
   connection for a protocol other than HTTP/1.1.  The server replies
   with a "101 (Switching Protocols)" status code if it accepts the
   protocol change.

   The other mechanism is the HTTP "CONNECT" method.  This method
   indicates that the client wishes to establish a TCP connection to the
   specified host and port.  The server replies with a 2xx (Successful)
   response to indicate that the request was accepted and a TCP
   connection was established.  After this point, the TCP connection is
   acting as a TCP tunnel, not an HTTP/1.1 connection.

   Both of these mechanisms also permit the server to reject the
   request.  For example, [RFC9110] says:

      A server MAY ignore a received Upgrade header field if it wishes
      to continue using the current protocol on that connection.

   and

      A server MUST reject a CONNECT request that targets an empty or
      invalid port number, typically by responding with a 400 (Bad
      Request) status code.

   Rejections are common, and can happen for a variety of reasons.  An
   "upgrade" request might be rejected if:

   *  The server does not support any of the client's indicated Upgrade
      Tokens (i.e., the client's proposed new protocols), so it
      continues to use HTTP/1.1.

   *  The server knows that an upgrade to the offered protocol will not
      provide any improvement over HTTP/1.1 for this request to this
      resource, so it chooses to respond in HTTP/1.1.

   *  The server requires the client to authenticate before upgrading
      the protocol, so it replies with the status code "401
      (Authentication Required)" and provides a challenge in an
      "Authorization" response header ([RFC9110], Section 11.6.2).

Schwartz                  Expires 24 April 2025                 [Page 3]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

   *  The resource has moved, so the server replies with a 3XX redirect
      status code ([RFC9110], Section 3.4).

   Similarly, a CONNECT request might be rejected if:

   *  The server does not support HTTP CONNECT.

   *  The specified destination is not allowed under server policy.

   *  The destination cannot be resolved, is unreachable, or does not
      accept the connection.

   *  The proxy requires the client to authenticate before proceeding.

   After rejecting a request, the server will continue to interpret
   subsequent bytes on that connection in accordance with HTTP/1.1.

   [RFC9110] also states:

      A client cannot begin using an upgraded protocol on the connection
      until it has completely sent the request message (i.e., the client
      can't change the protocol it is sending in the middle of a
      message).

   However, because of the possibility of rejection, the converse is not
   true: a client cannot necessarily begin using a new protocol merely
   because it has finished sending the corresponding request message.

   In some cases, the client might expect that the protocol transition
   will succeed.  If this expectation is correct, the client might be
   able to reduce delay by immediately sending the first bytes of the
   new protocol "optimistically", without waiting for the server's
   response.  This document explores the security implications of this
   "optimistic" behavior.

3.  Possible Security Issues

   When there are only two distinct parties involved in an HTTP/1.1
   connection (i.e., the client and the server), protocol transitions
   introduce no new security issues: each party must already be prepared
   for the other to send arbitrary data on the connection at any time.
   However, HTTP connections often involve more than two parties, if the
   requests or responses include third-party data.  For example, a
   browser (party 1) might send an HTTP request to an origin (party 2)
   with path, headers, or body controlled by a website from a different
   origin (party 3).  Post-transition protocols such as WebSocket
   similarly are often used to convey data chosen by a third party.

Schwartz                  Expires 24 April 2025                 [Page 4]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

   If the third-party data source is untrusted, we call the data it
   provides "attacker-controlled".  The combination of attacker-
   controlled data and optimistic protocol transitions results in two
   significant security issues.

3.1.  Request Smuggling

   In a Request Smuggling attack ([RFC9112], Section 11.2) the attacker-
   controlled data is chosen in such a way that it is interpreted by the
   server as an additional HTTP request.  These attacks allow the
   attacker to speak on behalf of the client while bypassing the
   client's own rules about what requests it will issue.  Request
   Smuggling can occur if the client and server have distinct
   interpretations of the data that flows between them.

   If the server accepts a protocol transition request, it interprets
   the subsequent bytes in accordance with the new protocol.  If it
   rejects the request, it interprets those bytes as HTTP/1.1.  However,
   the client doesn't know which interpretation the server will take
   until it receives the server's response status code.  If it uses the
   new protocol optimistically, this creates a risk that the server will
   interpret attacker-controlled data in the new protocol as an
   additional HTTP request issued by the client.

   As a trivial example, consider an HTTP CONNECT client providing
   connectivity to an untrusted application.  If the client is
   authenticated to the proxy server using a connection-level
   authentication method such as TLS Client Certificates, the attacker
   could send an HTTP/1.1 POST request for the proxy server at the
   beginning of its TCP connection.  If the client delivers this data
   optimistically, and the CONNECT request fails, the server would
   misinterpret the application's data as a subsequent authenticated
   request issued by the client.

3.2.  Parser Exploits

   A related category of attacks use protocol disagreement to exploit
   vulnerabilities in the server's request parsing logic.  These attacks
   apply when the HTTP client is trusted by the server, but the post-
   transition data source is not.  If the server software was developed
   under the assumption that some or all of the HTTP request data is not
   attacker-controlled, optimistic transmission can cause this
   assumption to be violated, exposing vulnerabilities in the server's
   HTTP request parser.

Schwartz                  Expires 24 April 2025                 [Page 5]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

4.  Operational Issues

   If the server rejects the transition request, the connection can
   continue to be used for HTTP/1.1.  There is no requirement to close
   the connection in response to a rejected transition, and keeping the
   connection open has performance advantages if additional HTTP
   requests to this server are likely.  Thus, it is normally
   inappropriate to close the connection in response to a rejected
   transition.

5.  Impact on HTTP Upgrade with Existing Upgrade Tokens

   This section describes the impact of this document's considerations
   on some registered Upgrade Tokens that are believed to be in use at
   the time of writing.

5.1.  "TLS"

   The "TLS" family of Upgrade Tokens was defined in [RFC2817], which
   correctly highlights the possibility of the server rejecting the
   upgrade.  If a client ignores this possibility and sends TLS data
   optimistically, the result cannot be valid HTTP/1.1: the first octet
   of a TLS connection must be 22 (ContentType.handshake), but this is
   not an allowed character in an HTTP/1.1 method.  A compliant HTTP/1.1
   server will treat this as a parsing error and close the connection
   without processing further requests.

5.2.  "WebSocket"/"websocket"

   Section 4.1 of [RFC6455] says:

      Once the client's opening handshake has been sent, the client MUST
      wait for a response from the server before sending any further
      data.

   Thus, optimistic use of HTTP Upgrade is already forbidden in the
   WebSocket protocol.  Additionally, the WebSocket protocol requires
   high-entropy masking of client-to-server frames (Section 5.1 of
   [RFC6455]).

5.3.  "connect-udp"

   Section 5 of [RFC9298] says:

      A client MAY optimistically start sending UDP packets in HTTP
      Datagrams before receiving the response to its UDP proxying
      request.

Schwartz                  Expires 24 April 2025                 [Page 6]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

   However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade
   request.  This upgrade is likely to be rejected in certain
   circumstances, such as when the UDP destination address (which is
   attacker-controlled) is invalid.  Additionally, the contents of the
   "connect-udp" protocol stream can include untrusted material (i.e.,
   the UDP packets, which might come from other applications on the
   client device).  This creates the possibility of Request Smuggling
   attacks.  To avoid these concerns, this text is updated as follows:

      When using HTTP/2 or later, a client MAY optimistically ...

   Section 3.3 of [RFC9298] describes the requirement for a successful
   proxy setup response, including upgrading to the "connect-udp"
   protocol, and says:

      If any of these requirements are not met, the client MUST treat
      this proxying attempt as failed and abort the connection.

   However, this could be interpreted as an instruction to abort the
   underlying TLS and TCP connections in the event of an unsuccessful
   response such as "407 ("Proxy Authentication Required)".  To avoid an
   unnecessary delay in this case, this text is hereby updated as
   follows:

      If any of these requirements are not met, the client MUST treat
      this proxying attempt as failed.  If the "Upgrade" response header
      field is absent, the client MAY reuse the connection for further
      HTTP/1.1 requests; otherwise it MUST abort the underlying
      connection.

5.4.  "connect-ip"

   The "connect-ip" Upgrade Token is defined in [RFC9484].  Section 11
   of [RFC9484] forbids clients from using optimistic upgrade, avoiding
   this issue.

6.  Guidance for Future Upgrade Tokens

   There are now several good examples of designs that reduce or
   eliminate the security concerns discussed in this document and may be
   applicable in future specifications:

   *  Forbid optimistic use of HTTP Upgrade (WebSocket, Section 4.1 of
      [RFC6455]).

   *  Embed a fixed preamble that terminates HTTP/1.1 processing
      (HTTP/2, Section 3.4 of [RFC9113]).

Schwartz                  Expires 24 April 2025                 [Page 7]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

   *  Apply high-entropy masking of client-to-server data (WebSocket,
      Section 5.1 of [RFC6455]).

   Future specifications for Upgrade Tokens should account for the
   security issues discussed here and provide clear guidance on how
   implementations can avoid them.

6.1.  Selection of Request Methods

   Some Upgrade Tokens, such as "TLS", are defined for use with any
   ordinary HTTP Method.  The upgraded protocol continues to provide
   HTTP semantics, and will convey the response to this HTTP request.

   The other Upgrade Tokens mentioned in Section 5 do not preserve HTTP
   semantics, so the method is not relevant.  All of these Upgrade
   Tokens are specified only for use with the "GET" method.

   Future specifications for Upgrade Tokens should restrict their use to
   "GET" requests if the HTTP method is otherwise irrelevant and a
   request body is not required.  This improves consistency with other
   Upgrade Tokens and reduces the likelihood that a faulty server
   implementation might process the request body as the new protocol.

7.  Guidance for HTTP CONNECT

   Clients that send HTTP CONNECT requests on behalf of untrusted TCP
   clients MUST wait for a 2xx (Successful) response before sending any
   TCP payload data.

   To mitigate vulnerabilities from any clients that do not conform to
   this requirement, proxy servers MAY close the underlying connection
   when rejecting an HTTP CONNECT request, without processing any
   further data sent to the proxy server on that connection.  Note that
   this behavior may impair performance, especially when returning a
   "407 (Proxy Authentication Required)" response.

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Schwartz                  Expires 24 April 2025                 [Page 8]
Internet-Draft      Optimistic HTTP Upgrade Security        October 2024

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9298]  Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
              DOI 10.17487/RFC9298, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9298>.

   [RFC9484]  Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
              Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
              RFC 9484, DOI 10.17487/RFC9484, October 2023,
              <https://www.rfc-editor.org/rfc/rfc9484>.

9.2.  Informative References

   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
              HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000,
              <https://www.rfc-editor.org/rfc/rfc2817>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/rfc/rfc6455>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

Acknowledgments

   Thanks to Mark Nottingham and Lucas Pardue for early reviews of this
   document.

Author's Address

   Benjamin M. Schwartz
   Meta Platforms, Inc.
   Email: ietf@bemasc.net

Schwartz                  Expires 24 April 2025                 [Page 9]