[要約] RFC 8565は、Hypertext Jeopardy Protocol（HTJP/1.0）に関する仕様書です。このプロトコルの目的は、Jeopardyスタイルのゲームをオンラインで実現するための通信手段を提供することです。
Independent Submission E. Fokschaner
Request for Comments: 8565 1 April 2019
Category: Informational
ISSN: 2070-1721
Hypertext Jeopardy Protocol (HTJP/1.0)
ハイパーテキストJeopardyプロトコル（HTJP / 1.0）
Abstract
概要
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.
Hypertext Jeopardy Protocol（HTJP）は、Hypertext Transfer Protocol（HTTP）の要求/応答セマンティクスを反転させます。従来のHTTPを使用して、サーバーに接続し、質問し、正しい答えを期待します。 HTJPを使用して、サーバーに接続し、回答を送信し、正しい質問を期待します。このドキュメントは、HTJPのセマンティクスを指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8565.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8565で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Comparison with HTTP . . . . . . . . . . . . . . . . . . . . 3
4. Response and Request Semantics . . . . . . . . . . . . . . . 4
4.1. Applicability of Postel's Robustness Principle . . . . . 4
4.2. Identifying the Server Associated with an HTJP Response . 5
4.3. Temporal Considerations . . . . . . . . . . . . . . . . . 5
4.4. Pseudo-Valid HTJP Messages . . . . . . . . . . . . . . . 6
4.5. HTTP Responses That Are Not Requestable . . . . . . . . . 6
5. Caches and Proxies . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Securing HTTP against HTJP . . . . . . . . . . . . . . . 7
7.1.1. Anti-HTJP-Nonce Header . . . . . . . . . . . . . . . 8
7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Hypertext Double Jeopardy Protocol . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
The Hypertext Jeopardy Protocol (HTJP) 1.0 is a stateless application-level response/request protocol that functions as the semantic inverse of the Hypertext Transfer Protocol (HTTP) 1.1 .
Hypertext Jeopardy Protocol（HTJP）1.0は、ステートレスなアプリケーションレベルの応答/要求プロトコルであり、Hypertext Transfer Protocol（HTTP）1.1のセマンティックインバースとして機能します。
It can roughly be specified in relation to HTTP by the following rules:
次のルールにより、HTTPとの関連で大まかに指定できます。
o Where an HTTP client would send an HTTP request message, an HTJP client would send an HTTP response message.
o HTTPクライアントがHTTP要求メッセージを送信する場合、HTJPクライアントはHTTP応答メッセージを送信します。
o Where an HTTP server would send an HTTP response message, an HTJP server would send an HTTP request message.
o HTTPサーバーがHTTP応答メッセージを送信する場合、HTJPサーバーはHTTP要求メッセージを送信します。
o The HTTP request sent as an HTJP response should be an HTTP request that (if sent to the appropriate HTTP server) would elicit the HTTP response sent in the HTJP request.
o HTJP応答として送信されるHTTP要求は、（適切なHTTPサーバーに送信された場合）HTJP要求で送信されるHTTP応答を引き出すHTTP要求である必要があります。
HTJP is compatible with the HTTP/1.1 specification, at least in spirit, if not in letter.
HTJPはHTTP / 1.1仕様と互換性があります。
HTJP has novel applications in all the following areas:
HTJPには、次のすべての分野で新しいアプリケーションがあります。
o Generative automated testing of HTTP implementations and HTTP-based applications.
o HTTP実装とHTTPベースのアプリケーションの生成自動テスト。
o Monitoring of HTTP-based applications in production.
o 本番環境でのHTTPベースのアプリケーションの監視。
o Forensic and diagnostic reconstruction of HTTP requests from HTTP response logs.
o HTTP応答ログからのHTTP要求のフォレンジックおよび診断による再構成。
o Discovery of first-party and third-party security vulnerabilities.
o ファーストパーティおよびサードパーティのセキュリティ脆弱性の発見。
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]で説明されているように解釈されます。
It is a little-known fact that HTTP/1.1 already defines itself to be its own inverse mode of operation. Section 3.1 of RFC 7230 [RFC7230], which describes the start line of the HTTP message format, states:
HTTP / 1.1がそれ自体を独自の逆動作モードであるとすでに定義していることは、あまり知られていない事実です。 HTTPメッセージ形式の開始行を説明するRFC 7230 [RFC7230]のセクション3.1には、次のように記載されています。
In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats, but, in practice, servers are implemented to only expect a request [...] and clients are implemented to only expect a response.
理論的には、クライアントはリクエストを受信し、サーバーはレスポンスを受信し、それらを異なる開始行形式で区別できますが、実際には、サーバーはリクエストのみを期待するように実装され、クライアントは期待するだけを実装されます応答。
It is only convention that HTTP clients send HTTP requests and that HTTP servers send HTTP responses. Therefore, HTJP is just HTTP with some alternative conventions. It is not a distinct protocol. Furthermore, since all messages in HTJP are indistinguishable from HTTP messages, an HTJP peer would have no way of identifying itself explicitly as using HTJP rather than HTTP.
HTTPクライアントがHTTP要求を送信し、HTTPサーバーがHTTP応答を送信するのは単なる慣例です。したがって、HTJPは単なるHTTPであり、いくつかの代替規則があります。それは明確なプロトコルではありません。さらに、HTJP内のすべてのメッセージはHTTPメッセージと区別がつかないため、HTJPピアはHTTPではなくHTJPを使用していることを明示的に識別する方法がありません。
Therefore, we describe HTJP as a "pseudo-protocol" in order to distinguish clients, servers, and conversations that are using the HTTP conventions laid out in this document from those that use conventions that are more commonly associated with HTTP.
したがって、このドキュメントで説明されているHTTP規則を使用しているクライアント、サーバー、および会話を、より一般的にHTTPに関連付けられている規則を使用しているものと区別するために、HTJPを「疑似プロトコル」として説明します。
An HTJP request MUST be an HTTP response message. An HTJP response message MUST be an HTTP request message that, if issued to the appropriate HTTP server, would elicit the HTTP response specified by the HTJP request being replied to.
HTJP要求はHTTP応答メッセージでなければなりません。 HTJP応答メッセージは、適切なHTTPサーバーに発行された場合、応答されるHTJP要求によって指定されたHTTP応答を引き出すHTTP要求メッセージである必要があります。
As described in Section 3, HTJP is unconventional but valid HTTP, and so the entirety of the HTTP specification (as defined in [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]) MUST be respected when doing so is consistent with HTJP's unique semantics.
セクション3で説明したように、HTJPは型破りだが有効なHTTPであるため、HTTP仕様全体（[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]、および[RFC7235]で定義）そうすることは、HTJPのユニークなセマンティクスと一致するときに尊重されなければなりません。
The following example illustrates a typical message exchange for an HTJP request concerning the same hypothetical server from Section 2.1 of RFC 7230 [RFC7230].
次の例は、RFC 7230 [RFC7230]のセクション2.1の同じ架空のサーバーに関するHTJPリクエストの一般的なメッセージ交換を示しています。
Client request:
クライアントのリクエスト：
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My payload includes a trailing CRLF.
"こんにちは世界"私のペイロードには末尾のCRLFが含まれています。
Server response:
サーバーの応答：
GET /hello.txt HTTP/1.1 Host: www.example.com
GET /hello.txt HTTP / 1.1ホスト：www.example.com
Implementations of HTJP SHOULD respect Postel's Robustness Principle [IAB-PROTOCOL-MAINTENANCE].
HTJPの実装は、Postelの堅牢性原則[IAB-PROTOCOL-MAINTENANCE]を尊重する必要があります（SHOULD）。
Applied to HTJP, Postel's Robustness Principle implies that, given the choice of multiple valid HTJP responses for an HTJP request, one SHOULD prefer a response that is more adherent to the HTTP standard or uses fewer HTTP features. For example, sometimes a User-Agent header has no bearing on the HTTP response from an HTTP server. On seeing such a response in an HTJP request, an HTJP server could validly respond with a practically unlimited number of permutations on the User-Agent header value. However, it SHOULD prefer to respond with an HTTP request that has no User-Agent header whatsoever, in keeping with Postel's Robustness Principle.
HTJPに適用すると、Postelの堅牢性原則は、HTJPリクエストに対して複数の有効なHTJPレスポンスを選択した場合、1つのSHOULDがHTTP標準に準拠するか、使用するHTTP機能が少ないレスポンスを優先することを意味します。たとえば、User-AgentヘッダーがHTTPサーバーからのHTTP応答に影響しない場合があります。 HTJPリクエストでこのような応答を確認すると、HTJPサーバーは、User-Agentヘッダー値の実質的に無制限の順列で有効に応答できます。ただし、PostelのRobustness Principleに従って、User-AgentヘッダーのないHTTPリクエストで応答することを推奨します。
The same consideration applies when encountering an HTJP request for which there are both valid and "pseudo-valid" (Section 4.4) HTJP responses available.
有効なHTJP応答と「疑似有効」（4.4節）の両方が利用可能なHTJP要求が発生した場合も、同じ考慮事項が適用されます。
It may be of interest to a user of HTJP to try issuing an HTJP response as an HTTP request to the appropriate server. This brings up the issue of correctly identifying the host to which the HTJP response should be sent. Much of the time this will be able to be determined from the Host header field of the HTJP response. The Host header is required by conformant HTTP/1.1 requests. In the case that the Host header is not present (for example, if the HTJP response is an HTTP/1.0 request rather than HTTP/1.1), an HTJP response MAY use the absolute URI form in the HTTP request line, to add clarity about the target host if it would be validly accepted by the server. This specific example is complicated by the fact that prior to HTTP/1.1 it was not required that implementations accept the absolute URI form. For this reason, it is also possible to phrase the HTJP response as an HTTP request to a Forward Proxy server, which would have accepted, indeed needed, the absolute URI request line prior to and after HTTP/1.1. As a last resort, it may be possible to heuristically derive the target host of an HTJP response from the HTJP request; for example, the HTJP request may have absolute references to other HTTP resources that seem to come from the same host.
HTJPのユーザーは、適切なサーバーへのHTTP要求としてHTJP応答を発行することを試みるのが興味深いかもしれません。これにより、HTJP応答の送信先となるホストを正しく識別するという問題が発生します。ほとんどの場合、これはHTJP応答のホストヘッダーフィールドから判別できます。 Hostヘッダーは、適合するHTTP / 1.1要求で必要です。 Hostヘッダーが存在しない場合（たとえば、HTJP応答がHTTP / 1.1ではなくHTTP / 1.0要求である場合）、HTJP応答は、HTTP要求行で絶対URI形式を使用して、サーバーによって有効に受け入れられる場合のターゲットホスト。この特定の例は、HTTP / 1.1より前は、実装が絶対URI形式を受け入れる必要がなかったという事実によって複雑になっています。このため、HTJP応答をフォワードプロキシサーバーへのHTTP要求として表現することもできます。フォワードプロキシサーバーは、HTTP / 1.1の前後の絶対URI要求行を実際に受け入れます。最後の手段として、HTJP要求からHTJP応答のターゲットホストをヒューリスティックに導出することが可能な場合があります。たとえば、HTJPリクエストには、同じホストから送信されたように見える他のHTTPリソースへの絶対参照がある場合があります。
When an HTJP response is issued, there is no guarantee that, by the time the response is received by an HTJP client, the HTTP server that is associated with said response will still reply with it. Providing any guarantee about "when" an HTTP server would reply with said response is obviously a theoretically unsolvable problem and therefore outside the scope of this HTJP specification. It is only required that the HTJP response be correct at some point in the range of the 32-bit Unix Timestamp; see "Seconds Since the Epoch" (Section 4.16) of Unix General Concepts [UNIX-General-Concepts].
HTJP応答が発行された場合、HTJPクライアントが応答を受信するまでに、その応答に関連付けられているHTTPサーバーが応答することは保証されません。 HTTPサーバーが上記の応答で「いつ」応答するかについての保証を提供することは明らかに理論的に解決できない問題であり、したがってこのHTJP仕様の範囲外です。 32ビットUnixタイムスタンプの範囲内のある時点でHTJP応答が正しいことのみが必要です。 Unix General Concepts [UNIX-General-Concepts]の「Seconds From the Epoch」（セクション4.16）を参照してください。
HTJP servers that are responding with an HTTP request for a volatile resource, and with high confidence in the time range at which the resource would be in the state described by the HTJP request, MAY add a Date header to the HTJP response. This is in conformance with the ability for HTTP requests to carry a Date header; see Section 7.1.1.2 of [RFC7231].
揮発性リソースに対するHTTPリクエストで応答しているHTJPサーバーは、リソースがHTJPリクエストで記述された状態になる時間範囲の信頼性が高いため、DateヘッダーをHTJPレスポンスに追加できます。これは、HTTPリクエストがDateヘッダーを伝送する機能に準拠しています。 [RFC7231]のセクション7.1.1.2を参照してください。
HTJP clients can try to demand more temporal certainty by adding a Date header to their HTTP response, embedding criteria for the time of the HTTP response in the HTTP response itself. Of course, the client might still only receive that exact HTTP response if it manages to deliver the HTTP request at the precise time of the previously requested Date header, and even then it is still not guaranteed due to HTTP caching et cetera.
HTJPクライアントは、HTTP応答にDateヘッダーを追加し、HTTP応答自体にHTTP応答の時間の基準を埋め込むことで、より一時的な確実性を要求することができます。もちろん、クライアントは、以前にリクエストされたDateヘッダーの正確な時間にHTTPリクエストを配信できた場合にのみ、その正確なHTTP応答を受信する可能性があります。それでも、HTTPキャッシュなどにより、クライアントは保証されません。
In the wild, HTTP clients and servers have been known to occasionally exchange HTTP messages that are not conformant to any HTTP specification. For this reason, we will identify a class of messages that are, on the one hand, invalid HTTP messages, yet at the same time, correctly answerable HTJP requests or correct answers to an HTJP request, as "pseudo-valid" HTJP messages.
実際には、HTTPクライアントとサーバーは、HTTP仕様に準拠していないHTTPメッセージをときどき交換することが知られています。このため、一方では無効なHTTPメッセージでありながら、正しく応答可能なHTJP要求またはHTJP要求に対する正しい応答であるメッセージのクラスを、「疑似有効」HTJPメッセージとして識別します。
Consider, for example, an HTTP server that erroneously reports a Content-Length header field of zero when sending an HTTP payload of non-zero length. Despite this HTTP message violating the HTTP specification, it is possible for an HTJP server to receive such a message and correctly respond to it, satisfying the HTJP semantics in doing so.
たとえば、ゼロ以外の長さのHTTPペイロードを送信するときに誤ってゼロのContent-Lengthヘッダーフィールドを報告するHTTPサーバーについて考えてみます。このHTTPメッセージはHTTP仕様に違反していますが、HTJPサーバーがそのようなメッセージを受信して正しく応答し、HTJPのセマンティクスを満たしている可能性があります。
This applies to both HTJP requests and HTJP responses. There may be times when the only valid HTJP response is an invalid HTTP request. When there are both valid and invalid HTTP requests that could satisfy the HTJP request, Postel's Robustness Principle SHOULD be applied, as described in Section 4.1.
これは、HTJP要求とHTJP応答の両方に適用されます。有効なHTJP応答が無効なHTTPリクエストのみである場合があります。 HTJPリクエストを満たすことができる有効なHTTPリクエストと無効なHTTPリクエストの両方がある場合、セクション4.1で説明されているように、Postelのロバストネス原則を適用する必要があります（SHOULD）。
Given that an HTJP response MUST be an HTTP request, and that HTTP requests do not have a status field (such as a status code), there is no way for an HTJP response to signal a failure in response to an HTJP request, via a status code or otherwise. The correct HTJP response to an HTJP request when a server cannot determine an HTTP request that elicits the HTTP response is to not respond at all. The HTJP responder MAY close the connection; however, the HTJP requester MUST NOT interpret the closing of the connection as a response. This can have issues when HTJP servers are hosted behind non-HTJP-aware HTTP proxies, as the proxy may inject a 5xx HTTP response, which could be misinterpreted as an HTJP response. See more on proxies in Section 5.
HTJPレスポンスはHTTPリクエストでなければならず、HTTPリクエストにはステータスフィールド（ステータスコードなど）がないため、HTJPレスポンスがHTJPリクエストへの応答で失敗を通知する方法はありません。ステータスコードまたはその他。サーバーがHTTP応答を引き出すHTTP要求を判別できない場合のHTJP要求に対する正しいHTJP応答は、まったく応答しないことです。 HTJPレスポンダは接続を閉じてもよい（MAY）。ただし、HTJPリクエスターは、接続の終了を応答として解釈してはなりません（MUST NOT）。 HTJPサーバーが非HTJP対応のHTTPプロキシの背後でホストされている場合、プロキシが5xx HTTP応答を挿入する可能性があるため、HTJP応答として誤って解釈される可能性があるため、問題が発生する可能性があります。プロキシの詳細については、セクション5を参照してください。
Despite being valid HTTP traffic, support for caching and proxying of HTJP traffic is unfortunately not widespread. It is estimated that currently approximately 0.0% of all HTTP-aware intermediaries gracefully handle HTJP traffic. For this reason, it is currently RECOMMENDED that HTJP should not be deployed behind an HTTP proxying or caching layer. Support will likely increase proportionally to HTJP's popularity in production.
有効なHTTPトラフィックであるにもかかわらず、HTJPトラフィックのキャッシングとプロキシのサポートは、残念ながら広く普及していません。現在、すべてのHTTP対応仲介の約0.0％がHTJPトラフィックを正常に処理していると推定されています。このため、現在、HTJPをHTTPプロキシまたはキャッシングレイヤーの背後に配置しないことをお勧めします。サポートは、HTJPの製造における人気に比例して増加する可能性があります。
In order that implementations of this specification can operate correctly, and in accordance with [BCP90], the following new HTTP header field would need to be registered in the "Message Headers" registry maintained at <https://www.iana.org/assignments/message-headers/>. To find out the details of this registration, an application should send an HTJP request to a suitable server specifying the Anti-HTJP-Nonce value that the server would have supplied had the IANA registration been made.
この仕様の実装が正しく動作するためには、[BCP90]に従って、次の新しいHTTPヘッダーフィールドを<https://www.iana.org/で維持されている「メッセージヘッダー」レジストリに登録する必要があります。割り当て/メッセージヘッダー/>。この登録の詳細を確認するには、アプリケーションは、IANA登録が行われた場合にサーバーが提供するはずのAnti-HTJP-Nonce値を指定して、適切なサーバーにHTJP要求を送信する必要があります。
+-------------------+----------+---------------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+---------------+---------------+
| Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+-------------------+----------+---------------+---------------+
An incomplete implementation of HTJP is inadvisable from a security perspective. A complete implementation of HTJP may have interesting security features that are worthy of detailed examination. Due to its semantics, the issuing of a successfully authorized HTTP response to an HTJP server will result in a reply containing the HTTP request that elicits said response, including any credentials, tokens, cookies, or other authorization materials that were required to elicit that response.
HTJPの不完全な実装は、セキュリティの観点からはお勧めできません。 HTJPの完全な実装には、詳細な調査に値する興味深いセキュリティ機能がある場合があります。そのセマンティクスのために、HTJPサーバーへの正常に承認されたHTTP応答の発行は、その応答を引き出すために必要な資格情報、トークン、Cookie、またはその他の承認資料を含む、その応答を引き出すHTTP要求を含む応答になります。 。
As an example:
例として：
Client request:
クライアントのリクエスト：
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Content-Length: 61
Content-Type: text/plain
Some predictable information accessed using authorization.
承認を使用してアクセスされるいくつかの予測可能な情報。
Server response: (line breaks in the Authorization header are for RFC formatting)
サーバーの応答：（Authorizationヘッダーの改行はRFCフォーマット用です）
GET /information.txt HTTP/1.1 Host: authorised-usage-service.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ. JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0
GET /information.txt HTTP / 1.1 Host：authorised-usage-service.example.com Authorization：Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。 eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ。 JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0
Given that we cannot prevent anyone from attempting to implement HTJP, it is RECOMMENDED to consider how HTJP impacts security when using HTTP.
誰もがHTJPを実装しようとするのを防ぐことはできないため、HTTPを使用するときにHTJPがセキュリティに与える影響を検討することをお勧めします。
Note that it was only possible to query for the credentialed HTTP request because the response to the authorized request was predictable. HTTP servers could mitigate this vulnerability exposed by HTJP by only serving a response that is at least as secret as the credentials themselves in response to an authorized request.
承認されたリクエストへの応答は予測可能であったため、認証されたHTTPリクエストのクエリのみが可能であったことに注意してください。 HTTPサーバーは、承認された要求に応答して、資格情報自体と少なくとも同じくらい秘密の応答のみを提供することにより、HTJPによって公開されたこの脆弱性を緩和することができます。
A generic solution to this problem is to use an "Anti-HTJP-Nonce" HTTP header in HTTP responses. The value of an "Anti-HTJP-Nonce" header SHOULD be a cryptographically secure random number in any encoding that is valid for an HTTP header value. The length of this number SHOULD be determined by the producer of the HTTP response, accounting for their method of random number generation and their threat model.
この問題の一般的な解決策は、HTTP応答で「Anti-HTJP-Nonce」HTTPヘッダーを使用することです。 "Anti-HTJP-Nonce"ヘッダーの値は、HTTPヘッダー値に有効な任意のエンコーディングの暗号的に安全な乱数である必要があります（SHOULD）。この数の長さは、HTTP応答のプロデューサーによって決定されるべきであり（SHOULD）、乱数生成の方法と脅威モデルを考慮に入れます。
HTJP, being just HTTP, has most of the same security concerns and features as HTTP itself. For example, the use of HTJP over an encrypted connection, such as TLS 1.3 [RFC8446], similar to HTTP Secure (HTTPS), is referred to as HTJP Secure (HTJPS). However, it is important to note that, unlike with HTTPS, it is not expected that the hostname you are securely communicating with is the same hostname as featured in the Host headers or absolute URIs of the HTJP messages themselves, as HTJP messages are typically referring to other HTTP hosts. This excludes the case of a server that supports both conventional HTTP and HTJP, where it is possible to make HTJP requests securely to the same host that is also the subject of the HTJP requests being made.
HTJPは単なるHTTPであり、HTTP自体とほとんど同じセキュリティ上の懸念と機能を備えています。たとえば、HTTP Secure（HTTPS）に類似した、TLS 1.3 [RFC8446]などの暗号化された接続でのHTJPの使用は、HTJP Secure（HTJPS）と呼ばれます。ただし、HTTPSとは異なり、安全に通信しているホスト名は、HTJPメッセージ自体のホストヘッダーまたは絶対URIで機能しているホスト名と同じであるとは想定されていないことに注意してください。他のHTTPホストへ。これは、従来のHTTPとHTJPの両方をサポートするサーバーの場合を除きます。この場合、HTJP要求の対象でもある同じホストにHTJP要求を安全に行うことができます。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<https://www.rfc-editor.org/info/rfc7232> 。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Lafon、Y.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests"、RFC 7233、DOI 10.17487 / RFC7233、June 2014、<https://www.rfc-editor.org/info/rfc7233>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<https://www.rfc-editor.org/info/rfc7235>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[UNIX-General-Concepts] "General Concepts", Chapter 4 of "The Open Group Base Specifications, Issue 7", 2018 edition, IEEE Std 1003.1-2017, 2018, <http://pubs.opengroup.org/ onlinepubs/9699919799/basedefs/V1_chap04.html>.
[UNIX-General-Concepts]「一般概念」、「The Open Group Base Specifications、Issue 7」の第4章、2018年版、IEEE Std 1003.1-2017、2018、<http://pubs.opengroup.org/ onlinepubs / 9699919799 / basedefs / V1_chap04.html>。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004, <https://www.rfc-editor.org/info/bcp90>.
[BCP90] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月、<https://www.rfc-editor.org/info / bcp90>。
[IAB-PROTOCOL-MAINTENANCE] Thomson, M., "The Harmful Consequences of the Robustness Principle", Work in Progress, draft-iab-protocol-maintenance-02, March 2019.
[IAB-PROTOCOL-MAINTENANCE] Thomson、M。、「Robustness Principleの有害な結果」、作業中、draft-iab-protocol-maintenance-02、2019年3月。
[RFC8446] 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>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
Also worth mentioning, in case one encounters it in the wild, is the Hypertext Double Jeopardy Protocol (HTJ2P). The Hypertext Double Jeopardy Protocol 1.0 is a stateless application-level request/ response protocol that functions as the inverse of the Hypertext Jeopardy Protocol (HTJP) 1.0 .
言及する価値があるのは、実際に遭遇した場合に備えて、Hypertext Double Jeopardy Protocol（HTJ2P）です。 Hypertext Double Jeopardy Protocol 1.0は、Hypertext Jeopardy Protocol（HTJP）1.0の逆として機能する、ステートレスなアプリケーションレベルの要求/応答プロトコルです。
An HTJ2P response MUST be an HTTP response which would be issued for an HTTP request delivered as the HTJ2P request. Implementations of HTJ2P have groundbreaking potential in the fields of HTTP caching, and in the implementation of HTJP.
HTJ2P応答は、HTJ2P要求として配信されるHTTP要求に対して発行されるHTTP応答である必要があります。 HTJ2Pの実装は、HTTPキャッシングの分野とHTJPの実装において画期的な可能性を秘めています。
Acknowledgements
謝辞
The author thanks Alex Trebek for his distinguished contributions to culture and society. The author thanks Peter Phillips for the suggestion of the Anti-HTJP-Nonce header. The author also wishes to thank anyone who has ever built a tool or a technology that made people ask "Why?".
著者は、文化と社会への顕著な貢献に対してアレックス・トレベックに感謝します。著者は、Anti-HTJP-Nonceヘッダーの提案についてPeter Phillipsに感謝します。著者はまた、人々に「なぜ？」と尋ねさせるツールやテクノロジーを構築したことがある人に感謝したいと思います。
Author's Address
著者のアドレス
Edmund Fokschaner
エドマンドフォクシェナー
Email: edfokschaner@gmail.com