|
ネットワークワーキンググループ Request for Comments： 2818 分類： 情報提供 |
E. Rescorla RTFM, Inc. 2000年5月 |
このメモは、インターネットコミュニティに情報提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The Internet Society (2000). All Rights Reserved.
このメモは、 「インターネット越しのHTTPコネクションをセキュアにするためのTLSの使い方」を記述します。 現在の実践は、HTTPオーバーSSL(TLSの前身)とし、 異なるサーバーポートの利用によって、 セキュアにされたトラフィックをセキュアでないトラフィックと区別するものです。 本書は、その実践をTLSを使って文書化します。 併読文書は、 通常のHTTPと同一のポート上でHTTP/TLSを使うための手法を記述しています。 [RFC2817]
HTTP [RFC2616] は、当初、 インターネット上を平文で使われていました。 しかし、HTTPの取扱に注意を要するアプリケーション用の利用の増加により、 セキュリティ手段が要求されるようになりました。 SSLおよび、その後継であるTLS [RFC2246] は、 チャネルセキュリティ(経路のセキュリティ)提供するために設計されました。 本書は、HTTPオーバーTLSの使い方を記述します。
本書中のキーワード： "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY"は、 [RFC2119] に記述されているように解釈されるべきものです。
概念的には、HTTP/TLSは、非常に単純です。 単に、まさにHTTPをTCP上で使うようにHTTPオーバーTLSを使います。
HTTPクライアントとして働くエージェントは、 TLSクライアントとしても働く必要があります。 これは、サーバーに対するコネクションを適切なポート上で開始し、 TLSハンドシェイクを開始するためにTLS ClientHelloを送る必要があります。 TLSハンドシェイクが完了したとき、そのクライアントは、 最初のHTTPリクエストを開始できます。 すべてのHTTPデータは、 TLSの「アプリケーションデータ」として送られなければなりません(MUST)。 通信の維持を含む通常のHTTP動作は、この後に従う必要があります。
TLSは、セキュアなコネクション終了のための機能を提供します。 有効な終了アラートが受信されたとき、実装は、「そのコネクション上で、 これ以上のデータは受信されない」と想定することができます。 TLS実装は、コネクションを終了させる前に、 終了アラートの交換を開始しなければなりません(MUST)。 TLS実装は、終了アラートを送った後、 相手がその終了アラートを送信するのを待たずに、 「不完全な終了」を発生させることにより、 コネクションを終了できます(MAY)。 「これを行う実装は、 そのセッションを再利用できる(MAY)こと」に注意してください。 これは、アプリケーションが、(典型的には、 HTTPメッセージの境界を検出することを通じて)「関心あるすべてのメッセージデータを受信したこと」を知っているときにのみに行われるようにする必要があります(SHOULD)。
[RFC2246] において仕様とされているように、 まず、有効な終了アラート受信すること無しに(「時期尚早な終了」) コネクション終了を受信するいかなる実装も、 そのセッションを再利用してはなりません(MUST NOT)。 「時期尚早な終了は、既に受信したデータのセキュリティ問題とならないが、 以降のデータが切れている可能性があること」を端的に示していることに注意してください。 TLSは、HTTPリクエスト／レスポンスの境界を認識しないので、 「メッセージ中もしくはメッセージ間で切断が発生したか否か」を判定するために、 HTTPデータ自体(特に、 Content-Lengthヘッダー)を検証することが必要不可欠です。
HTTPでは、コネクションの終了をもってサーバーデータの終端を示すので、 クライアント実装は、いかなる時期尚早な終了をもエラーとして扱い、 受信したデータを切れている可能性があるものとして扱わなければならなりません(MUST)。 クライアントは、 切断が発生したかどうかをHTTPによって発見する場合もあるので、 完全なレスポンスを受信した場合、 「送信時には厳格、 受信時には寛容(であるようにする)」 [RFC1958] とする原則に従って、 そのようなエラーを許容することができます。 しばしば、切断は、HTTPプロトコルデータ中には表れないことがあります。 ； 特に2つの場合、注意に値します。：
Content-Lengthヘッダー無しのHTTPレスポンス。 この状況におけるデータ長は、コネクション終了によって示されるので、 サーバーによる時期尚早の終了は、 攻撃者によって生成された偽の終了と区別することができません。
有効なContent-LengthヘッダーをもったHTTPレスポンスが、 すべてのデータが読まれる前に終了した場合。 TLSは、文書指向の防護を提供しないので、 「サーバーがContent-Lengthの計算を誤ったのか、あるいは、 攻撃者がコネクションを切断したのか」を判定することは不可能です。
上記のルールについて、例外が1つあります。 時期尚早な終了に直面したとき、クライアントは、 Content-Lengthヘッダーに示されたのと同量のデータを受信したという、 すべてのリクエストを完了したものとして扱う必要があります(SHOULD)。
不完全な終了を検知したクライアントは、 粛々と復旧する必要があります(SHOULD)。 クライアントは、 このように終了されたTLSセッションを保持することができます(MAY)。
クライアントは、コネクションを終了する前に、 終了アラートを送らなければなりません(MUST)。 以降のデータを受信する準備ができていないクライアントは、 サーバーの終了アラートを待たないことを選択し、 単にコネクションを終了することができます(MAY)。 これによって、サーバー側に不完全な終了が発生します。
RFC 2616は、 HTTPクライアントにいつでもコネクションを終了することを許容し、 サーバーに粛々と回復することを要求します。 特に、サーバーは、 クライアントから不完全な終了を受信するための準備が必要です(SHOULD)。 なぜなら、しばしば、クライアントは、 「サーバーデータの終了時」を決定できるからです。 サーバーは、 このように終了されたTLSセッションを再開できる必要があります(SHOULD)。
実装上の注意： 継続的コネクションを使わないHTTP実装において、サーバーは、通常、 コネクションを終了することによって、 データの終端を示すことができることを期待します。 しかし、Content-Lengthが使われているとき、クライアントは、 既に終了アラートを送信してコネクションを棄却している可能性があります。
サーバーは、コネクションを終了する前に、 クライアントとの終了アラートの交換を開始することを試みなければなりません(MUST)。 サーバーは、終了アラートを送った後、 コネクションを終了することができ(MAY)、それゆえ、 クライアント側に不完全な終了を発生させます。
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を参照することによって生成されます。 その結果、 サーバーについてのホスト名がクライアントに知られることになります。 ホスト名が利用可能な場合、中間者による攻撃を予防するために、 クライアントは、 これをサーバーの証明書メッセージ中に示されたサーバーの身元に照らしてチェックしなければなりません(MUST)。
クライアントが期待されるサーバーの身元に関して外部情報をもつ場合、 ホスト名チェックは省略できます(MAY)。 (例えば、サーバーのアドレスとホスト名が動的でも、 サーバーが提示する証明書をクライアントが知っている場合は、 クライアントはこのサーバーに接続できます。)このような場合、 中間者による攻撃を予防するために、 可能な限り許容可能な証明書の範囲を狭めることが重要です。 特別な事例において、 クライアントが単にサーバーの身元を無視することが適切である可能性がありますが、 「このことは、 コネクションを積極的な攻撃に対して無防備なままにすること」が理解されなければなりません。
dNSName型のsubjectAltName拡張がある場合、それは、 身元として使われなければなりません(MUST)。 それ以外の場合は、 証明書のSubjectフィールドにある(最も具体的)なCommon Nameフィールドを使用しなければなりません(MUST)。 Common Nameの利用が既存の実践ですが、これは不当であり、 代わりに認証機関には、dNSNameを使うことが強く薦められます。
マッチングは、 [RFC2459] によって仕様とされているマッチングルールを使って行われます。 証明書内に特定のタイプの身元が複数存在する場合(dNSName名が複数ある場合や、 セット内の1つでも合致すれば許可される場合など)、 Nameは、 任意の単一ドメイイン名コンポーネントまたはコンポーネントフラグメントに合致するとみなされるワイルドカード記号 * を含むことができます。 (例： *.a.comは、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を置き換えていた可能性があります。 この種の攻撃を予防するために、ユーザは、 期待に適合するかを判断するために、 サーバーによって提供された証明書を注意深く確認する必要があります。
典型的には、サーバーは、 (クライアントが適切な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.