Network Working Group E. Rescorla Request for Comments: 2818 RTFM, Inc. Category: Informational May 2000 TLS上のHTTP このメモの位置付け このメモは、インターネット・コミュニティに情報を提供するものである。 インターネット標準を規定するものではない。このメモの配布は無制限である。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 このメモは、TLSを使用して、インターネット上のHTTPコネクションをセキュアに 行う方法を示す。現在、SSL(TLSの前身)上にHTTPを形成し、セキュアと非セキュア とのトラフィックを区別するために、異なるサーバポート番号を使用することが 実際に行われている。このドキュメントでは、TLSを使用してこれを行う方法を 示すものである。関連ドキュメントでは、通常のHTTPと同じポート上でHTTP/TLS を使用するための方法を示す [RFC2817]。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. TLS上のHTTP . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. コネクションの開始 . . . . . . . . . . . . . . . . . . 2 2.2. コネクションの終了 . . . . . . . . . . . . . . . . . . 2 2.2.1. クライアントの振る舞い . . . . . . . . . . . . . . . 3 2.2.2. サーバの振る舞い . . . . . . . . . . . . . . . . . . 3 2.3. ポート番号 . . . . . . . . . . . . . . . . . . . . . . 4 2.4. URI フォーマット . . . . . . . . . . . . . . . . . . . 4 3. 他端の認証 . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. サーバのアイデンティティ . . . . . . . . . . . . . . . 4 3.2. クライアントのアイデンティティ . . . . . . . . . . . . 5 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 セキュリティに関する考察 . . . . . . . . . . . . . . . . . . 6 著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . 6 著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. はじめに HTTP [RFC2616] は元々、インターネット上で暗号化されずに使用されていた。 しかし、セキュリティに敏感なアプリケーションにおいてもHTTPが使用される ようになったため、セキュリティ対策を必要とすることとなった。 SSL、そして それを継承したTLS [RFC2246] は、チャネル志向のセキュリティを提供するよう に設計されたものである。このドキュメントでは、TLS上でHTTPを使用するため の方法を示す。 1.1. 用語 本ドキュメントに現れるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHOULD"、 "SHOULD NOT"、"MAY"は、[RFC2119] で示されるように解釈されなければならない。 2. TLS上のHTTP 概念的には、HTTP/TLSは非常に簡単である。 TLS上でHTTPを使用するのは、 TCP上でHTTPを使用するのとまったく同じである。 2.1. コネクションの開始 HTTPクライアントとして動作するエージェントはまた、TLSクライアントとして 動作するべきである。エージェントは、適切なポート上で動作しているサーバへ のコネクションを開始し、TLSのClientHelloを送信することによりTLSハンドシェ イクを開始するべきである。TLSハンドシェイクが終了すると、クライアントは 最初のHTTPリクエストの送信を開始してもよい。すべてのHTTPデータは、TLSの 「アプリケーションデータ」として送信しなければならない(MUST)。通常のHTTP の動作、これはコネクションの継続を含むものであるが、これはその後に処理さ れる。 2.2. コネクションの終了 TLSでは、セキュアなコネクション終了機能を提供している。有効な終了アラート を受信したときには、実装においては、そのコネクションではこれ以上データ を受信しないものと考えることができる。TLS実装においては、コネクションを 閉じる前に、終了アラートの交換を行わなければならない(MUST)。TLS実装に おいては、終了アラートを送信した後、他方のピアが終了アラートを送信する のを待たずにコネクションを閉じるという、「不完全な終了」を行ってもよい (MAY)。これを行う実装においては、セションの再利用を行ってもよいことに 注意。ただしこれを行うのは、(通常は、HTTPメッセージ境界を検出したことを 通じて)アプリケーションがすべてのメッセージデータを受け取ったことを知っ ている場合のみであるべきである(SHOULD)。 [RFC2246]で規定されているように、有効な終了アラートを受信せずにコネク ションの終了を受信した(これを「早すぎる終了」と呼ぶ)実装においては、 そのセションを再利用してはならない(MUST NOT)。この「早すぎる終了」という のは、すでに受信したデータのセキュリティに関しては問題ないが、その後の データが切断されているかもしれないということを示していることに注意。 TLSは、HTTPリクエスト/レスポンスの境界には気づかないので、HTTPデータ自体 (特にContent-Lengthヘッダ)を調べ、メッセージ中、またはメッセージ間で データ切断が発生したかどうかを決定する必要がある。 2.2.1. クライアントの振る舞い HTTPでは、コネクションの終了をもってサーバからのデータの終了を通知して いるため、クライアント実装では、「早すぎる終了」はすべてエラーとして扱わ なければならない(MUST)。そして受信したデータは切断されている可能性がある ものとして扱わなければならない。ある場合には、HTTPプロトコルにより、 切断が行われた個所を特定することが出来る。それゆえ、レスポンスが完全 であれば、「送信時には厳しく、受信時には寛大に」という原則 [RFC1958] により、そのエラーを許容してもよい。ただしHTTPプロトコルデータではトラン ケーションが発見できない場合もある。特に次の二つの場合が注意に値する。 Content-LengthヘッダのないHTTPレスポンス。この場合におけるデータ長は、 コネクションの終了によって通知されるため、サーバによる「早すぎる終了」は、 攻撃者による偽の終了と区別することができない。 すべてのデータを読み込んで終了する前に、有効なContent-LengthヘッダがHTTP レスポンスにあった場合。TLSでは、ドキュメント志向の保護を提供していない ため、サーバがContent-Lengthを計算違いしたか、または攻撃者がコネクション を切断したかは区別がつかない。 上記のルールにおいては、一つの例外がある。「早すぎる終了」に遭遇したとき、 Content-Lengthヘッダに示されたデータと同量のデータを受信している場合 には、クライアントはそれを完全なリクエストとして扱うべきである(SHOULD)。 「不完全な終了」を検出したクライアントは、穏やかにそれを回復するべきで ある(SHOULD)。この方法により終了したTLSセションは再利用してもよい(MAY)。 コネクションを終了する前には、クライアントは終了アラートを送信しなければ ならない(MUST)。これ以上データを受信する用意のないクライアントでは、 サーバの終了アラートを待たず、そのまま単純にコネクションを終了してもよい (MAY)。その結果、サーバ側で「不完全な終了」が発生することになる。 2.2.2. サーバの振る舞い RFC 2616では、HTTPクライアントはいつコネクションを終了してもよいことに なっている。そしてサーバはそれを穏やかに回復する必要があるとしている。 特に、サーバはクライアントから「不完全な終了」を受信するための準備をする べきである(SHOULD)。これは、クライアントはサーバデータの終了を決定する ことができるからである。サーバは、この方法で終了したTLSセションは再利用 できるようにすべきである(SHOULD)。 実装上の注意: 継続的コネクションを使用しないHTTP実装では、通常サーバは、 コネクションを終了することによってデータの終了を通知したいと考えている。 しかし、Content-Lengthが使用されたときには、クライアントが終了アラート を送信し、コネクションを終了するかもしれない。 サーバは、コネクションを終了する前に、クライアントと終了アラートの交換を しようとしなければならない(MUST)。サーバは、終了アラートを送信した後には、 コネクションを終了してもよい(MAY)。その結果、クライアント側で「不完全な 終了」となる。 2.3. ポート番号 HTTPサーバがクライアントから受信することを期待している最初のデータは、 Request-Lineである。TLSサーバ(すなわちHTTP/TLSサーバ)がクライアントから 受信することを期待している最初のデータは、ClientHelloである。このため、 使用されているプロトコルを区別するために、別々のポート上でHTTP/TLSを動作 させるのが一般的である。HTTP/TLSがTCP/IPコネクション上で動作しているとき のデフォルトポートは443である。ただしこれは、HTTP/TLSが他のポート上で 動作することを禁止するものではない。TLSは、信頼のできるコネクション志向 のデータストリームを想定しているだけである。 2.4. URI フォーマット HTTP/TLSは、'http'プロトコル識別子の代わりに、'https'プロトコル識別子を 使用することによって、HTTP URIと区別される。HTTP/TLSを指定しているURIの 例としては、以下のようなものが挙げられる。 https://www.example.com/~smith/home.html 3. 他端の認証 3.1. サーバのアイデンティティ 一般に、HTTP/TLSリクエストは、URIを解析することによって生成される。これ により、クライアントはサーバのホスト名を知ることとなる。ホスト名が利用 可能であるならば、クライアントは、サーバからのCertificateメッセージに より提示されるサーバのアイデンティティに対する、ホスト名のチェックを行わ なければならない(MUST)。これはなりすまし攻撃を防ぐためである。 サーバのアイデンティティであるとされる情報をクライアントが別に保持している ならば、ホスト名チェックは省略してもよい(MAY)。 (例えば、アドレスとホスト 名は動的なものであるが、サーバが提示する証明書をクライアントがすでに知っ ているようなマシンには接続してもよい。）そのような場合では、受理できる 証明書の範囲をできるだけ狭くすることが大切である。これはなりすまし攻撃を 防ぐためである。ある特別な場合では、単純にサーバのアイデンティティを無視し ても問題ないかもしれない。しかしこれは、そのコネクションが積極的な攻撃を 受ける可能性のある状態のままであることは理解しなければならない。 証明書においてsubjectAltNameエクステンションに対しdNSName型が指定されて いる場合には、これをアイデンティティとして使用しなければならない(MUST)。 そうでない場合には、証明書のSubjectフィールドにおける(最も特定の可能な) Common Nameフィールドを使用しなければならない(MUST)。Common Nameを使用 することはすでに行われているが、それは推奨されず、認証局においては代わり にdNSNameを使用することが推奨される。 [RFC2459]によって規定されているマッチングルールを使用して、マッチングが 実行される。証明書に一つ以上のアイデンティティが存在するならば(例えば、 一つ以上のdNSName型がある、またはそれらのどれか一つでもマッチすれば受理 できると考えられるなど)、Nameにはワイルドカードキャラクタ * を含めても よい。これは、ドメイン名コンポーネントの一つ、すなわちコンポーネントを 分割したときの一つにマッチすると考えることができる。例えば、*.a.comは、 foo.a.comにはマッチするが、bar.foo.a.comにはマッチしない。f*.comはfoo.com にはマッチするが、bar.comにはマッチしない。 ある場合においては、URIはホスト名ではなくIPアドレスで指定される。この場合、 subjectAltNameエクステンションのiPAddress型が証明書に存在していなければ ならず、またURIにおけるIPに正確に一致しなければならない。 ホスト名が証明書のアイデンティティとマッチしない場合には、ユーザ志向クライ アントは、ユーザに通知する(クライアントは、どのような場合でもコネクション を続行することのできる機会をユーザに提供してもよい(MAY))か、または bad certificate アラートによりコネクションを終了しなければならない(MUST)。 自動化されたクライアントでは、(利用可能であるならば)適切な監査ログに エラーを記録しなければならない(MUST)。そして（ bad certificateアラートに より）コネクションを終了するべきである(SHOULD)。自動化されたクライアント では、このチェックを無効化する設定を提供してもよい(MAY)が、それを可能に する設定は提供しなければならない(MUST)。 多くの場合、URI自身は信頼のできない情報源から来ることに注意。上記の チェック方法は、この情報源が危険にさらされているところでは、攻撃に対して の保護とはならない。例えば、そのURI自体が、HTTP/TLSを使用しないで得ら れたHTMLページをクリックすることによって得られたものであれば、なりすま した攻撃者が、すでにそのURIを変更しているかもしれない。このような攻撃を 防ぐために、ユーザはサーバによって提供された証明書を注意深く調べ、それが ユーザの期待を満たすものかどうかを決定すべきである。 3.2. クライアントのアイデンティティ 通常サーバには、クライアントのアイデンティティがどのようなものであるべき かに関する知識は保持していない。そのため、(クライアントには、適切なCAを ルートとする証明書チェーンがあるということ以外の)チェックを行うことは できない。もしサーバにそのような知識(通常、HTTPまたはTLS以外の何らかの 情報源)がある場合には、上記のアイデンティティのチェックをすべきである (SHOULD)。 参考文献 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 2459, January 1999. [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, June 1999. [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. セキュリティに関する考察 このドキュメント全体は、セキュリティに関するものである。 著者のアドレス Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303 Phone: (650) 328-8631 EMail: ekr@rtfm.com 著作権表示 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によって提供されている。 日本語訳 西原 啓輔 2001年5月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。