RFC 8565 ハイパーテキスト危険プロトコル (HTJP/1.0) Independent Submission E. Fokschaner Request for Comments: 8565 1 April 2019 Category: Informational ISSN: 2070-1721 ハイパーテキスト危険プロトコル (HTJP/1.0) 概要 ハイパーテキスト危険プロトコル (HTJP) はハイパーテキスト転送プロトコル (HTTP)のリクエスト/応答の意味を逆転します。 従来のHTTPでは、サーバに接続し、リクエストをし、正しい応答を期待します。 HTJPを使うと、サーバに接続し、リクエストを送信し、正しい質問を期待します。 この文章はHTJPの意味を指定します。 このメモの位置付け この文書では、インターネット標準化過程の仕様ではありません、それは情報目的のために公開されています。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなるレベルの候補でもありません。RFC7841のセクション2を見てください。 このドキュメントの現在の状況、正誤表、フィードバックの提供の仕方の情報については、https://www.rfc-editor.org/info/rfc7168 で得られるでしょう。 https://www.rfc-editor.org/info/rfc8565. 著作権 Copyright (c) 2019 IETF Trust and the persons identified as the document authors. 無断転載禁ず このドキュメントはBCP78とこのドキュメントの公表日に実施されているIETFドキュメントに関するIETF信託の法律条項 (https://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を確認してください。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 2 2. この文章で使われる約束事 . . . . . . . . . . . . . . 3 3. HTTPとの比較 . . . . . . . . . . . . . . . . . . . . 3 4. 応答とリクエストの意味 . . . . . . . . . . . . . . . 4 4.1. Postelの堅牢性原則の適用性 . . . . . 4 4.2. HTJP応答に関係するサーバの識別 . 5 4.3. 一時的な考慮 . . . . . . . . . . . . . . . . . 5 4.4. 擬似的な有効なHTJPメッセージ . . . . . . . . . . . . . . . 6 4.5. リクエストできないHTTP応答 . . . . . . . . . 6 5. キャッシュとプロキシ . . . . . . . . . . . . . . . . . . . . . 7 6. IANA 問題 . . . . . . . . . . . . . . . . . . . . . 7 7. セキュリティ問題 . . . . . . . . . . . . . . . . . . . 7 7.1. HTJPに対するHTTPの保護 . . . . . . . . . . . . . . . 7 7.1.1. Anti-HTJP-Nonce ヘッダ . . . . . . . . . . . . . . . 8 7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. 参照 . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. 標準の表記 . . . . . . . . . . . . . . . . . . 9 8.2. 引用 . . . . . . . . . . . . . . . . . 10 付録 A. ハイパーテキスト2重危険プロトコル . . . . . . . . . 11 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . 11 著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . . 11 1. はじめに ハイパーテキスト危険プロトコルはハイパーテキスト転送プロトコル (HTTP) 1.1の逆の意味として機能するステートレスなアプリケーションレベルの応答/リクエスト プロトコルです。 以下の規則に従ってHTTPに関して大まかに指定することができます: o HTTPクライアントがHTTPリクエストをメッセージを送信する場面で、HTJPはHTTP応答メッセージを送信します。 o HTTPサーバがHTTP応答メッセージを送信する場面で、HTJPサーバはHTTPリクエスト メッセージを送信します。 o HTJP応答として送信されたHTTPリクエストは、(適切なHTTPサーバに送信された場合は)HTJPリクエストの中で送信されるHTTP応答を引き出すHTTPリクエストでなければなりません。 HTJPはHTTP/1.1仕様と互換性があります。形式では無くとも少なくとも精神的に。 HTJPは以下の全ての分野で新しい用途があります: o HTTP実装とHTTPベースのアプリケーションの生成的な自動化テスト。 o プロダクションのHTTPベースのアプリケーションの監視。 o HTTP応答ログからのHTTPリクエストのフォレンシックおよび診断的な再構築。 o 自身および第三者のセキュリティ脆弱性の発見。 2. この文章で使われる約束事。 この文章中の「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である(REQUIRED)」、「SHALL(するものとする)」、「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「推奨されない(NOT RECOMMENDED)」、「してもよい(MAY)」および「任意である(OPTIONAL)」のキーワードは、ここで示されるように全て大文字で現れる時のみ BCP 14 [RFC2119] [RFC8174]に記述されているとおりに解釈されます。 3. HTTPとの比較 HTTP/1.1 がすでに操作の独自の逆モードを自身で定義していることはあまり知られていません。 RFC 7230 [RFC7230] のセクション3.1で、HTTPメッセージ形式の開始行を説明していて、以下のように述べられています: 理論的には、異なる開始行の形式によって識別することで、クライアントはリクエストを受信し、サーバが応答を受信することができます。しかし実際にはサーバはリクエストのみを期待するように実装され [...] クライアントは応答のみを期待するように実装されます。 HTTPクライアントがHTTPリクエストを送信し、HTTPサーバがHTTP応答を送信することは、慣例でしかありません。 従って、HTJPはいくらかの別の慣例を持つHTTPに過ぎません。 それは異なるプロトコルではありません。 さらに、HTJPの全てのメッセージはHTTPメッセージと区別が付かないため、HTJPのピアはHTTPではなくHTJPを使っていると明示的に識別する方法を持ちません。 そのため、この文章内で述べられているHTTP規約を使っているクライアント、サーバおよび通信を、もっと一般的にHTTPに関係している規約と区別するために、HTJPを "擬似プロトコル"として説明します。 4. 応答とリクエストの意味 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. 以下の例は、RFC 7203 [RFC7230] のセクション 2.1 と同じ仮想的なサーバを考慮するHTJJPリクエストについての典型的なメッセージ交換を示します。 クライアントのリクエスト: 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. サーバの応答: GET /hello.txt HTTP/1.1 Host: www.example.com 4.1. Postelの堅牢性原則の適用性 HTJPの実装はPostelの堅牢性原則 [IAB-PROTOCOL-MAINTENANCE] に留意しなければなりません。 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. The same consideration applies when encountering an HTJP request for which there are both valid and "pseudo-valid" (Section 4.4) HTJP responses available. 4.2. HTJP応答に関係するサーバの識別 HTJPのユーザにとって、適切なサーバにHTTPリクエストとしてHTJP応答を発行してみることは興味深いことです。 これによりHTJP応答がどのホストに送信されなければならないかを正確に識別するという問題が起こります。 ほとんどの場合において、これはHTJP応答のHostヘッダフィールドから決定することができるでしょう。 Hostヘッダは HTTP/1.1 リクエストの適合によって必要とされます。 Hostヘッダが存在しない場合(例えば、もしHTJP応答がHTTP/1.1ではなくHTTP/1.0リクエストの場合)、HTJP応答はサーバによって有効なものとして受け付けられる場合には目的のホストについて明瞭さを追加するためにHTTPリクエスト行の中に絶対URI形式を使うかもしれません。 この具体的な例は、HTTP/1.1より前の実装では絶対URI形式を受け付ける必要がなかったという事実によって複雑化されています。 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. 4.3. 一時的な考慮 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. HTJP応答が幾つかの点で32ビットUnixタイムスタンプの範囲で正しいことだけが必要です; "Epochからの秒数"を見てください Unix General Concepts [UNIX-General-Concepts] の(セクション 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. これは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. 4.4. 擬似的な有効なHTJPメッセージ 実際には、HTTPクライアントとサーバはHTTP仕様に準拠していないHTTPメッセージを時々交換することが知られています。 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ペイロードを送信する時に誤ってゼロのContent-Lengthヘッダフィールドを報告するHTTPサーバを考えてみましょう。 このHTTPメッセージがHTTP仕様に違反しているにも関わらず、HTJPサーバはそのようなメッセージを受信してHTJPのセ万ティクスを満たしながら正しく応答することができます。 これはHTJPリクエストとHTJP応答の両方に当てはまります。 唯一のHTJP応答が無効なHTTPリクエストである場合があります。 HTJPリクエストを満たすことができる有効および無効なHTTPリクエストの両方がある場合、セクション 4.1 で説明されるように、Postelの堅牢性原則が適用されるべきです。 4.5. リクエストできないHTTP応答 HTJP応答はHTTPリクエストでなければならず、HTTPリクエストは(ステータスコードのような)ステータス フィールドを持たないと考えると、HTJP応答がステータスコードなどを使ってHTJPリクエストに応答して失敗を知らせる方法はありません。 サーバがHTTP応答を引き出すHTTPリクエストを決定できない場合にHTJPリクエストに対する正しいHTJP応答は、全く応答しないことです。 HTJPレスポンダは接続を閉じることができます; しかし、HTJPリクエスタは接続の切断を応答として解釈してはなりません。 プロキシが5xx応答を挿入する可能性があるため、HTJPサーバがHTJP非対応のHTTPプロキシの背後でホストされている場合は、これが問題になるかもしれません。5xx HTTP応答がHTJP応答と間違って解釈されるかもしれません。 セクション 5のプロキシを参照してください。 5. キャッシュとプロキシ 有効なHTTPトラフィックにも関わらず、HTJPトラフィックのキャッシュとプロキシは残念ながら普及していません。 現在、HTTPを認識する全ての中継の約0.0%がHTJPトラフィックを適切に処理すると推定されています。 このため、HTJPはHTTPプロキシあるいはキャッシュ層の背後に配備しないことが現在のところ推奨されています。 HTJPのプロダクションでの人気に比例してサポートが増加するでしょう。 6. IANA 問題 この仕様の実装が正しく動作するために、そして [BCP90] に従って、以下の新しいHTTPヘッダ フィールドが で維持されている "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. +-------------------+----------+---------------+---------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+---------------+---------------+ | Anti-HTJP-Nonce | http | informational | Section 7.1.1 | +-------------------+----------+---------------+---------------+ 7. セキュリティ問題 7.1. HTJPに対するHTTPの保護 HTJPの不完全な実装はセキュリティの観点からお勧めできません。 HTJPの完全な実装は詳細な検討に値する興味深いセキュリティ機能を持っているかもしれません。 そのセマンティクスにより、HTJPサーバへの認証に成功したHTTP応答の発行は、その応答を引き出すHTTPリクエストを含む応答をもたらすでしょう。 例: クライアントのリクエスト: 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. サーバの応答: (認証ヘッダ内の改行はRFC形式のためのものです) GET /information.txt HTTP/1.1 Host: authorised-usage-service.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ. JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0 誰かがHTJPを実装しようとすることを防ぐことができないため、HTTPを使ったときにHTJPがセキュリティにどのような影響を与えるかを検討することをお勧めします。 認証された要求に対する応答は予想可能だったため、認証されたHTTPリクエストを照会することだけが可能なことに注意してください。 HTTPサーバは承認されたリクエストに応答して少なくとも資格情報自体と同じくらい秘密の応答を提供するだけで、HTJPによって公開されるこの脆弱性を緩和することができます。 7.1.1. Anti-HTJP-Nonce ヘッダ この問題に対する一般的な解決策は、HTTP応答に "Anti-HTJP-Nonce" HTTP ヘッダを使うことです。 "Anti-HTJP-Nonce" ヘッダの値は、HTTPヘッダの値として有効な任意のエンコーディングの暗号学的に安全な乱数であるべきです。 この数の長さは、乱数生成の方法とその脅威モデルを考慮して、HTTP応答のプロデューサによって決定されるべきです。 7.2. HTJPS 単なるHTTPであるHTJPはHTTP自体とほとんど同じセキュリティ上の懸念と機能を持っています。 例えば、HTTP Secure (HTTPS)と同様のTLS 1.3 [RFC8446]のような暗号化された接続上のHTJPの使用は、HTJP Secure (HTJPS)と呼ばれます。 ただし、HTTPSと異なり、HTJPメッセージは一般的に他のHTTPホストを参照しているため、安全に通信しているホスト名がHTJPメッセージ自体のHostヘッダまたは絶対URLに記載されているものと同じホスト名であるとは想定されていないことに注意することが重要です。 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. 8. 参照 8.1. 参照する参考文献 [RFC2119] Bradner, S., "RFCで要求レベルを表すために使われるキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): セマンティクスとコンテント", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): 条件付きリクエスト", RFC 7232, DOI 10.17487/RFC7232, June 2014, . [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): Rangeリクエスト", RFC 7233, DOI 10.17487/RFC7233, June 2014, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): キャッシュ", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "ハイパーテキスト転送プロトコル (HTTP/1.1): 認証", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC8174] Leiba, B., "RFC 2119 キーワードでの大文字と小文字の曖昧さ", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UNIX-General-Concepts] "General Concepts", Chapter 4 of "The Open Group Base Specifications, Issue 7", 2018 edition, IEEE Std 1003.1-2017, 2018, . 8.2. 有益な参考文献 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "メッセージ ヘッダ フィールドについての登録手順", BCP 90, RFC 3864, September 2004, . [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, . Appendix A. Hypertext Double Jeopardy Protocol また、実際に遭遇した場合に言及する価値があるハイパーテキスト2重危険プロトコル (HTJ2P)。 ハイパーテキスト2重危険プロトコル 1.0 はハイパーテキスト危険プロトコル (HTJP) 1.0 の逆の機能のステートレスなアプリケーションレベルのリクエスト/応答プロトコルです。 HTJ2P 応答はHTJ2Pリクエストとして配送されるHTTPリクエストについて発行されるHTTP応答でなければなりません。 HTJ2Pの実装はHTTPキャッシュおよびHTJPの実装において画期的な可能性を秘めています。 謝辞 Alex Trebekに彼の文化と社会への著しい貢献について感謝します。 Peter Phillips に Anti-HTJP-Nonce ヘッダの提案について感謝します。 また、人々に「なぜ？」と尋ねさせるツールあるいは技術をこれまでに構築したことのある人に感謝します。 著者のアドレス Edmund Fokschaner Email: edfokschaner@gmail.com