ネットワークワーキンググループ
Request for Comments: 2818
分類: 情報提供

E. Rescorla
RTFM, Inc.
2000年 5月

English

HTTP オーバー TLS
(HTTP Over TLS)

このメモの位置付け

このメモは、インターネットコミュニティに情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布には制限はありません。

著作権表記

Copyright (C) The Internet Society (2000).  All Rights Reserved.

要旨

このメモは、「インターネット越しの HTTP コネクションをセキュアにするための TLS の使い方」を記述します。現在の実践は、HTTP オーバー SSL(TLS の前身)とし、異なるサーバーポートの利用によって、セキュアにされたトラフィックをセキュアでないトラフィックと区別するものです。本書は、その実践を TLS を使って文書化します。併読文書は、通常の HTTP と同一のポート上で HTTP/TLS を使うための手法を記述しています。[RFC2817]

目次

1. はじめに

1.1. 要件についての用語法

2. HTTP オーバー TLS

2.1. コネクション開始
2.2. コネクション終了
2.2.1. クライアントの処理
2.2.2. サーバーの処理
2.3. ポート番号
2.4. URI フォーマット

3. 終点の識別

3.1. サーバーの身元
3.2. クライアントの身元

参考文献

セキュリティについての考慮事項

著者のアドレス

著作権表記全文

 

1.  はじめに English

HTTP [RFC2616] は、当初、インターネット上を平文で使われていました。しかし、HTTP の取扱に注意を要するアプリケーション用の利用の増加により、セキュリティ手段が要求されるようになりました。SSL および、その後継である TLS [RFC2246] は、チャネルセキュリティ(経路のセキュリティ)提供するために設計されました。本書は、HTTP オーバー TLS の使い方を記述します。

1.1.  要件についての用語法 English

本書中のキーワード: "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" は、[RFC2119] に記述されているように解釈されるべきものです。

 

2.  HTTP オーバー TLS English

概念的には、HTTP/TLS は、非常に単純です。単に、まさに HTTP を TCP 上で使うように HTTP オーバー TLS を使います。

2.1.  コネクション開始 English

HTTP クライアントとして働くエージェントは、TLS クライアントとしても働く必要があります。これは、サーバーに対するコネクションを適切なポート上で開始し、TLS ハンドシェイクを開始するために TLS ClientHello を送る必要があります。TLS ハンドシェイクが完了したとき、そのクライアントは、最初の HTTP リクエストを開始できます。すべての HTTP データは、TLS の「アプリケーションデータ」として送られなければなりません(MUST)。通信の維持を含む通常のHTTP動作は、この後に従う必要があります。

2.2.  コネクション終了 English

TLS は、セキュアなコネクション終了のための機能を提供します。有効な終了アラートが受信されたとき、実装は、「そのコネクション 上で、これ以上のデータは受信されない」と想定することができます。TLS 実装は、コネクションを終了させる前に、終了アラートの交換を開始しなければなりません(MUST)。 TLS 実装は、 終了アラートを送った後、相手がその終了アラートを送信するのを待たずに、「不完全な終了」を発生させることにより、コネクションを終了できます(MAY)。 「これを行う実装は、そのセッションを再利用できる(MAY)こと」に注意してください。これは、アプリケーションが、(典型的には、HTTP メッセージの境界を検出することを通じて)「関心あるすべてのメッセージデータを受信したこと」を知っているときにのみに行われるようにする必要があります(SHOULD)

[RFC2246] において仕様とされているように、まず、有効な終了アラート受信すること無しに(「時期尚早な終了」) コネクション終了を受信する いかなる実装も、そのセッションを再利用してはなりません(MUST NOT)。「時期尚早な終了は、既に受信したデータのセキュリティ問題とならないが、以降のデータが切れている可能性があること」を端的に示していることに注意してください。TLS は、HTTP リクエスト/レスポンスの境界を認識しないので、「メッセージ中もしくはメッセージ間で切断が発生したか否か」を判定するために、HTTP データ自体(特に、Content-Length ヘッダー)を検証することが必要不可欠です。

2.2.1.  クライアントの処理 English

HTTPでは、コネクションの終了をもってサーバーデータの終端を示すので、クライアント実装は、いかなる時期尚早な終了をもエラーとして扱い、受信したデータを切れている可能性があるものとして扱わなければならなりません(MUST)。 クライアントは、切断が発生したかどうかをHTTPによって発見する場合もあるので、完全なレスポンスを受信した場合、「送信時には厳格、受信時には寛容(であるようにする)」 [RFC1958] とする原則に従って、そのようなエラーを許容することができます。しばしば、切断は、HTTP プロトコルデータ中には表れないことがあります。; 特に 2 つの場合、注意に値します。:

Content-Length ヘッダー無しの HTTP レスポンス。この状況におけるデータ長は、コネクション終了によって示されるので、サーバーによる時期尚早の終了は、攻撃者によって生成された偽の終了と区別することができません。

有効な Content-Length ヘッダーをもった HTTP レスポンスが、すべてのデータが読まれる前に終了した場合。TLS は、文書指向の防護を提供しないので、「サーバーが Content-Length の計算を誤ったのか、あるいは、攻撃者がコネクションを切断したのか」を判定することは不可能です。

上記のルールについて、例外が 1つあります。時期尚早な終了に直面したとき、クライアントは、Content-Length ヘッダーに示されたのと同量のデータを受信したという、すべてのリクエストを完了したものとして扱う必要があります(SHOULD)

不完全な終了を検知したクライアント は、粛々と復旧する必要があります(SHOULD)。クライアントは、このように終了された TLS セッションを保持することができます(MAY)

クライアントは、コネクションを終了する前に、終了アラートを送らなければなりません(MUST)。以降のデータを受信する準備ができていないクライアントは、 サーバーの終了アラートを待たないことを選択し、単にコネクションを終了することができます(MAY)。これによって、サーバー側に不完全な終了が発生します。

2.2.2.  サーバーの処理 English

RFC 2616 は、HTTP クライアントにいつでもコネクションを終了することを許容し、サーバーに粛々と回復することを要求します。 特に、サーバーは、クライアントから不完全な終了を受信するための準備が必要です(SHOULD)。なぜなら、しばしば、クライアントは、「サーバーデータの終了時」を決定できるからです。 サーバーは、このように終了された TLS セッションを再開できる必要があります(SHOULD)

実装上の注意: 継続的コネクションを使わない HTTP 実装において、サーバーは、通常、コネクションを終了することによって、データの終端を示すことができることを期待します。しかし、Content-Length が使われているとき、クライアントは、既に終了アラートを送信してコネクションを棄却している可能性があります。

サーバーは、コネクションを終了する前に、クライアントとの終了アラートの交換を開始することを試みなければなりません(MUST)。サーバーは、終了アラートを送った後、コネクションを終了することができ(MAY)、それゆえ、クライアント側に不完全な終了を発生させます。

2.3.  ポート番号 English

HTTP サーバーがクライアントから受信することを待っている最初のデータは、Request-Line です。TLS サーバー(すなわち HTTP/TLS サーバー)が受信することを待っている最初のデータは、ClientHello です。したがって、普及している実践は、どちらのプロトコルが使われているかを区別するために、HTTP/TLS を別個のポート上で動作させることです。HTTP/TLS が TCP/IP コネクション上で動作しているとき、デフォルトポート番号は、443 番です。これは、HTTP/TLS がその他のトランスポート上で動作することを禁止するものではありません。TLS は、信頼可能なコネクション指向のデータストリームを想定しているにとどまります。

2.4.  URI フォーマット English

HTTP/TLS は、'http' プロトコル識別子の代わりに 'https' プロトコル識別子を使うことによって、HTTP URI と区別されます。以下のものが HTTP/TLS を指定する URI の一例です。:

https://www.example.com/~smith/home.html

 

3.  終点の識別 English

3.1.  サーバーの身元 English

一般に、HTTP/TLS リクエストは、URI を参照することによって生成されます。その結果、サーバーについてのホスト名がクライアントに知られることになります。ホスト名が利用可能な場合、中間者による攻撃を予防するために、クライアントは、これをサーバーの証明書メッセージ中に示されたサーバーの身元に照らしてチェックしなければなりません(MUST)

クライアントが期待されるサーバーの身元に関して外部情報をもつ場合、ホスト名チェックは省略できます(MAY)。(例えば、 サーバーのアドレスとホスト名が動的でも、サーバーが提示する証明書をクライアントが知っている場合は、クライアントはこのサーバーに接続できます。)このような場合、中間者による攻撃を予防するために、可能な限り許容可能な証明書の範囲を狭めることが重要です。特別な事例において、クライアントが単にサーバーの身元を無視することが適切である可能性がありますが、「このことは、コネクションを積極的な攻撃に対して無防備なままにすること」が理解されなければなりません。

dNSName 型の subjectAltName 拡張 がある場合、それは、身元として使われなければなりません(MUST)。それ以外の場合は、証明書の Subject フィールドにある(最も具体的)な Common Name フィールドを使用しなければなりません(MUST)。 Common Name の利用が既存の実践ですが、これは不当であり、代わりに認証機関には、dNSName を使うことが強く薦められます。

マッチングは、[RFC2459] によって仕様とされているマッチングルールを使って行われます。 証明書内に特定のタイプの身元が複数存在する場合(dNSName 名が複数ある場合や、セット内の1つでも合致すれば許可される場合など)、Name は、任意の単一ドメイイン名コンポーネントまたはコンポーネントフラグメントに合致するとみなされるワイルドカード記号 * を含むことができます。(例: *.a.com は、matches foo.a.com に合致しますが bar.foo.a.com には合致しません。f*.com は、foo.com に合致しますが、bar.com には合致しません。)

場合によっては、URI は、ホスト名ではなく、IP アドレスとして指定されることがあります。この場合、iPAddress subjectAltName は、証明書中になければならず、URI 中の IP アドレスと正確に一致しなければなりません。

ホスト名が証明書中の身元と一致しない場合、ユーザ指向のクライアントは(いかなる場合でも、そのコネクションで続行する機会をユーザに提供できます(MAY)が)、 ユーザに通知するか、コネクションを「不良証明書エラー」で切断するか、のいずれかをしなければなりません(MUST)。自動化されたクライアントは、適切な監査ログが利用可能である場合、それにそのエラー記録しなければならず(MUST)、そのコネクション を(不良証明書エラーで)切断する必要があります(SHOULD)。自動化されたクライアントは、このチェックを無効にする設定を提供することができます(MAY)が、これを有効にする設定を提供しなければなりません(MUST)

「多くの場合、URI 自体が信頼できない源泉から来ること」 を銘記してください。上述のチェックは、この源泉が侵されている場合、攻撃に対する防護を提供しません。例えば、HTTP/TLS を使わずに得た HTML ページ上をクリックすることによって URI が得られた場合、中間者が既に URI を置き換えていた可能性があります。この種の攻撃を予防するために、ユーザは、期待に適合するかを判断するために、サーバーによって提供された証明書を注意深く確認する必要があります。

3.2.  クライアントの身元 English

典型的には、サーバーは、(クライアントが適切な CA につながる証明書チェーンをもつ場合を除いて)「クライアントの身元についてのあるべき姿」についての外部知識をもちませんので、チェックは不可能です。サーバーが(典型的には、HTTP や TLS 以外の何らかの源泉から)そのような知識をもつ場合、サーバーは、上記の身元をチェックする必要があります(SHOULD)

 

参考文献

[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo,
「インターネットX.509 PKI - 証明書と CRL のプロファイル(Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile)」,
RFC 2459, 1999年 1月.
 
[RFC2616] 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月.
 
[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key Words for use in RFCs to indicate Requirement Levels)」,
BCP 14
, RFC 2119, 1997年 3月.
 
[RFC2246] Dierks, T. and C. Allen,
「TLS プロトコル v1.0(The TLS Protocol)」,
RFC 2246, 1999年 1月.
 
[RFC2817] Khare, R. and S. Lawrence,
"Upgrading to TLS Within HTTP/1.1",
RFC 2817, 2000年 3月.

 

セキュリティについての考慮事項

本書全体がセキュリティに関するものです。

 

著者のアドレス

Eric Rescorla
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303

電話: (650) 328-8631
EMail: ekr@rtfm.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

Email: miyakawa@ipa.go.jp

 

著作権表記全文

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.

謝辞

Funding for the RFC Editor function is currently provided by the  Internet Society.