この文書は、 E. Rescorla: HTTP Over TLS (RFC 2818), May 2000. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 2818 Category: Informational
E. Rescorla
RTFM, Inc.
May 2000
この文書はインターネットコミュニティのための情報を提供する物である。 この文書はいかなる種のインターネットの標準も明述する物ではない。 この文書の配布に制限は無い。
Copyright © The Internet Society (2000). All Rights Reserved.
この文書は、インターネット上の HTTP 接続をセキュアにするための TLS の使用法を記述する。 現在の慣例では、(TLS の前身の) SSL 上に HTTP を展開し、セキュアな通信を異なるサーバポート番号の使用によってセキュアでないものと区別している。 この文書は、TLS を使用したこの用法を記述する。 もう一方のドキュメントでは、通常の HTTP と同じポートを通じて HTTP/TLS を使用するための方法を示す [RFC2817]。
HTTP [RFC2616] は元々インターネット上で平文で使用されてきた。 しかし、機密事項を扱うアプリケーションによる HTTP の使用が増えてきた事によって、セキュリティ対策が必要となってきた。 SSL、そしてその後継の TLS [RFC2246] は、チャネル指向のセキュリティを提供するために設計された。 この文書は、TLS 上で HTTP を使用する方法を記述する。
この文書に表れる "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" 各キーワードは、[RFC2119] にて記述されるように解釈されるべきである。
概念的に、HTTP/TLS は非常に単純である。 TCP 上の HTTP を使用するのとまさに同じように、TLS 上の HTTP を使用せよ。
HTTP クライアントの役割をしているエージェントは、TLS クライアントの役割もするべきである。 それは、サーバの適切なポート上への接続を開始し、TLS ハンドシェイクを始めるために TLS ClientHello を送るべきである。 TLS ハンドシェイクが完了した時、クライアントは最初の HTTP リクエストを開始する事ができる。 全ての HTTP データは、TLS の "アプリケーションデータ" として送られなければならない。 接続の保持を含む、通常の HTTP の振る舞いは、その後に行われるべきである。
TLS は、セキュアな接続の終了についての機能を提供する。 妥当な終了アラートが受信された時、実装{implementation} は更なるデータがその接続では受信されないとする事ができる。 TLS を実装するものは、接続を閉じる前に終了アラートの交換を開始しなければならない。 TLS を実装するものは、終了アラート送った後で、そのピアが自身の終了アラートを送る事を待たずに接続を閉じるという、"不完全な終了" を行ってもよい。 これを行う実装は、そのセッションを再利用する事を選択できるという事に注意せよ。 これは、アプリケーションが重要なメッセージデータを全て受信したという事を (通常は HTTP メッセージ境界の検知によって) 知った時にのみ行われるべきである。
[RFC2246] にて規定されるように、初めに妥当な終了アラートを受信する事なく接続の終了を受信した ("早期異常終了{premature close} の") 全ての実装は、そのセッションを再利用しなければならない。 早期異常終了は、既に受信されたデータのセキュリティに疑問を呼ぶ事はないが、単に以降のデータが切断されたであろうという事に注意せよ。 TLS は HTTPリクエスト/レスポンス境界を気付かないので、メッセージの内部、あるいはメッセージ間に切断が生じたかどうかを決定するために HTTP データ自体 (特に Content-Length ヘッダ) を探査する必要がある。
HTTP はサーバデータの終端を知らせるために接続の終了を使用するので、 クライアント実装は、あらゆる早期異常終了をエラーとして、また受信されるデータを切断された可能性があるものとして、それぞれ扱わなければれならない。 HTTP プロトコルによって切断が起こったかどうかをクライアントが見つけ出す事が可能であった場合、それが完全な応答を受信した場合、"送信時には厳格であり、受信時には寛大であれ" という原則 [RFC1958] に従い、そのようなエラーに寛容であってもよいが、多くの場合では切断は HTTP プロトコルデータ中には示されない; 特に、以下の二つの場合は特別な注意を払うべきである:
Content-Length ヘッダのない HTTP レスポンス。 この場合のデータ長は接続の終了によって知らされるので、サーバによって生成される早期異常終了は、攻撃者によって生成される偽の close と区別できない。
全てのデータが読まれる前に終了された、妥当な Content-Length ヘッダを持つ HTTP レスポンス。 TLS は文書指向の保護を提供しないので、サーバが Content-Length を誤って計算したか、それとも攻撃者が接続を切断したかを決定する事は不可能である。
上記の規則には一つ例外がある。 早期異常終了に遭遇した場合、クライアントは Content-Length ヘッダにて規定されている量と同じデータを受信したようなリクエストを完全なものとして扱うべきである。
不完全な終了を検知したクライアントは、上品に回復すべきである。 クライアントは、この方法にて終了した TLS セッションを再開する事ができる。
クライアントは、その接続を切断する前に終了アラートを送らなければならない。 それ以上のデータを受信する準備のないクライアントは、サーバの終了アラートを待たずに、単に接続を終了し、それによって、サーバ側で不完全な終了を生成される。
RFC 2616 では、HTTP クライアントがいつでも接続を終了する事を許しており、またサーバに上品に状態を戻すように要求する。 特に、クライアントは多くの場合サーバデータの終末がいつかを決定する事ができるので、サーバはクライアントからの不完全な終了を受信する準備をすべきである。 サーバは、この方法にて終了した TLS セッションを再開しようとすべきである。
実装上の注意: 持続的接続を使用しない HTTP 実装において、サーバは通常、接続を終了する事によってデータの終了を知らせる事ができるであろう。 しかし、Content-Length が使用される時、クライアントは既に終了アラートを送っているかもしれないし、接続を落としているかもしれない。
サーバは、接続を終了する前に、クライアントとの終了アラートの交換を始めようとしなければならない。 サーバは、終了アラートを送った後に接続を終了する事ができ、その場合クライアント側で不完全な終了を生成する事になる。
HTTP サーバがクライアントから受信するであろう最初のデータは、Request-Line というものである。 TLS サーバ (すなわち HTTP/TLS サーバ) が受信するであろう最初のデータは、ClientHello である。 それ故に、どちらのプロトコルが使用されているかを区別するためには別々のポート上で HTTP/TLS を実行させるのが一般的な方法であった。 HTTP/TLS が TCP/IP 接続上で実行されている時の既定ポートは 443 である。 これは、HTTP/TLS が別の転送上で実行される事を妨げるものではない。 TLS は信頼できる接続指向のデータストリームを仮定しているというだけである。
HTTP/TLS は、'http' プロトコル識別子の代わりに 'https' プロトコル識別子を使用する事によって HTTP URI を区別する。 HTTP/TLS を規定する URI の例は以下のようなものである。:
https://www.example.com/~smith/home.html
一般に、HTTP/TLS リクエストは URI を参照する事によって生成される。 その結果、そのサーバのためのホスト名はクライアントに知られる。 ホスト名が利用可能な場合、中継者による攻撃{man-in-the-middle attacks} を防ぐために、クライアントはサーバの識別子に対してサーバの Certificate メッセージの中で提示されるものとを照合しなければならない。
クライアントがサーバが期待される識別子に関して外部情報を持っている場合、ホスト名照合は省略する事ができる。 (例えば、クライアントはそのアドレスやホスト名が動的なマシンに接続しているかもしれないが、クライアントはサーバが提示する証明書を知っている。) そのような場合、中継者による攻撃を防ぐためにできるだけ受け取り可能な証明書の範囲を狭くする事は重要である。 特別な場合では、クライアントは単にサーバの識別子を無視する事が適切であるかもしれないが、 それが積極的な攻撃に対して接続を開放しっ放しにしておくという事は理解されなければならない。
dNSName 型の subjectAltName 拡張がある場合、それは識別子として使用されなければならない。 そうでない場合は、 証明書の Subject フィールド内の (最も特定できる) Common Name フィールドが使用されなければならない。 Common Name の使用が現在の慣例であるが、これは推奨されず、代わりに Certification Authorities は dNSName を使用する事が推奨される。
照合には、[RFC2459] によって規定される照合規則を使用して行う。 証明書内に与えられた型に複数の識別子がある場合、 (例えば、複数の dNSName 名がある、あるいはそのセットのうちの任意の一つが適合すれば、受け入れ可能であると考えられる。) Name は、任意の単一ドメイン名の構成要素あるいはその断片に適合すると考える事ができるワイルドカード文字 * を含む事ができる。 例えば、*.a.com は、foo.a.com に一致するが bar.foo.a.com とは一致しない。 f*.com は、foo.com に一致するが bar.com とは一致しない。
ある場合には、URI がホスト名ではなく IP アドレスにて指定される。 この場合、iPAddress 型の subjectAltName が証明書内になければならないし、URI 中で IP に正確に一致しなければならない。
ホスト名が証明書内の識別子と適合しない場合、ユーザ指向のクライアントは、ユーザに知らせる (クライアントはユーザにどんな場合もその接続を続ける機会を与える事ができる) か、bad certificate エラーをもって接続を終了しなければならない。 自動化されたクライアントは、(利用可能であれば) 適切な監査ログにエラーを記録しなければならないし、(bad certificate エラーをもって) 接続を終了すべきである。 自動化されたクライアントは、この照合を不能にするような設定を提供する事ができるが、それを可能にする設定は提供しなければならない。
多くの場合、URI 自身は信頼されていない情報源{source} から来るという事に注意せよ。 上記の照合は、この情報源が危険に晒される場合、攻撃に対する保護を提供しない。 例えば、もしその URI がそれ自体が HTTP/TLS を使用せずに得られた HTML ページをクリックする事によって得られた場合、中継者は URI を置き換える事ができるであろう。 この攻撃形態を防ぐために、ユーザは、それが彼らの期待に沿うかどうかを決定するためにサーバによって提示された証明書を注意深く探査すべきである。
一般には、サーバは、クライアントの識別子であるべきものについての外部知識を持っていないので、(クライアントが適切な CA 内に証明書鎖を持つという事以外の) 照合は不可能である。 サーバが (一般には外部のいくつかの情報源から HTTP や TLS へ) そのような知識を持っている場合、それは上記のように識別子を照合すべきである。
この文書全体がセキュリティに関するものである。
Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303 Phone: (650) 328-8631 EMail: ekr@rtfm.com
Copyright © The Internet Society (2000). All Rights Reserved.
この文書とその翻訳は、複製し他人に配布することができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含むことによって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布することができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文書自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体へのリファレンスを削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。