[要約] HTTP/1.1において、サーバーの確認を待たずに新しいプロトコルのデータを送信する「楽観的な移行」が引き起こすセキュリティリスクについて解説しています。移行リクエストが拒否された場合に、後続のデータが意図しないHTTPリクエストとして解釈されるリクエスト密輸（Request Smuggling）などの攻撃手法とその対策を詳述しています。RFC 9112および9298を更新し、プロキシクライアントやサーバーに対して接続のクローズや応答待機などの新たな義務を課すことで、通信の安全性を強化しています。
Internet Engineering Task Force (IETF) B. Schwartz
Request for Comments: 9931 Meta Platforms, Inc.
Updates: 9112, 9298 March 2026
Category: Standards Track
ISSN: 2070-1721
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 adds new requirements to RFCs 9112 and 9298 to avoid related security issues.
HTTP/1.1 では、クライアントは既存の接続上の新しいプロトコルへの変更を要求できます。この文書では、このリクエストが確認される前にクライアントによって送信されるデータに適用されるセキュリティに関する考慮事項について説明し、関連するセキュリティ問題を回避するために RFC 9112 および 9298 に新しい要件を追加します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9931.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9931 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Overview
2. Requirements Language
3. Background
4. Possible Security Issues
4.1. Request Smuggling
4.2. Parser Exploits
5. Operational Issues
6. Impact on HTTP Upgrade with Existing Upgrade Tokens
6.1. "TLS"
6.2. "WebSocket"/"websocket"
6.3. "connect-udp"
6.4. "connect-ip"
7. Guidance for Future Upgrade Tokens
7.1. Selection of Request Methods
8. Requirements for HTTP CONNECT
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
This document discusses certain security considerations that arise when switching from HTTP/1.1 to a different protocol on the same connection. It provides:
このドキュメントでは、同じ接続上で HTTP/1.1 から別のプロトコルに切り替えるときに発生するセキュリティに関する考慮事項について説明します。それは以下を提供します:
* a review of the relevant standards,
* 関連する規格の見直し、
* a discussion of the security risks that may apply if a client sends data before the transition is confirmed,
* 移行が確認される前にクライアントがデータを送信した場合に適用される可能性のあるセキュリティ リスクについての説明。
* a security evaluation of existing upgrade tokens, and
* 既存のアップグレード トークンのセキュリティ評価、および
* guidance for implementations and future standards documents.
* 実装のためのガイダンスと将来の標準文書。
Updates to [HTTP/1.1] and [CONNECT-UDP], including new normative requirements, are provided in Sections 8 and 6.3, respectively.
新しい規範要件を含む [HTTP/1.1] と [CONNECT-UDP] の更新は、それぞれセクション 8 と 6.3 で提供されます。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
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 requests can be multiplexed, as each request is distinguished explicitly by its stream ID. However, in HTTP/1.1, requests are strictly sequential, and each new request is distinguished implicitly by the closure of the preceding request.
HTTP/1.1 [HTTP/1.1] 以降では、単一の接続を多数のリクエストに使用できます。HTTP/2 [HTTP/2] および HTTP/3 [HTTP/3] では、各リクエストがストリーム ID によって明示的に区別されるため、これらのリクエストは多重化できます。ただし、HTTP/1.1 では、リクエストは厳密にシーケンシャルであり、新しいリクエストはそれぞれ、前のリクエストの終了によって暗黙的に区別されます。
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 are two mechanisms to request such a protocol transition. One mechanism is the Upgrade header field ([HTTP], Section 7.8). When included in a request, this field 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 ([HTTP], Section 15.2.2).
HTTP/1.1 は、クライアントが接続の残りの部分に使用されるプロトコルを変更できる唯一の HTTP バージョンでもあります。このようなプロトコル移行を要求するには 2 つのメカニズムがあります。1 つのメカニズムは Upgrade ヘッダー フィールド ([HTTP]、セクション 7.8) です。このフィールドがリクエストに含まれる場合、クライアントがこの接続を HTTP/1.1 以外のプロトコルに使用することを希望していることを示します。サーバーは、プロトコルの変更を受け入れる場合、101 (スイッチング プロトコル) ステータス コードで応答します ([HTTP]、セクション 15.2.2)。
The other mechanism is the HTTP CONNECT method (Section 9.3.6 of [HTTP]). This method indicates that the client wishes to establish a TCP connection to the specified host and port. If accepted, 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.
もう 1 つのメカニズムは HTTP CONNECT メソッド ([HTTP] のセクション 9.3.6) です。このメソッドは、クライアントが指定されたホストおよびポートへの TCP 接続の確立を望んでいることを示します。受け入れられた場合、サーバーは 2xx (成功) 応答で応答し、要求が受け入れられ、TCP 接続が確立されたことを示します。この時点以降、TCP 接続は HTTP/1.1 接続ではなく、TCP トンネルとして機能します。
Both of these mechanisms also permit the server to reject the request. For example, Section 7.8 of [HTTP] says:
これらのメカニズムはどちらも、サーバーがリクエストを拒否することを許可します。たとえば、[HTTP] のセクション 7.8 には次のように書かれています。
A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.
サーバーは、その接続上で現在のプロトコルの使用を継続したい場合、受信した Upgrade ヘッダー フィールドを無視してもよい (MAY)。
and Section 9.3.6 of [HTTP] says:
[HTTP] のセクション 9.3.6 には次のように書かれています。
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.
サーバーは、空または無効なポート番号をターゲットとする CONNECT リクエストを、通常は 400 (Bad Request) ステータス コードで応答することによって拒否しなければなりません (MUST)。
Rejected upgrades are common and can happen for a variety of reasons, such as:
アップグレードの拒否は一般的であり、次のようなさまざまな理由で発生する可能性があります。
* 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.
* サーバーは、クライアントが指定したアップグレード トークン (つまり、クライアントが提案した新しいプロトコル) をサポートしていないため、引き続き 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.
* サーバーは、提供されたプロトコルにアップグレードしても、このリソースへのリクエストに関して HTTP/1.1 よりも改善されないことを認識しているため、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 field ([HTTP], Section 11.6.2).
* サーバーは、プロトコルをアップグレードする前にクライアントに認証を要求するため、ステータス コード 401 (認証が必要) で応答し、Authorization 応答ヘッダー フィールドにチャレンジを提供します ([HTTP]、セクション 11.6.2)。
* The resource has moved, so the server replies with a 3xx (Redirection) status code ([HTTP], Section 3.4).
* リソースが移動したため、サーバーは 3xx (リダイレクト) ステータス コードで応答します ([HTTP]、セクション 3.4)。
Similarly, servers frequently reject HTTP CONNECT requests, such as when:
同様に、サーバーは次のような場合に HTTP CONNECT リクエストを頻繁に拒否します。
* The server does not support HTTP CONNECT.
* サーバーは 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 bytes received on that connection in accordance with HTTP/1.1.
リクエストを拒否した後も、サーバーは HTTP/1.1 に従ってその接続で受信したバイトを解釈し続けます。
Section 7.8 of [HTTP] also states:
[HTTP] のセクション 7.8 にも次のように記載されています。
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).
クライアントは、要求メッセージの送信が完了するまで、接続上でアップグレードされたプロトコルの使用を開始できません (つまり、クライアントは、メッセージの途中で送信しているプロトコルを変更できません)。
In other words, completion of the request message is a *necessary* condition for the client to begin using the new protocol. However, it is important to clarify that this is not a *sufficient* condition because the server might reject the request.
言い換えれば、リクエスト メッセージの完了は、クライアントが新しいプロトコルの使用を開始するための「必須」条件です。ただし、サーバーがリクエストを拒否する可能性があるため、これは「十分な」条件ではないことを明確にすることが重要です。
In some cases, the client might predict that the server is likely to accept a requested protocol transition. For example, if a request using an upgrade token recently succeeded, the client might expect that subsequent requests with the same upgrade token will also succeed. If this expectation is correct, the client can often 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.
場合によっては、クライアントは、サーバーが要求されたプロトコル移行を受け入れる可能性が高いと予測することがあります。たとえば、アップグレード トークンを使用したリクエストが最近成功した場合、クライアントは同じアップグレード トークンを使用した後続のリクエストも成功すると期待する可能性があります。この予想が正しければ、クライアントはサーバーの応答を待たずに、新しいプロトコルの最初のバイトを「楽観的に」即座に送信することで遅延を短縮できることがよくあります。この文書では、この「楽観的な」動作がセキュリティに与える影響について検討します。
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 the path, headers, or content controlled by a website from a different origin (party 3). Post-transition protocols, such as WebSocket [WEBSOCKET], are also frequently used to convey data chosen by a third party.
HTTP/1.1 接続に関与する異なる当事者が 2 人だけ (つまり、クライアントとサーバー) の場合、プロトコルの移行によって新たなセキュリティ問題が生じることはありません。各当事者は、相手がいつでも接続上で任意のデータを送信できるようにあらかじめ準備しておく必要があります。ただし、リクエストまたは応答にサードパーティ データが含まれている場合、HTTP 接続には 3 つ以上のパーティが関与することがよくあります。たとえば、ブラウザ (パーティ 1) は、別のオリジン (パーティ 3) からの Web サイトによって制御されるパス、ヘッダー、またはコンテンツを含む HTTP リクエストをオリジン (パーティ 2) に送信する場合があります。WebSocket [WEBSOCKET] などの移行後のプロトコルも、サードパーティが選択したデータを伝達するためによく使用されます。
If the third-party data source is untrusted, then the data it provides is potentially "attacker-controlled". The combination of attacker-controlled data and optimistic protocol transitions results in two significant security issues.
サードパーティのデータ ソースが信頼できない場合、そのデータ ソースが提供するデータは「攻撃者によって制御されている」可能性があります。攻撃者が制御するデータと楽観的なプロトコル移行の組み合わせにより、2 つの重大なセキュリティ問題が発生します。
In a Request Smuggling attack ([HTTP/1.1], 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.
リクエスト密輸攻撃 ([HTTP/1.1]、セクション 11.2) では、攻撃者が制御するデータは、サーバーによって追加の HTTP リクエストとして解釈されるような方法で選択されます。これらの攻撃により、攻撃者はクライアントが発行するリクエストに関するクライアント独自のルールをバイパスしながら、クライアントに代わって発言することが可能になります。リクエストの密輸は、クライアントとサーバーの間で流れるデータの解釈が異なる場合に発生する可能性があります。
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 cannot 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.
サーバーがプロトコル移行要求を受け入れると、新しいプロトコルに従って後続のバイトを解釈します。リクエストが拒否された場合、それらのバイトは HTTP/1.1 として解釈されます。ただし、クライアントは、サーバーの応答ステータス コードを受信するまで、サーバーがどの解釈を採用するかを知ることができません。新しいプロトコルを楽観的に使用すると、サーバーが新しいプロトコルで攻撃者が制御するデータを、クライアントが発行した追加の HTTP リクエストとして解釈するリスクが生じます。
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 ([TLS], Section 4.4.2), the attacker could send an HTTP/1.1 POST request ([HTTP], Section 9.3.3) 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.
簡単な例として、信頼できないアプリケーションへの接続を提供する HTTP CONNECT クライアントを考えてみましょう。TLS クライアント証明書 ([TLS]、セクション 4.4.2) などの接続レベルの認証方法を使用してクライアントがプロキシ サーバーに対して認証されている場合、攻撃者は TCP 接続の開始時にプロキシ サーバーに対して HTTP/1.1 POST リクエスト ([HTTP]、セクション 9.3.3) を送信する可能性があります。クライアントがこのデータを楽観的に配信し、CONNECT リクエストが失敗した場合、サーバーはアプリケーションのデータをクライアントが発行した後続の認証されたリクエストと誤って解釈します。
## REQUESTS ##
# The malicious application requests a TCP connection to a nonexistent
# destination, which will fail.
CONNECT no-such-destination.example:443 HTTP/1.1
Host: no-such-destination.example:443
# Before connection fails, the malicious application sends data on the
# proxied TCP connection that forms a valid POST request to the proxy.
# The vulnerable client optimistically forwards this data to the proxy.
POST /upload HTTP/1.1
Host: proxy.example
Content-Length: 123456
<POST body controlled by the malicious application>
## RESPONSES ##
# When TCP connection establishment fails, the proxy responds by
# rejecting the CONNECT request, but the client has already forwarded
# the malicious TCP payload data to the proxy.
HTTP/1.1 504 Gateway Timeout
Content-Length: 0
# The proxy interprets the smuggled POST request as coming from the
# client. If connection-based authentication is in use (e.g., using
# TLS client certificate authentication), the proxy treats this
# malicious request as authenticated.
HTTP/1.1 200 OK
Content-Length: 0
Figure 1: Example Request Smuggling Attack Using HTTP CONNECT
図 1: HTTP CONNECT を使用したリクエスト密輸攻撃の例
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.
関連するカテゴリの攻撃では、プロトコルの不一致を利用して、サーバーのリクエスト解析ロジックの脆弱性を悪用します。これらの攻撃は、HTTP クライアントがサーバーによって信頼されているが、移行後のデータ ソースが信頼されていない場合に適用されます。HTTP リクエスト データの一部またはすべてが攻撃者によって制御されていないという前提に基づいてサーバー ソフトウェアが開発されている場合、楽観的な送信によってこの前提が破られ、サーバーの HTTP リクエスト パーサーの脆弱性が露呈する可能性があります。
If the server rejects the transition request, the connection can continue to be used for HTTP/1.1. There is no general 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.
サーバーが移行リクエストを拒否した場合、接続は引き続き HTTP/1.1 で使用できます。拒否された遷移に応じて接続を閉じるという一般的な要件はありません。このサーバーへの追加の HTTP リクエストが発生する可能性がある場合、接続を開いたままにしておくことでパフォーマンスが向上します。したがって、拒否された遷移に応じて接続を閉じることは通常は不適切です。
This section describes the impact of this document's considerations on some registered upgrade tokens [IANA-UPGR] that are believed to be in use at the time of writing.
このセクションでは、執筆時点で使用されていると考えられる一部の登録済みアップグレード トークン [IANA-UPGR] に対するこの文書の考慮事項の影響について説明します。
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 (see [TLS], Section 5.1 and [HTTP/1.1], Section 3). A compliant HTTP/1.1 server will treat this as a parsing error and close the connection without processing further requests.
アップグレード トークンの「TLS」ファミリーは [RFC2817] で定義されており、サーバーがアップグレードを拒否する可能性を正しく強調しています。クライアントがこの可能性を無視して TLS データを楽観的に送信した場合、結果は有効な HTTP/1.1 ではありません。TLS 接続の最初のオクテットは 22 (ContentType.handshake) でなければなりませんが、これは HTTP/1.1 メソッドでは許可されない文字です ([TLS]、セクション 5.1 および [HTTP/1.1]、セクション 3 を参照)。準拠した HTTP/1.1 サーバーはこれを解析エラーとして扱い、それ以上のリクエストを処理せずに接続を閉じます。
Section 4.1 of [WEBSOCKET] says:
[WEBSOCKET] のセクション 4.1 には次のように書かれています。
Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data.
クライアントのオープニング ハンドシェイクが送信された後、クライアントはさらにデータを送信する前にサーバーからの応答を待機しなければなりません (MUST)。
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 [WEBSOCKET]).
したがって、HTTP アップグレードの楽観的な使用は、WebSocket プロトコルではすでに禁止されています。さらに、WebSocket プロトコルはクライアントからサーバーへのフレームの高エントロピー マスキングを必要とします ([WEBSOCKET] のセクション 5.1)。
Section 5 of [CONNECT-UDP] says:
[CONNECT-UDP] のセクション 5 には次のように書かれています。
A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request.
クライアントは、UDP プロキシ要求に対する応答を受信する前に、楽観的に HTTP データグラムで UDP パケットの送信を開始してもよい(MAY)。
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 document replaces that text to exclude HTTP/1.1 from any optimistic sending, as follows:
ただし、HTTP/1.1 では、この「プロキシ要求」は HTTP アップグレード要求です。このアップグレードは、UDP 宛先アドレス (攻撃者が制御する) が無効な場合など、特定の状況では拒否される可能性があります。さらに、「connect-udp」プロトコル ストリームのコンテンツには、信頼できないマテリアル (つまり、クライアント デバイス上の他のアプリケーションから送信される可能性のある UDP パケット) が含まれる可能性があります。これにより、リクエスト密輸攻撃の可能性が生じます。これらの懸念を回避するために、このドキュメントではそのテキストを次のように置き換えて、楽観的な送信から HTTP/1.1 を除外します。
A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request but only if the HTTP version in use is HTTP/2 or later. Clients MUST NOT send UDP packets optimistically in HTTP/1.x due to the risk of Request Smuggling attacks.
クライアントは、使用中の HTTP バージョンが HTTP/2 以降である場合に限り、UDP プロキシ要求に対する応答を受信する前に、楽観的に HTTP データグラムで UDP パケットの送信を開始してもよい(MAY)。Request Smuggling 攻撃のリスクがあるため、クライアントは HTTP/1.x で UDP パケットを楽観的に送信してはなりません (MUST NOT)。
The "connect-ip" upgrade token is defined in [CONNECT-IP]. Section 11 of [CONNECT-IP] forbids clients from sending packets optimistically in HTTP/1.1, avoiding this issue.
「connect-ip」アップグレードトークンは[CONNECT-IP]で定義されています。[CONNECT-IP] のセクション 11 では、クライアントが HTTP/1.1 で楽観的にパケットを送信することを禁止しており、この問題を回避しています。
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 (Section 4.1 of [WEBSOCKET] and Section 11 of [CONNECT-IP]).
* HTTP アップグレードの楽観的な使用を禁止します ([WEBSOCKET] のセクション 4.1 および [CONNECT-IP] のセクション 11)。
* Embed a fixed preamble that deliberately terminates HTTP/1.1 processing (Section 3.4 of [HTTP/2]).
* HTTP/1.1 処理を意図的に終了する固定プリアンブルを埋め込みます ([HTTP/2] のセクション 3.4)。
* Apply high-entropy masking of client-to-server data (Section 5.1 of [WEBSOCKET]).
* クライアントからサーバーへのデータに高エントロピー マスキングを適用します ([WEBSOCKET] のセクション 5.1)。
Future specifications for upgrade tokens should account for the security issues discussed here and provide clear guidance on how implementations can avoid them.
アップグレード トークンの将来の仕様では、ここで説明したセキュリティ問題を考慮し、実装で問題を回避する方法について明確なガイダンスを提供する必要があります。
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.
「TLS」などの一部のアップグレード トークンは、通常の HTTP メソッドで使用するために定義されています。アップグレードされたプロトコルは引き続き HTTP セマンティクスを提供し、この HTTP 要求に対する応答を伝達します。
The other upgrade tokens mentioned in Section 6 do not preserve HTTP semantics, so the method is not relevant. All of these upgrade tokens are specified only for GET requests with no content.
セクション 6 で説明されている他のアップグレード トークンは HTTP セマンティクスを保持しないため、この方法は関係ありません。これらのアップグレード トークンはすべて、コンテンツのない GET リクエストに対してのみ指定されます。
Future specifications for upgrade tokens should restrict their use to GET requests with no content if the HTTP method is otherwise irrelevant and the request does not need to carry any message content. This improves consistency with other upgrade tokens and simplifies server implementation.
アップグレード トークンの将来の仕様では、HTTP メソッドが無関係でリクエストにメッセージ コンテンツが含まれる必要がない場合、その使用をコンテンツのない GET リクエストに制限する必要があります。これにより、他のアップグレード トークンとの一貫性が向上し、サーバーの実装が簡素化されます。
This document updates [HTTP/1.1] to include the remaining text of this section. The requirements in this section apply only to HTTP/1.1.
この文書は、このセクションの残りのテキストを含めるために [HTTP/1.1] を更新します。このセクションの要件は HTTP/1.1 にのみ適用されます。
Proxy clients that send CONNECT requests on behalf of untrusted TCP clients MUST do one or both of the following:
信頼できない TCP クライアントに代わって CONNECT リクエストを送信するプロキシ クライアントは、次のいずれかまたは両方を実行しなければなりません。
1. Wait for a 2xx (Successful) response before forwarding any TCP payload data.
1. TCP ペイロード データを転送する前に、2xx (成功) 応答を待ちます。
2. Send a "Connection: close" request header.
2. 「Connection: close」リクエストヘッダーを送信します。
Proxy clients that don't implement at least one of these two behaviors are vulnerable to a trivial Request Smuggling attack ([HTTP/1.1], Section 11.2).
これら 2 つの動作のうち少なくとも 1 つを実装していないプロキシ クライアントは、単純なリクエスト密輸攻撃に対して脆弱です ([HTTP/1.1]、セクション 11.2)。
At the time of writing, some proxy clients are believed to be vulnerable as described. As a mitigation, proxy servers MUST close the underlying connection when rejecting a CONNECT request without processing any further requests on that connection. This requirement applies whether or not the request includes a "close" connection option.
この記事の執筆時点では、一部のプロキシ クライアントには前述の脆弱性があると考えられています。As a mitigation, proxy servers MUST close the underlying connection when rejecting a CONNECT request without processing any further requests on that connection.この要件は、リクエストに「閉じる」接続オプションが含まれているかどうかに関係なく適用されます。
Note that this mitigation will frequently cause slower connection establishment for correctly implemented clients, especially when returning a 407 (Proxy Authentication Required) response. This performance loss can be avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this attack.
この軽減策により、特に 407 (プロキシ認証が必要) 応答を返す場合、正しく実装されたクライアントの接続確立が遅くなることがよくあることに注意してください。このパフォーマンスの低下は、この攻撃に対して脆弱ではない HTTP/2 または HTTP/3 を使用することで回避できます。
As a performance optimization, proxy servers MAY disable this mitigation if the client is known to wait for a 2xx (Successful) response before forwarding untrusted TCP payload data (i.e., complying with item 1 above). Proxy servers can identify compliant clients using the request's User-Agent header field and the user agent vendor's documentation regarding its compliance.
パフォーマンスの最適化として、クライアントが信頼できない TCP ペイロード データを転送する前に 2xx (成功) 応答を待つことがわかっている場合 (つまり、上記の項目 1 に準拠している場合)、プロキシ サーバーはこの軽減策を無効にしてもよい(MAY)。プロキシ サーバーは、リクエストの User-Agent ヘッダー フィールドとその準拠に関するユーザー エージェント ベンダーのドキュメントを使用して、準拠しているクライアントを識別できます。
This document describes security considerations related to optimistic use of protocol transitions in HTTP/1.1.
この文書では、HTTP/1.1 でのプロトコル遷移の楽観的な使用に関連するセキュリティの考慮事項について説明します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[HTTP] 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/info/rfc9110>.
[HTTP/1.1] 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/info/rfc9112>.
[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/info/rfc2119>.
[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/info/rfc8174>.
[CONNECT-IP]
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/info/rfc9484>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[IANA-UPGR]
IANA, "Hypertext Transfer Protocol (HTTP) Upgrade Token
Registry",
<https://www.iana.org/assignments/http-upgrade-tokens/>.
[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/info/rfc2817>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[WEBSOCKET]
Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
This document benefited from valuable reviews and suggestions by:
このドキュメントは、次の方々による貴重なレビューと提案から恩恵を受けています。
* Mike Bishop
* マイク・ビショップ
* Mohamed Boucadair
* モハメド・ブーカデア
* Gorry Fairhurst
* ゴリー・フェアハースト
* Mark Nottingham
* マーク・ノッティンガム
* Kazuho Oku
* 奥一穂
* Lucas Pardue
* ルーカス・パルデュ
* David Schinazi
* デビッド・スキナジ
* Glenn Strauss
* グレン・ストラウス
* Michael Sweet
* マイケル・スウィート
* Willy Tarreau
* ウィリー・タロー
* Martin Thomson
* マーティン・トムソン
Benjamin M. Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net