draft-ietf-httpbis-optimistic-upgrade-01.txt | draft-ietf-httpbis-optimistic-upgrade-latest.txt | |||
---|---|---|---|---|
HTTPBIS Working Group | HTTPBIS Working Group | |||
Internet-Draft Meta Platforms, Inc. | Internet-Draft Meta Platforms, Inc. | |||
Updates: 9298 (if approved) October 21, 2024 | Updates: 9298 (if approved) February 16, 2025 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: April 24, 2025 | Expires: August 20, 2025 | |||
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 | Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 | |||
draft-ietf-httpbis-optimistic-upgrade-01 | draft-ietf-httpbis-optimistic-upgrade-latest | |||
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 | |||
request is confirmed, and updates RFC 9298 to avoid related security | request is confirmed, and updates RFC 9298 to avoid related security | |||
issues. | issues. | |||
About This Document | About This Document | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 24, 2025. | This Internet-Draft will expire on August 20, 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 8, line 48 ¶ | skipping to change at page 8, line 48 ¶ | |||
Tokens are specified only for use with the "GET" method. | Tokens are specified only for use with the "GET" method. | |||
Future specifications for Upgrade Tokens should restrict their use to | Future specifications for Upgrade Tokens should restrict their use to | |||
"GET" requests if the HTTP method is otherwise irrelevant and a | "GET" requests if the HTTP method is otherwise irrelevant and a | |||
request body is not required. This improves consistency with other | request body is not required. This improves consistency with other | |||
Upgrade Tokens and reduces the likelihood that a faulty server | Upgrade Tokens and reduces the likelihood that a faulty server | |||
implementation might process the request body as the new protocol. | implementation might process the request body as the new protocol. | |||
7. Guidance for HTTP CONNECT | 7. Guidance for HTTP CONNECT | |||
Clients that send HTTP CONNECT requests on behalf of untrusted TCP | In HTTP/1.1, proxy clients that send CONNECT requests on behalf of | |||
clients MUST wait for a 2xx (Successful) response before sending any | untrusted TCP clients MUST wait for a 2xx (Successful) response | |||
TCP payload data. | before forwarding any TCP payload data. Proxy clients that start | |||
forwarding before confirming the response status code are vulnerable | ||||
to a trivial request smuggling attack (Section 3.1). | ||||
To mitigate vulnerabilities from any clients that do not conform to | To mitigate the impact of such vulnerable clients, proxy servers MAY | |||
this requirement, proxy servers MAY close the underlying connection | close the underlying connection when rejecting an HTTP/1.1 CONNECT | |||
when rejecting an HTTP CONNECT request, without processing any | request, without processing any further data on that connection. | |||
further data sent to the proxy server on that connection. Note that | Note that this behavior will frequently impair the performance of | |||
this behavior may impair performance, especially when returning a | correctly implemented clients, especially when returning a "407 | |||
"407 (Proxy Authentication Required)" response. | (Proxy Authentication Required)" response. This performance loss can | |||
be be avoided by using HTTP/2 or HTTP/3, which are not vulnerable to | ||||
this attack. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
End of changes. 7 change blocks. | ||||
14 lines changed or deleted | 18 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |