|
ネットワーク WG Request for Comments： 2817 更新対象： 2616 分類： スタンダードトラック |
R. Khare 4K Associates / UC Irvine S. Lawrence Agranat Systems, Inc. 2000年5月 |
本書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、 「Internet Official Protocol Standards」 (STD 1)の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (2000). All Rights Reserved.
このメモは、 「既存のTCPコネクション上において、 TLS (Transport Layer Security)を開始するためのHTTP/1.1にあるUpdateメカニズムの使い方」を説明する。 これにより、セキュア化されていないHTTPと、 セキュア化されたHTTPのトラフィックが同一のwell knownポートを共有できるようになる。 (この場合、443番のhttps:ではなく、80番のhttp:となる。) また、これにより、「バーチャルホスティング」が可能になるので、 1台の(HTTP + TLS)サーバーで、 1つのIPアドレスを共有する複数のバーチャルホストへのトラフィック処理を特定できるようになる。
最後に、このメモは、 公衆用HTTP状態コードについての新しいIANAのレジストリを確立するとともに、 公衆用もしくは私用のUpgrade製品トークンについてのレジストリを確立する。
このメモは、現行の'https' URIスキームの定義には影響しない。 このスキームは、既に、 'http'とは別の名称空間を形成している。 (http://example.org/とhttps://example.org/は、同等ではない)。
HTTP over SSL3 [3] の採用についてのこれまでの実践において、 この組み合わせの場合を固有のURIスキームとTCPポート番号によってHTTP を単独で使う場合とは区別してきた。 'http'のスキームは、 80番ポートにおけるHTTPプロトコル単独を意味し、 一方'https'は、 443番ポートにおけるSSL上のHTTPプロトコルを意味している。 同様に、 他のアプリケーションプロトコル(例：snews, ftps)のセキュア化された利用とセキュア化されていない利用を区別するために、 それぞれにwell-knownポート番号が要求され(場合によっては、 割り当てられ)ている。 このアプローチは、 利用可能なwell knownポートの数を効果的に半減させる。
1997年12月のワシントンDC IETFミーティングにおいて、 アプリケーションエリアのディレクターらとIESGは、 「別途「セキュア」ポート番号を割り当てる実践を止める必要がある」と再度主張した。 HTTP/1.1 Upgradeメカニズムは、 TLS [6] をオープンなHTTPコネクションに適用できる。
以来、約2年間、 この提案の背後にある概念が広く受容されてきたが、 一般的なWebブラウザのために443番ポートを使う方法についての代替法を実装することについて関心は少なかった。 実際、このメモ中には、 現行のhttps: URIの解釈に影響を与える事項は無い。 しかし、Internet Printing ロトコル [7] のような新しいアプリケーションプロトコルは、 HTTPの上に構築されており、IETF標準化過程において進めるために、 ちょうどこのようなメカニズムを求めている。
また、Upgradeメカニズムは、 「バーチャルホスティング」問題も解決する。 1つのホストに複数のIPアドレスを割り当てるのではなく、 HTTP/1.1 サーバーは、 意図するWebサービスを特定するためにHost:ヘッダーを使う。 HTTP/1.1利用が普及するに従って、 より多くのISPが名前に基づくバーチャルホスティングを提供するようになっているが、 IPアドレス空間の枯渇を遅らせることになる。
TLS(およびSSL)は、 以前のバージョンのHTTPと同様の制約を引きずっている。： 最初のハンドシェイクは、意図するホスト名を指定せず、 IPアドレスのみに頼っている。 TLSハンドシェイクにおける平文HTTP/1.1 Upgrade:の使用(初期Host:ヘッダーに基づく証明書の選択)は、 ISPが名前に基づくセキュアなバーチャルホスティングも提供できるようにする。
(SSL (Secure Sockets Layer)としても知られている)TLSは、 様々な暗号システムを使ってプライベートな「エンド to エンド」コネクションを確立し、 オプションとして強い相互認証を含む。 最初に、ハンドシェイク段階では、レコード層を確立し、 終端の認証をし、パラメータを設定し、エラーを報告するために、 3つのサブプロトコルを使う。 次に、 そのコネクションの以降の部分を暗号化・圧縮・再構築する処理を扱う、 処理が階層化されたレコードプロトコルがある。 後者は、完全に透過的であることを意図された。 例えば、TLSのレコードマーカーかつ／または証明書と、 HTTP/1.1のチャンクされた符号化または認証の間に、 依存関係はない。
クライアントかサーバーのいずれかが「TLSでセキュア化されたコネクションが望まれること／必要不可欠であること」を示すために、 HTTP/1.1 [1] (Section 14.42)のUpgradeメカニズムを使うことができる。 このメモは、 "TLS/1.0" Upgradeトークンおよび新しいHTTP状態コード「426 要 Upgrade」を規定する。
3章と4章は、 直接接続されたクライアントとサーバーの操作を記述している。 中間にあるプロキシは、5章で説明しているように、 これらの操作を適用する前に「エンド to エンド」トンネルを確立しなければならない。
本書中のキーワード"MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY"は、RFC 2119 [11] に記述されているように解釈されるべきものである。
クライアントが"TLS/1.0"を含むUpgradeヘッダーフィールドをもつHTTP/1.1リクエストを送るとき、 クライアントは、 サーバーに対してTLS/1.0に切り替え後に現在のHTTP/1.1リクエストを完遂することを要求していることになる。
クライアントは、 セキュア化されていないレスポンスを受け取り可能なとき、 いかなる平文HTTPリクエストにおいても、 セキュア化された動作に切り替えることができる(MAY)。：
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
この場合、サーバーは、通常通りのクリアなHTTP操作に応答するか、 あるいは(OR)、 (次章において詳細に記述してある)セキュア化された操作に切り替えることができる(MAY)。
HTTP/1.1 [1] は、 「UpgradeがHTTP/1.1メッセージ中にあるときは常に、 キーワードupgradeは、 コネクションヘッダーフィールド(section 14.10)内で提供されなければならない(MUST)」と規定していることに注意。
セキュア化されていないレスポンスが許容不能である場合、 クライアントは、まず、 (可能である場合)TLS/1.0への切り替えを関するために、 OPTIONSリクエストを送らなければならない(MUST)。
OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
HTTP/1.1 [1] において仕様とされているように、 サーバーがTLSハンドシェイクを開始する準備ができている場合、 サーバーは、 過渡的な「101 プロトコル切り替え中」(メッセージ)を送らなければならない(MSUT)とともに、 切り替えるプロトコルスタックのトークンを規定するUpgradeレスポンスヘッダーを含めなければならない(MUST)。：
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
「101(プロトコル切り替え)レスポンスのUpgradeヘッダー中に掲載されたプロトコルトークンは、 順位づけられた「ボトムアップ」スタックを規定すること」に注意。
HTTP/1.1 [1] の10.1.2に規定されているように、 「サーバーは、101レスポンスの末尾にある空白行の直後に、 プロトコルをレスポンスのUpgradeヘッダーフィールドによって規定されたものに切り替える」。
一度TLSハンドシェイクが成立すると、そのサーバーは、 当初のリクエストに対するレスポンスで続けなければならない(MUST)。 いかなるTLSハンドシェイク失敗も、 TLSエラー警告仕様の単位でコネクションを切断するようにしなければならない(MUST)。
Upgradeレスポンスのヘッダーフィールドは、 サーバーが受容できる(MAY)プロトコルUpgradeの候補を公示する。 「426(要Upgrade)」状態コードと併せて、サーバーは、 クライアントがリクエストを完了させるために受容しなければならない(MUST)正確なプロトコル Upgrade を公示できる。
HTTP/1.1 [1] において仕様とされているように、 サーバーは、リストされている(組み合わせの)プロトコルに切り替えることを望んでいることを示すために、 101もしくは426以外のレスポンス中にUpgradeヘッダーを含めることができる(MAY)。
サーバーは、 「クライアントリクエストは、 TLSが426状態コード(要Upgrade)を使わずして完了できないこと」を示すことができ(MAY)、 これは、要求される TLS バージョンのトークンを規定するUpgradeヘッダーフィールドを含まなければならない(MUST)。
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
このサーバーは、 426レスポンスにおいて人間が読むことができる形式でエラーの理由を示すメッセージ本文を含め、 ユーザが利用可能である可能性があるあらゆる代替策を記述する必要がある(SHOULD)。
「たとえクライアントがTLSを使うことを望んでいる場合でも、 処理のためには、 3章中の操作を行わなければならないこと」に注意。； TLSハンドシェイクは、426レスポンス直後には開始できない。
段階的なヘッダーであるので、Upgradeは、 HTTPの相手同士の各ペア間において交渉される。 ユーザエージェントがプロキシ宛にUpgradeヘッダーをもつリクエストを送る場合、 ユーザエージェントは、 ユーザエージェントとプロキシの間のプロトコルについての変更を要求しているのであり、 「エンド to エンド」の変更ではない。
特に、TLSは、認証を提供し、 中間者による攻撃を予防するために「エンド to エンド」な接続を要求するので、このメモは、 プロキシを踏み越えてトンネルを確立するためのCONNECTメソッドを規定する。
一度、トンネルが確立したら、 3章中のあらゆる操作がTLSコネクションを確立するために利用可能である。
発信元サーバーがプロキシからUpgradeヘッダーを受け取り、 101(プロトコル切り替え)レスポンスで応答する場合、 プロキシとサーバー自体の間のコネクションのみのプロトコルを切り替えているのである。 同様に、プロキシは、 発信元サーバーと通信するのに使っているプロトコルとは独立して、 そのクライアント宛にそのコネクション上のプロトコルを変更するために101レスポンスを返す可能性がある。
また、これらのシナリオは、426レスポンスの判定を複雑にする。 Upgradeは段階的なヘッダーであるので、 426を処理できないプロキシは、 付随するUpgradeヘッダーを削除してしまい、 クライアントによる要求されたプロトコルへの切り替え判定をを行わせない可能性がある。 クライアントがUpgradeヘッダーを伴わない426状態コードを受け取った場合、 クライアントは、5.2に記述してあるように、 「エンド to エンド」なトンネルコネクションをリクエストする必要があり、 要求されるUpgrade情報を得るために、 そのリクエストを繰り返す必要がある。
この段階的なUpgradeの仕様は、熟考された選択であった。 これによって、プロキシの両側において段階的な採用が可能であり、 カスケード化されたプロキシ間で、 変更に関与しなかったプロキシについての知識無しに、 プロトコルを最適化できる。
CONNECT手法は、 「プロキシが代わりにトンネルコネクションを確立すること」 を要求する。 Request-LineのRequest-URI部分は、 URI Generic Syntax [2] によって規定されているように、常に'authority'である。 すなわち、リクエストされたコネクション宛先のホスト名とポート番号をコロンで区切ったものである。：
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
当然ながら、トンネルが最初に確立されなければならないので、 「エンド to エンド」プロトコルUpgradeリクエスト以外であれば他のHTTPメカニズムが通常はCONNECT手法とともに利用可能である。
例えば、プロキシ認証は、 トンネルを作成するためのオーソリティを確立するために使われる可能性がある。：
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
いかなる他のパイプライン化されたHTTP/1.1リクエストと同様に、 トンネルを通すべきデータを、空白行の直後に送ることができる。 通常の警告も適用される。： 最終的なレスポンスが否定的である場合、データを棄却できる。 また、複数のTCPセグメントが残っている場合、 そのコネクションは、レスポンス無しにリセットできる。
CONNECTリクエストに対するいかなる成功レスポンス(2xx)も、
「プロキシがリクエストされたホストとポートに対するコネクションを確立し、
現在のコネクションをサーバーコネクション宛にトンネルさせるように切り替えたこと」
を示す。
「プロキシ自体がその他のプロキシを通じてのみ要求した発信元サーバーに到達可能である」ような場合がある。 この場合、最初のプロキシは、 その次のプロキシのCONNECTリクエストを行い、 オーソリティ宛のトンネルを要求する必要がある(SHOULD)。 プロキシは、オーソリティ宛の、 直接かトンネルによるいずれかのコネクションが確立されない限り、 いかなる2xx状態コードでも応答してはならない(MUST NOT)。
自ら宛のCONNECTリクエストを受信した発信元サーバーは、 コネクションが確立されたことを示すために2xx状態コードで応答することができる(MAY)。
ピアのいずれか一方がコネクションを切断する場合、 そのピアから来た、あらゆる残っているデータは、他方に転送される。 そして、その後、他のコネクションもプロキシによって終了される。 そのピア宛のデータが未配送で残っている場合、 そのデータは、棄却される。
Upgrade機能の信頼できる相互運用可能な交渉においては、 明解な失敗の表示が要求される。 426(要Upgrade)状態コードによって、 サーバーが一定の資源を提供しなければならないことを示す詳細なプロトコル拡張を明確に表現できるようになる。
一見、 「https:というURIについての古い再指図のやり方に似ていることによって、 レスポンスが何らかの再指図(3xx)の一形態である」 ように見える可能性がある。 Upgrade:を処理できないユーザエージェントは、これを作成する。
「3xxコードは、『要Upgrade』について割り当てられてきた」と想定する。； これを処理できなかったユーザエージェント(クライアント)が、 これを300として扱う。 それから、おそらく、クライアントは、 レスポンス中の"Location"ヘッダーを探し、 そのヘッダーフィールド中のURLに対するリクエストを繰り返すことを試みる。 このユーザエージェントは、 TLS層上に組み込むようUpgradeすることを知らなかったので、 せいぜい、新しいURLでも失敗することであろう。
IANA は、BCP 26 [10] に記述されているように、 2つの名前空間についてのレジストリを作成するものとする。：
HTTP状態コードのレジストリは、 HTTPレスポンスのStatus行にあるStatus-Codeトークンについての名前空間を規定する。 この名前空間についての初期値は、 以下のものによって規定されている。：
この名前空間に追加されるべき値は、 IETFアプリケーションエリアにおけるスタンダードトラック文書の方式で レビューの対象とする必要がある(SHOULD)。 あらゆるこのような文書は、 HTTP/1.1についてのドラフト標準 [1] に対する「廃止(Obsoletes)」か「更新(Updates)」のいずれかの文書ステータスによって、 追跡可能である必要がある(SHOULD)。
HTTP Upgradeトークンのレジストリは、 Upgrade HTTPヘッダーフィールド中のプロトコルを識別するために使われる製品トークンについての名前空間を規定する。 登録された各トークンは、1つもしくは一式の仕様と、および、 連絡先情報と関連づけられる必要がある。
HTTP/1.1 [1] についてのドラフト標準は、 「トークンは『製品』についての成果に従う」と規定する。：
product = token ["/" product-version]
product-version = token
登録は、BCP 26 [10] に記述されているように、 先入先出法に基づいて許可される必要がある。 これらの仕様は、IETF文書であったり、または、 IESGによるレビュー対象とする必要はないが、 下記のルールに従う必要がある。：
この仕様は、プロトコルトークン"TLS/1.0"をTLSプロトコル [6] によって規定されているプロトコルについての識別子として規定する。
「Upgrade トークンを公衆利用可能とするための規定」 は要求されないが、 登録についての連絡先情報は、必要(SHOULD)である。
中間者による(Upgradeヘッダーを削除する)攻撃についての潜在的可能性は、 現状のhttp/httpsが混合した実践にあることと同様に残されている。：
さらに、TLSを明示的に呼び出さないクライアントについて、 サーバーは、 TLS準拠を示すために101もしくは426以外のいかなるレスポンスにおいても、 Upgradeヘッダーを使うことができる。 TLS準拠がサーバーの機能であり手元の資源ではないと見なされる必要があるので、 1回だけ送信し、 クライアントにその事実をキャッシュさせることで十分である。
このメモ中に'https' URIスキームの規定に影響を与える事項は無いが、 このメカニズムを広くハイパーテキストのコンテンツに採用することによって、 セキュアな資源とセキュアでない資源の両方を識別するために、 'http'を使うことができるようになる。
「どのようなセキュリティ特性がコネクション上で要求されているか」についての選択は、 クライアントとサーバーに委ねられる。 これは、 この判定を行う際に両者が利用可能なあらゆる情報を使うことができるようにする。 例えば、ユーザエージェント(クライアント)は、 ユーザパフォーマンス設定や「このLAN以外のすべてのPOST操作にTLSが要求される」というようなネットワークのセキュリティについての情報に依拠できる。 あるいは、サーバーは、「このページのFORMは、 TLSを使って表示・送信されなければならない」というような資源アクセスルールを適用することができる。
一般的なTCPトンネルは、セキュリティリスクにさらされている。 まず、そのような認証は、少数のknown portに限定される必要がある。 ここに規定したUpgrade:メカニズムは、 80番ポートにおける前方トンネリングのみを要求する。 2番目に、 トンネルを通過するデータはプロキシにとっては不透明であるので、 他のwell-knownポート／予約ポートをトンネルさせることには、 追加的なリスクがある。 例えば、25番ポートに接続する想定上のHTTPクライアントは、 SMTP経由でspamを中継する可能性がある。
| [1] |
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, 1999年6月. |
| [2] | Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic Syntax", RFC 2396, 1998年8月. |
| [3] |
Rescorla, E., 「HTTPオーバーTLS (HTTP Over TLS)」", RFC 2818, 2000年5月. |
| [4] |
Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "Web Distributed Authoring and Versioning", RFC 2518, 1999年2月. |
| [5] |
Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections Protocol", 作業中。 |
| [6] |
Dierks, T. and C. Allen, 「TLSプロトコル v1.0 (The TLS Protocol)」, RFC 2246, 1999年1月. |
| [7] |
Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, 1999年4月. |
| [8] |
Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", 作業中。 (Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.) |
| [9] |
Rose, M., 「I-DとRFCをXMLを使って書く(Writing I-Ds and RFCs using XML)」, RFC 2629, 1999年6月. |
| [10] |
Narten, T. and H. Alvestrand, 「RFC中の『IANAについてに考慮事項』の章を書くためのガイドライン(Guidelines for Writing an IANA Considerations Section in RFCs)」, BCP 26, RFC 2434(English), 1998年10月. |
| [11] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
Rohit Khare
4K Associates / UC Irvine
3207 Palo Verde
Irvine, CA 92612
US
電話： +1 626 806 7574
EMail： rohit＠4K-associates.com
URI： http://www.4K-associates.com/
Scott Lawrence
Agranat Systems, Inc.
5 Clocktower Place
Suite 400
Maynard, MA 01754
US
電話： +1 978 461 0888
EMail： lawrence＠agranat.com
URI： http://www.agranat.com/
宮川 寧夫
情報処理振興事業協会
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
URI： http://www.ipa.go.jp/security/
CONNECT手法は、元来、 Netscape Communications社のAri Luotonen氏によって、 "Tunneling TCP basedプロトコルs through Web Proxy Servers" [8] という作業中文書中に記述されていた。 これは、広くHTTPプロキシによって実装されていたが、 いかなるIETFスタンダードトラック文書の部分とされてこなかった。 手法名CONNECTは、確保されたが、 [1]に規定されていない。
ここに提示した規定は、その以前のメモに直接、由来するものであり、 いくつかの編集上の変更と、 他のHTTP仕様において確立されている様式上の慣行への準拠が行われている。
以下の方々にも感謝する。：
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC編集者のための資金は現在、Internet Societyによって提供されています。