はじめに
- この文書は RFC8565 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
Hypertext Jeopardy Protocol (HTJP/1.0)
- Independent Submission
- Request for Comments: 8565
- Category: Informational
- ISSN: 2070-1721
- E. Fokschaner
- 1 April 2019
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 のセマンティクスを規定する。
※訳注：アメリカの人気クイズ番組「Jeopardy!」では、通常のクイズの出題・回答とは逆になっているところから。以下 wikipedia からの引用。末尾にある「謝辞」も参照のこと。
クイズは司会者が問題文を全文読み上げてからの早押し形式で行われる。問題文はほとんどが短文あるいは数個の単語であり、日本のクイズ番組で見られる「日本で最も高い山は何でしょう？」といった質問文形式ではなく、「それは日本で最も高い山です」といった事実の形で書かれている。回答者は「富士山とはどんな山でしょう？」のように質問文形式で回答する。
Status of This Memo（このメモの位置づけ）
This document is not an Internet Standards Track specification; it is published for informational purposes.
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.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.
この文書はインターネット標準化過程の仕様ではなく、情報提供の目的で発行されたものである。
この文書は、他のいかなる RFC ストリームとも無関係に、RFC シリーズに貢献するものである。
RFC エディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFC エディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない。
この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、 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.
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.
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
1. Introduction（序論）
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:
- Where an HTTP client would send an HTTP request message, an HTJP client would send an HTTP response message.
- Where an HTTP server would send an HTTP response message, an HTJP server would send an HTTP request message.
- 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.
HTTPとの関係では、おおよそ次のような規則で規定される：
- HTTP クライアントが HTTP 要求メッセージを送信する代わりに、HTJP クライアントは HTTP 応答メッセージを送信する。
- HTTP サーバーが HTTP 応答メッセージを送信する代わりに、HTJP サーバーは HTTP 要求メッセージを送信する。
- 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:
- Generative automated testing of HTTP implementations and HTTP-based applications.
- Monitoring of HTTP-based applications in production.
- Forensic and diagnostic reconstruction of HTTP requests from HTTP response logs.
- Discovery of first-party and third-party security vulnerabilities.
HTJP は以下のすべての領域で新しいアプリケーションを持っている。
- HTTP の実装と HTTP ベースのアプリケーションの生成的な自動テスト。
- HTTP ベースのアプリケーションの実運用での監視。
- HTTP 応答ログからの HTTP 要求の法医学的、診断的再構成。
- ファーストパーティとサードパーティのセキュリティ脆弱性の発見。
2. Conventions Used in This Document（本文書で使用されている規約）
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] に記載されているように解釈することとする。
3. Comparison with HTTP（HTTP との比較）
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 を「疑似プロトコル」と表現している。
4. Response and Request Semantics（応答と要求のセマンティック）
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 応答メッセージでなければならない (MUST)。
HTJP 応答メッセージは、適切な HTTP サーバーに発行された場合、返信される HTJP 要求によって指定された HTTP 応答を引き出す HTTP 要求メッセージでなければならない (MUST)。
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 独自のセマンティクスと矛盾しない限り尊重されなければならない (MUST)。
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.
Server response:
サーバーの応答：
GET /hello.txt HTTP/1.1
Host: www.example.com
4.1. Applicability of Postel's Robustness Principle（ポステルのロバスト性原則の適用性）
Implementations of HTJP SHOULD respect Postel's Robustness Principle [IAB-PROTOCOL-MAINTENANCE].
HTJP の実装は、ポステルのロバスト性原則 [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 に適用されるポステルのロバスト性原則は、HTJP 要求に対して複数の有効な HTJP 応答ある場合、HTTP 標準により忠実であるか、より少ない HTTP 機能を使用する応答を選ぶべきであることを意味する (SHOULD)。
例えば、User-Agent ヘッダーが HTTP サーバーからの HTTP 応答に関係しないことがある。
HTJP 要求でこのような応答を見た場合、HTJP サーバーは User-Agent ヘッダーの値を実質的に無制限に変更して応答することができる。
しかし、ポステルのロバスト性原則に従って、User-Agent ヘッダーのない HTTP 要求で応答すべきである (SHOULD)。
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 応答の両方が利用可能な HTJP 要求に遭遇した場合も、同様の考慮が必要である。
4.2. Identifying the Server Associated with an HTJP Response（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 のユーザーにとって、HTJP の応答を HTTP 要求として適切なサーバーに発行してみることは興味深いことだろう。
これは HTJP 応答の送信先となるホストを正しく特定するという問題を提起している。
多くの場合、これは HTJP 応答の Host ヘッダーフィールドから決定することができる。
Host ヘッダーは HTTP/1.1 準拠の要求で要求される。
Host ヘッダーが存在しない場合 (例えば、HTJP 応答が HTTP/1.1 ではなく HTTP/1.0 の要求である場合)、HTJP 応答は HTTP 要求行で絶対 URI 形式を使用してもよい (MAY)。
この具体例は、HTTP/1.1 以前には実装が絶対 URI 形式を受け入れることを要求されていなかったという事実によって、複雑になっている。
この理由から、HTTP/1.1 以前も以後も絶対 URI 要求行を受け入れ、実際に必要としたであろう Forward Proxy サーバーへの HTTP 要求として HTJP 応答を表現することも可能である。
最後の手段として、HTJP 応答のターゲットホストを HTJP 要求から発見的に導き出すことが可能かもしれない。例えば、HTJP 要求は同じホストから来たと思われる他の HTTP リソースへの絶対参照を持つことがある。
4.3. Temporal Considerations（時間的な考慮事項）
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 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].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 応答が発行されたとき、その応答を HTJP クライアントが受信するまでに、その応答に関連する HTTP サーバーがまだその応答を返信するという保証はない。
HTTP サーバーが「いつ」その応答を返すかについての保証は、明らかに理論的に解決不可能な問題であり、したがって本 HTJP 仕様の範囲外である。
Unix General Concepts [UNIX-General-Concepts] の "Seconds Since the Epoch" (4.16 節) を参照。
揮発性リソースに対する HTTP 要求で応答する HTJP サーバーは、リソースが HTJP 要求で記述された状態になる時間範囲に高い信頼性を持っている場合、HTJP 応答に Date ヘッダーを追加してもよい (MAY)。
これは HTTP 要求が Date ヘッダーを持つことに準拠する。[RFC7231] の 7.1.1.2 参照。
HTJP クライアントは、HTTP 応答に Date ヘッダーを追加し、HTTP 応答の時間に関する基準を HTTP 応答自体に埋め込むことによって、より時間的確実性を要求しようとすることができる。
もちろん、クライアントは、先に要求された Date ヘッダーの正確な時刻に HTTP 要求を配送できた場合にのみ、その正確な HTTP 応答を受け取ることができるし、その場合でも、HTTP キャッシュなどのために保証されるわけではない。
4.4. Pseudo-Valid HTJP Messages（疑似的に有効な HTJP メッセージ）
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.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.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.
一部の HTTP のクライアントとサーバーは、HTTP の仕様に準拠しない HTTP メッセージをやり取りすることが知られている。
このため、一方では無効な HTTP メッセージでありながら、同時に HTJP 要求に正しそうに応答できる、あるいは HTJP 要求に正しく応答するメッセージを「疑似的に有効」な HTJP メッセージとして識別することにする。
例えば、長さが 0 でない HTTP ペイロードを送信する際に、誤って Content-Length ヘッダーフィールドを 0 と報告する HTTP サーバーを考えてみる。
この HTTP メッセージは HTTP 仕様に違反しているが、HTJP サーバーはこのようなメッセージを受信して正しく応答し、そうすることで HTJP のセマンティクスを満足させることが可能である。
これは HTJP 要求と HTJP 応答の両方に当てはまる。
有効な HTJP 応答が無効な HTTP 要求のみである場合もありえる。
HTJP 要求を満たすことができる有効な HTTP 要求と無効な HTTP 要求の両方が存在する場合、4.1 節で説明されているように、ポステルのロバスト性原則が適用されるべきである (SHOULD)。
4.5. HTTP Responses That Are Not Requestable（要求できない HTTP 応答）
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 要求でなければならず (MUST)、HTTP 要求は (ステータスコードのような) ステータスフィールドを持たないことを考えると、HTJP 応答がステータスコードやその他の方法で HTJP 要求に対する失敗を通知する方法はない。
HTTP 応答を引き出す HTTP 要求をサーバーが判断できない場合の正しい HTJP 応答は、全く応答しないことである。
HTJP 応答側はコネクションを閉じてもかまわないが (MAY)、HTJP 要求側はコネクションのクローズを応答と解釈してはならない (MUST NOT)。
これは、HTJP サーバーが HTJP を認識しない HTTP プロキシの背後でホストされている場合、プロキシが 5xx HTTP 応答を注入し、それが HTJP 応答と誤解される可能性があるため、問題となることがあるためである。
プロキシについては 5 章を参照すること。
5. Caches and Proxies（キャッシュとプロキシ）
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 を認識する中継装置のうち、HTJP トラフィックを正しく処理するものは約 0.0% であると推定される。
このため、現在、HTJP は HTTP プロキシやキャッシュ層の背後に配置しないことが推奨される (RECOMMENDED)。
HTJP のサポートは、実運用における HTJP の普及に比例して増加すると思われる。
6. IANA Considerations（IANA に関する考慮事項）
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/assignments/message-headers/ で管理される「Message Headers」レジストリに登録される必要があるだろう。
この登録の詳細を知るために、アプリケーションは適切なサーバーに HTJP 要求を送り、IANA 登録がなされていればサーバーが提供したであろう Anti-HTJP-Nonce 値を指定するべきである。
+-------------------+----------+---------------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+---------------+---------------+
| Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+-------------------+----------+---------------+---------------+
7. Security Considerations（セキュリティに関する考慮事項）
7.1. Securing HTTP against HTJP（HTJPに対するHTTPの安全性確保）
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 応答の発行は、その応答を引き出すために必要とされた認証情報、トークン、クッキー、その他の認証材料を含む、その応答を引き出した 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
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 がどのようにセキュリティに影響を与えるかを検討することが推奨される (RECOMMENDED)。
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 応答として）可能であったことに注意すること。
HTTP サーバーは、認証された要求に対して少なくとも認証情報自身と同程度の秘密の応答を提供するだけで（訳注：つまり、HTTP 応答を推測困難にすれば）、HTJP によって公開されたこの脆弱性を緩和することができる。
7.1.1. Anti-HTJP-Nonce Header（Anti-HTJP-Nonce ヘッダー）
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)。
7.2. HTJPS
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 メッセージは通常他の HTTP ホストを参照しているため、安全な通信相手のホスト名が Host ヘッダーや HTJP メッセージ自体の絶対 URI に記載されているのと同じホスト名であることは期待できないことに注意が必要である。
これは、従来の HTTP と HTJP の両方をサポートするサーバーが、HTJP 要求の対象である同じホストに対して安全に HTJP 要求を行うことが可能な場合を除く。
8. References
8.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/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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
8.2. Informative References
[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>.
[IAB-PROTOCOL-MAINTENANCE]
Thomson, M., "The Harmful Consequences of the Robustness
Principle", Work in Progress, draft-iab-protocol-
maintenance-02, March 2019.
[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>.
Appendix A. Hypertext Double Jeopardy Protocol
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 .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.
また、Hypertext Double Jeopardy Protocol (HTJ2P) も、万が一必要になった場合のために触れておく価値がある。
Hypertext Double Jeopardy Protocol 1.0 は、Hypertext Jeopardy Protocol (HTJP) 1.0 の逆として機能するステートレスなアプリケーションレベルの要求/応答プロトコルである。
HTJ2P 応答は、HTJ2P 要求として配信された HTTP 要求に対して発行される HTTP 応答でなければならない (MUST)。
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?".
Alex Trebek 1 の文化と社会への卓越した貢献に感謝します。
Anti-HTJP-Nonce ヘッダーを提案してくれた Peter Phillips に感謝します。
著者はまた、人々に「なぜ？」と問うような道具や技術を作ったことのあるすべての人に感謝します。
Author's Address
Edmund Fokschaner
Email: edfokschaner@gmail.com
-
アメリカのクイズ番組「Jeopardy!」の司会者。2019年3月6日にすい臓がんであることを発表。2020年11月8日に闘病の末亡くなった。この RFC は2019年4月1日発行。 ↩