この文書は、 R. Khare, S. Lawrence: Upgrading to TLS Within HTTP/1.1 (RFC 2817), May 2000. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 2817 Updates: 2616 Category: Standards Track
R. Khare
4K Associates / UC Irvine
S. Lawrence
Agranat Systems, Inc.
May 2000
この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。 このプロトコルの標準化状態と状況については、"Internet Official Protocol Standards" (STD 1) の最新版を参照していただきたい。 この文書の配布に制限は無い。
Copyright © The Internet Society (2000). All Rights Reserved.
この文書は既存の TCP 接続を通してトランスポート層セキュリティ (TLS: Transport Layer Security) を始めるための HTTP/1.1 における Upgrade メカニズムの使い方を説明する。 これによって安全である、無いに係らず HTTP トラフィックは同じ well known port を共有できる (この場合、443 を用いる https: よりも 80 を用いる http: である)。 またこれは "バーチャルホスティング" を可能にするので、単一の HTTP + TLS サーバは単一の IP アドレスにて複数のホスト名を意図したトラフィックを明確にする事ができる。
HTTP/1.1 [1] は、Upgrade をホップバイホップメカニズムとして定義しているので、この文書ではまた、HTTP プロキシを通るエンドトゥエンドなトンネルを確立するための、HTTP CONNECT メソッドを記述する。 最後に、この文書は、公的な HTTP ステータスコードのための、及び公的・私的な Upgrade 製品トークンのための IANA レジストリを設立する。
この文書は、'https' URI スキームの現在の定義には影響しないし、既に 'http' とは別の名前空間を定義している (http://example.org/ と https://example.org/ は同等ではない)。
SSL3 [3] 上に HTTP を展開させるという歴史的慣習は、独特な URI スキームと TCP ポート番号によって単独の HTTP からの結合を区別した。 'http' というスキームはポート 80 上の単独の HTTP プロトコルを意味し、'https' は ポート 443 上の SSL を通じた HTTP プロトコルを意味した。 相対する{parallel} ウェルノウンポート番号は同様に必要とされ、またいくつかの場合では安全である、あるいは安全でない他のアプリケーションプロトコル (例えば snews や ftps) の使用を区別できる。 このアプローチは利用可能なウェルノウンポートの数を効果的に半減する。
1997 年 12 月のワシントン DC での IETF ミーティングにおいて、Applications Area Directors と IESG は相対する{parallel} "secure" ポート番号を発行する慣習には反対を唱えるべきであるという事を再び断言した。 HTTP/1.1 Upgrade メカニズムは開かれた HTTP 接続にトランスポート層セキュリティ [6] を当てる事ができる。
それからおよそ二年の間、この提案の背景にある概念は広く受け入れられているが、一般的な Web ブラウジングのためのポート 443 に代わる実装についてはほとんど関心が持たれていない。 実際、この文書の中には https: URI の現在の解釈に影響を与えるものはない。 しかし、HTTP 上に構築される新しいアプリケーションプロトコル、例えば Internet Printing Protocol [7] 等では、IETF 標準規格へと昇華させるためにまさにそのようなメカニズムが必要とされている。
また Upgrade メカニズムは "バーチャルホスティング" 問題を解決する。 意図された Web サービス処理のあいまいさを無くすために、HTTP/1.1 サーバは複数の IP アドレスを単一のホストに割り当てるよりも、Host: ヘッダを使うであろう。 HTTP/1.1 の使用がより一般に広まるにつれて、ますます ISP が名前に基づいたバーチャルホストを提供していき、その結果 IP アドレス空間の枯渇を遅らせる。
TLS (や SSL) は HTTP の初期のバージョンと同じ制限を受けている: すなわち、最初のハンドシェイクは意図されたホスト名を規定せずに、IP アドレスにのみ依存している。 平文の HTTP/1.1 Upgrade: 前文{preamble} を TLS ハンドシェイクへ使う -- 最初の Host: ヘッダに基づいて証明書を選択する -- 事によって、ISP はセキュアな名前に基づいたバーチャルホストを提供することができるであろう。
SSL (Secure Sockets Layer) としても知られる TLS は、選択によっては強力な相互認証を含んだ、様々な暗号システムを使用して、プライベートなエンドトゥエンドコネクションを確立する。 最初に、ハンドシェイクフェーズは、レコード層の確立、端点の認証、パラメータの設定、エラーの報告のために三つのサブプロトコルを使う。 その後、接続の残りのための暗号化、圧縮およびリアセンブリを扱う進行中の階層状のレコードプロトコルがある。 後者は、完全に透過であるという事を意図している。 例えば、TLS のレコードマーカーや証明書と HTTP/1.1 のチャンク形式エンコーディングや認証の間に依存関係はない。
クライアントやサーバは、TLS のセキュアな接続を求める、あるいは必要であるという事を示すために HTTP/1.1 [1] Upgrade メカニズム (section 14.42) を使用する事ができる。 この文書では、"TLS/1.0" Upgrade トークンと、新しい HTTP ステータスコード "426 Upgrade Required" を定義する。
section 3 と 4 は、直接接続されたクライアントとサーバの操作を記述する。 中間プロクシは、section 5 にて説明されるように、これらの操作を適用する前にエンドトゥエンドなトンネルを確立しなければならない。
この文書中に表れる "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 リクエストの間にセキュアな操作へ切り替えを提案できる。
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
この場合、サーバは平文の HTTP 操作にて応答する事もできるし、あるいは (次の節で説明されるように) セキュアな操作に切り替える事もできる。
HTTP/1.1 [1] では、"Upgrade が HTTP/1.1 メッセージに存在する時は常に、upgrade というキーワードを Connection ヘッダフィールド (section 14.10) の中に与えなければならない" とされている事に注意せよ。
セキュアでないレスポンスが受け入れられない場合、クライアントは初めに (可能であれば) TLS/1.0 へと切り替えを完了するために OPTIONS リクエストを送らなければならない。
OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
HTTP/1.1 [1] にて規定されるように、サーバは TLS ハンドシェイクを開始しようとする場合、中間段階の "101 Switching Protocol" と、そこに切り替えようとするプロトコルスタックのトークンを規定している Upgrade レスポンスヘッダを含まなければならない:
HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
101 Switching Protocols レスポンスの Upgrade ヘッダ中に列挙されるプロトコルトークンは順に '下から上へ向かう{bottom-up}' スタックを指定するという事に注意せよ。
HTTP/1.1 [1], Section 10.1.2 にて規定されるように: "サーバは 101 レスポンスを終了する空行のあと、直ちにレスポンスの Upgrade ヘッダフィールドによって定義されたプロトコルに変更するだろう"
一度 TLS ハンドシェイクが完全に成功したら、サーバは元々のリクエストへのレスポンスを続けなければならない。 TLS ハンドシェイクが失敗したら、TLS エラーアラート仕様毎に、接続を切断しなければならない。
Upgrade レスポンスヘッダフィールドは、サーバが受け入れる事ができるプロトコルアップグレードを告知する。 "426 Upgrade Required" ステータスコードと同時に、サーバはクライアントがリクエストを完了するために受け入れなければならない正確なプロトコルアップグレードを告知する事ができる。
HTTP/1.1 [1] にて規定されるように、サーバは列挙されるプロトコルのいずれか (あるいはその組み合わせ) に切り替えようとする事を示すために 101 や 426 以外のあらゆるレスポンス中に Upgrade ヘッダを含む事ができる。
サーバは、 "426 Upgrade Required" ステータスコードを使用して、クライアントのリクエストは TLS なしでは完了できないという事を示す事ができ、これには要求される TLS バージョンのトークンを規定している Upgrade ヘッダフィールドを含まなければならない。
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
サーバは、426 レスポンス中に、人間が読める形式でエラーの理由を示し、ユーザが利用可能であるようなあらゆる代替方法を記述したメッセージボディを含むべきである。
たとえクライアントが TLS を使用する事を望んでいる場合でも、処理を行うためには section 3 中の操作を使用しなければならないという事に注意せよ; すなわち、TLS ハンドシェイクは 426 レスポンス後、直ちに開始する事はできない。
ホップバイホップヘッダのように、Upgrade は HTTP 通信をするそれぞれの間で交渉がなされる。 ユーザエージェントがプロクシに Upgrade ヘッダを含むリクエストを送った場合、自身とプロクシの間のプロトコルを変更するようにリクエストするものであり、エンドトゥエンドな変更ではない。
特に、TLS は認証を供給し中継者による攻撃{man-in-the-middle attacks} を避けるためにエンドトゥエンドな接続能力を必要とするので、この文書はプロクシ上にトンネルを確立するために CONNECT メソッドを規定する。
一度トンネルが確立されたら、Section 3 中のあらゆる操作は TLS 接続を確立するために使用する事ができる。
オリジンサーバがプロクシから Upgade ヘッダを受信し、101 Switching Protocols レスポンスをもって応答する場合、プロクシとサーバ自身の間の接続上でのみプロトコルを変更している。 同様に、プロクシは、オリジンサーバに向けて通信するために使用しているプロトコルとは独立してその接続上のプロトコルを変更するためにそのクライアントに 101 レスポンスを返すであろう。
またこれらのシナリオは、426 レスポンスの判断を複雑にする。 Upgrade はホップバイホップヘッダなので、426 を認識しないプロクシは含まれている Upgrade ヘッダを削除し、クライアントが必要なプロトコルの切り替えを決定する事を妨げるかもしれない。 クライアントは、含まれるべき Upgrade ヘッダのない 426 ステータスを受信した場合、 Section 5.2 に記述されるようなエンドトゥエンドなトンネル接続を要求し、必要な upgrade 情報を得るためにリクエストを繰り返す必要があるだろう。
Upgrade のホップバイホップ定義は、熟考上での選択であった。 それは、両端プロクシの一方の漸次的展開や、その変更に含まれない一員{party} の知識なしに連結されたプロクシのプロトコルの最適化を可能にする。
CONNECT メソッドは、プロクシにトンネル接続の確立を要求する。 リクエストラインの Request-URI の部分は、常に URI 一般構文 [2] によって定義されるような 'authority' であり、リクエストされるコネクションの目的地となるホスト名とポート番号とをコロンで区切ったものである。
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80
もちろん CONNECT と共に他の HTTP メカニズムも使用する事ができるが、エンドトゥエンドでのプロトコル Upgrade リクエストは除かれる。 何故なら、トンネルは最初に確立されなければならないからである。
例えば、プロクシ認証はトンネルを作成する authority を確立するために使用されるかもしれない:
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ=
他のあらゆるパイプラインされる HTTP/1.1 リクエストのように、トンネルされるデータは空行の後、直ちに送られるであろう。 通常の警告は更に次のものを適用する: 最終的なレスポンスが否定的である場合、データは破棄されるかもしれない。 複数の TCP セグメントが確立していない{outstanding} 場合、その接続はレスポンスなしでリセットされるかもしれない。
CONNECT リクエストに対する成功 (2xx) レスポンスは、プロクシがリクエストされたホストとポートに接続を確立したという事、及び現在の接続をサーバへの接続をトンネリングするものへ切り換えたという事を示す。
そのプロクシからリクエストされるオリジンサーバへ到達するには、他のプロクシを経なければならない場合もあるかもしれない。 この場合、最初のプロクシは、その authority へトンネルを要求するために、その次のプロクシへ CONNECT リクエストを送信すべきである。 プロキシは、その authority への直接、あるいはトンネルでの接続が確立しない限り、いかなる 2xx ステータスコードも返してはならない。
自身に向けられた CONNECT リクエストを受信したオリジンサーバは、接続が確立した事を示すために 2xx ステータスコードを返す事ができる。
任意の時点でピアの一方が切断された場合、そのピアからやってきた未送信データは全てもう一方へと渡され、その後他の接続もプロクシによって終了するであろう。 そのピアに到達していない未送信データがある場合、そのデータは破棄されるであろう。
Upgrade 特性の信頼でき、相互運用できるネゴシエーションでは、一義的な失敗信号を必要とする。 426 Upgrade Required ステータスコードによって、サーバは与えられたリソースが従わなければならない正確なプロトコル拡張を決定的に提示する事ができる。
それは初めは、https: URI への古い様式のリダイレクションとの類似性によって、このレスポンスがある種のリダイレクション (3xxコード) 形式であるべきであったように見えるかもしれない。 Upgrade: を理解しないユーザエージェントはこれを排除する。
3xx コードが "Upgrade Required" のために割り当てられたと仮定する; それを認識しなかったユーザエージェントは、それを 300 のように扱うであろう。 その後、それは適切にレスポンス中の "Location" ヘッダを捜し、そのヘッダフィールド中の URL にてリクエストを繰り返そうとするであろう。 TLS 層を組み込むための Upgrade を知らなかったので、新たな URL で再び失敗するのがせいぜいであろう。
IANA は、BCP 26 [10] にて示されるように、2 つの名前空間についてのレジストリを作成するものとする:
HTTP ステータスコードレジストリは、HTTP レスポンスのステータスラインにおける Status-Code トークンのための名前空間を定義する。 この名前空間のための初期値は、以下によって規定される:
この名前空間に追加される値は、IETF Applications Area 内で standards track 文書の形式で検討されるべきである。 そのようなドキュメントは全て、HTTP/1.1 [1] についてのドラフトスタンダードの '廃案{Obsoletes}' あるいは '更新{Updates}' のステータスを通じて追跡できるべきである。
HTTP Upgrade トークンレジストリは、Upgrade HTTP ヘッダフィールドにおいてプロトコルを識別するために使用される product トークンのための名前空間を定義する。 登録された各トークンには、一つ以上の仕様書と、連絡先情報が組み合わされるべきである。
HTTP/1.1 [1] についてのドラフトスタンダードは、これらのトークンは 'product' を作り出す規則に従うという事を規定する:
product = token ["/" product-version] product-version = token
登録は、BCP 26 [10] にて示されるように早い者勝ちという原理にて認められるべきである。 これらの仕様は IETF のドキュメントとなったり、IESG の検討を受ける必要はないが、以下の規則に従うべきである:
この仕様書では、TLSプロトコル [6] によって規定されるプロトコルのための識別子としてプロトコルトークン "TLS/1.0" を定義する。
upgrade トークンのための仕様は公的に利用可能である必要はないが、登録についての連絡先情報は公的に利用可能であるべきである。
(Upgrade ヘッダを削除する事による) 中継者による攻撃{man-in-the-middle attacks} の可能性は、http/https が混合して実行されている現在と、依然として同じままである:
その上、明示的に TLS を実施しようとしないクライアントのために、サーバは TLS 従順性を告示するために 101 や 426 以外のあらゆるレスポンスにおいて Upgrade ヘッダを使用する事ができる。 TLS 従順性はサーバの特徴であり、サーバの持つリソースの特徴ではないと考えられるべきであるので、それを一度送信すれば十分であるし、それを一度送り、クライアントにその事実をキャッシュさせれば十分であろう。
この文書中のいずれも 'https' URI スキームの定義に影響しないが、HyperText 内容のためにこのメカニズムを広範囲に採用する事で、セキュアであるリソースとそうでないリソースを識別するために 'http' を使用する事ができる。
接続上でどんなセキュリティ特性が必要とされるかについての選択は、クライアントとサーバに任される。 これによって、どちらかがこの決定を行う事において利用可能なあらゆる情報の使用が可能になる。 例えば、ユーザエージェントはユーザ優先度のセッティングや 'TLS は私のローカルネット上ではない全ての POST 操作において必要とする' といったようなネットワークのセキュリティについて情報に頼る事ができるし、サーバは 'このページの FORM は TLS を使用して供給され、また提出されなければならない' といったようなリソースアクセス規則を適用する事ができる。
一般的な TCP トンネルはセキュリティリスクに満ちている。 初めに、そのような認証は少数の既知のポートへ制限されるべきである。 ここに定義される Upgrade: メカニズムは、ポート 80 において前方トンネリングのみを要求する。 次に、トンネルされるデータはプロクシにとって見えないものなので、他のウェルノウンポートあるいは予約されるポートへのトンネリングには更なるリスクがある。 例えば、ポート 25 へ CONNECT する HTTP クライアントとみなされるものは、SMTP 経由でスパムを中継する事ができるであろう。
Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US Phone: +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 Phone: +1 978 461 0888 EMail: lawrence@agranat.com URI: http://www.agranat.com/
CONNECT メソッドは元々、Netscape Communications 社の Ari Luotonen によって "Tunneling TCP based protocols through Web proxy servers" [8] と題される、進行中の研究において記述されたものである。 これは HTTP プロキシによって広く実装されたが、IETF Standards Track 文書のどの部分にも取り入れられなかった。 メソッド名 CONNECT は、[1] において予約はされたが、定義はされなかった。
ここで与えられた定義は、初期の文書から直接得られるものに、編集段階において、他の HTTP 仕様において現在までに確立している文体上の修正や慣例をいくつか盛り込んでいる。
更に以下の方々にも感謝する:
Copyright © The Internet Society (2000). All Rights Reserved.
この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。