Network Working Group                                       E. Rescorla
Request for Comments: 2818                                   RTFM, Inc.
Category: Informational                                        May 2000
        

HTTP Over TLS

HTTP Over TLS

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

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

著作権（C）インターネット協会（2000）。全著作権所有。

This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].

このメモは、インターネット上でHTTP接続を保護するためにTLSを使用する方法について説明します。現在の練習は別のサーバーポートを使用することにより、安全でないトラフィックから保護されたトラフィックを区別し、SSL（TLSの前身）の上にHTTPを層にあります。 TLSを使用して練習し、このドキュメントのドキュメント。仲間ドキュメントは、通常のHTTP [RFC2817]と同じポートを介してHTTP/TLSを使用するための方法を記載しています。

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . 2
   1.1. Requirements Terminology  . . . . . . . . . . . . . . . 2
   2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
   2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
   2.2. Connection Closure  . . . . . . . . . . . . . . . . . . 2
   2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
   2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
   2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
   2.4. URI Format  . . . . . . . . . . . . . . . . . . . . . . 4
   3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
   3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
   3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Security Considerations  . . . . . . . . . . . . . . . . . . 6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
   Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
        

HTTP [RFC2616] was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security measures. SSL, and its successor TLS [RFC2246] were designed to provide channel-oriented security. This document describes how to use HTTP over TLS.

HTTP [RFC2616]は、もともとインターネット上で明らかにしました。しかし、敏感なアプリケーションのためのHTTPの使用の増加は、セキュリティ対策を必要としています。 SSL、およびその後継TLS [RFC2246]は、チャネル指向のセキュリティを提供するように設計されました。この文書では、TLS上でHTTPを使用する方法について説明します。

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].

キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT" と[RFC2119]で説明したように解釈されるべきであり、この文書に表示される "MAY"。

Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.

概念的には、HTTP/TLSは非常に簡単です。あなたはTCP上でHTTPを使用するのと同じように、単に正確にTLS上でHTTPを使用します。

The agent acting as the HTTP client should also act as the TLS client. It should initiate a connection to the server on the appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The client may then initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data". Normal HTTP behavior, including retained connections should be followed.

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

TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". Note that an implementation which does this MAY choose to reuse the session. This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the message data that it cares about.

TLSは、接続を安全に閉じるための機能を提供します。有効なclosureアラートを受信した場合、実装はその接続でそれ以上データを受信しないことを確信できます。TLS実装は、接続を閉じる前にclosureアラートの交換を開始しなければなりません (MUST)。TLS実装は、closureアラートを送信した後、ピアがclosureアラートを送信するのを待たずに接続を閉じてもよく (MAY)、その場合「不完全なクローズ」となります。これを行う実装は、セッションを再利用することを選択してもよい (MAY) ことに注意してください。これは、アプリケーションが（通常はHTTPメッセージの境界を検出することによって）必要なすべてのメッセージデータを受信したことを把握している場合にのみ行うべきです (SHOULD)。

As specified in [RFC2246], any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") MUST NOT reuse that session. Note that a premature close does not call into question the security of the data already received, but simply indicates that subsequent data might have been truncated. Because TLS is oblivious to HTTP request/response boundaries, it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation occurred inside a message or between messages.

[RFC2246] で規定されているように、有効な終了アラート（「早期クローズ（premature close）」）をあらかじめ受信することなく接続のクローズを受信した実装は、そのセッションを再利用してはなりません (MUST NOT)。なお、早期クローズは、すでに受信したデータのセキュリティに疑義を生じさせるものではなく、単に後続のデータが切り詰められた可能性があることを示しているにすぎません。TLSはHTTPリクエスト/レスポンスの境界を関知しないため、切り詰めがメッセージの内部で発生したのか、メッセージ間で発生したのかを判断するには、HTTPデータ自体（具体的にはContent-Lengthヘッダー）を調べる必要があります。

Because HTTP uses connection closure to signal end of server data, client implementations MUST treat any premature closes as errors and the data received as potentially truncated. While in some cases the HTTP protocol allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such errors following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958], often truncation does not show in the HTTP protocol data; two cases in particular deserve special note:

HTTPは、サーバデータの終わりを知らせるために、接続の閉鎖を使用しているため、クライアントの実装はエラーとして任意の時期尚早閉じを扱わなければなりません (MUST)し、データが潜在的に切り捨てられました。いくつかのケースでは、HTTPプロトコルは、クライアントが切り捨てがなるように行われたかどうかを確認することができますが、それは完全な応答を受信した場合、それはに[RFC1958「を送信する際に厳格なと寛容を受け[こと]」の原則、次のようなエラーを許容します]、多くの場合、切り捨ては、HTTPプロトコルのデータには表示されません。特に、2つのケースは特別な注意に値します。

A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature close generated by the server cannot be distinguished from a spurious close generated by an attacker.

Content-LengthヘッダーのないHTTPレスポンス。この状況ではデータ長が接続のクローズによって通知されるため、サーバーによって生じた早期クローズと、攻撃者によって生じた偽りのクローズを区別することができません。

A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has truncated the connection.

すべてのデータが読み込まれた前に、有効なContent-Lengthヘッダーを持つHTTPレスポンスを閉じました。 TLSは、ドキュメント指向の保護を提供していないので、サーバーがコンテンツ長をmiscomputedたか、攻撃者が接続を切り捨てられたかどうかを判断することは不可能です。

There is one exception to the above rule. When encountering a premature close, a client SHOULD treat as completed all requests for which it has received as much data as specified in the Content-Length header.

上記のルールには1つの例外があります。早期クローズに遭遇した場合、クライアントはContent-Lengthヘッダーで指定された量のデータをすでに受信しているすべてのリクエストについて、完了したものとして扱うべきです (SHOULD)。

A client detecting an incomplete close SHOULD recover gracefully. It MAY resume a TLS session closed in this fashion.

不完全なクローズを検出するクライアントは優雅に回復すべきです (SHOULD)。これは、この方法で閉じたTLSセッションを再開することができます (MAY)。

Clients MUST send a closure alert before closing the connection. Clients which are unprepared to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.

クライアントが接続を閉じる前に閉鎖警戒を送らなければなりません (MUST)。任意のより多くのデータを受信する準備ができていないですクライアントは、サーバの終了アラートを待って、単にので、サーバ側で不完全なクローズを生成、接続を終了しないこともできます (MAY)。

RFC 2616 permits an HTTP client to close the connection at any time, and requires servers to recover gracefully. In particular, servers SHOULD be prepared to receive an incomplete close from the client, since the client can often determine when the end of server data is. Servers SHOULD be willing to resume TLS sessions closed in this fashion.

RFC 2616は、HTTPクライアントが任意の時点で接続を閉じることを許可しており、サーバーには正常に回復することを要求しています。特に、クライアントはサーバーデータの終了時期を判断できることが多いため、サーバーはクライアントからの不完全なクローズを受信することに備えておくべきです (SHOULD)。また、サーバーはこのようにしてクローズされたTLSセッションの再開を進んで受け入れるべきです (SHOULD)。

Implementation note: In HTTP implementations which do not use persistent connections, the server ordinarily expects to be able to signal end of data by closing the connection. When Content-Length is used, however, the client may have already sent the closure alert and dropped the connection.

実装上の注意：持続的な接続を使用していないHTTPの実装では、サーバーは、通常、接続を閉じることにより、データの終了を知らせることができるように期待しています。コンテンツの長さが使用されている場合は、しかし、クライアントがすでに終了アラートを送信して接続を切断した可能性があります。

Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers MAY close the connection after sending the closure alert, thus generating an incomplete close on the client side.

サーバーは、接続を閉じる前に、クライアントとのclosureアラートの交換を開始しようとしなければなりません (MUST)。サーバーは、closureアラートを送信した後に接続を閉じてもよく (MAY)、その結果、クライアント側では不完全なクローズとなります。

The first data that an HTTP server expects to receive from the client is the Request-Line production. The first data that a TLS server (and hence an HTTP/TLS server) expects to receive is the ClientHello. Consequently, common practice has been to run HTTP/TLS over a separate port in order to distinguish which protocol is being used. When HTTP/TLS is being run over a TCP/IP connection, the default port is 443. This does not preclude HTTP/TLS from being run over another transport. TLS only presumes a reliable connection-oriented data stream.

HTTPサーバがクライアントから受信することを期待最初のデータは、Request-ライン生産です。 TLSサーバー（したがってHTTP/TLSサーバー）が受信することを期待する最初のデータはのClientHelloあります。したがって、一般的に使用されているプロトコルを区別するために別々のポートを介してHTTP/TLSを実行することでした。 HTTP/TLSは、TCP/IP接続を介して実行されている場合は、デフォルトのポートはこれは別のトランスポート上で実行されてから、HTTP/TLSを排除するものではない443です。 TLSは、唯一の信頼できる接続指向のデータ・ストリームを前提とします。

HTTP/TLS is differentiated from HTTP URIs by using the 'https' protocol identifier in place of the 'http' protocol identifier. An example URI specifying HTTP/TLS is:

HTTP/TLSは、「HTTP」プロトコル識別子の代わりに「HTTPS」プロトコル識別子を使用して、HTTPのURIと区別されます。 HTTP/TLSを指定する例URIは以下のとおりです。

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

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

In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.

一般的には、HTTP/TLSリクエストは、URIを逆参照によって生成されます。その結果、サーバのホスト名がクライアントに知られています。ホスト名が使用可能な場合はman-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示され、クライアントはサーバのアイデンティティに対してそれをチェックしなければなりません (MUST)。

If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.

クライアントがサーバーの想定される識別情報に関する外部情報を持っている場合は、ホスト名のチェックを省略してもよいです (MAY)。（たとえば、クライアントは、アドレスとホスト名が動的に変わるものの、サーバーが提示する証明書をクライアントが把握しているマシンに接続している場合があります。）そのような場合、中間者攻撃を防ぐために、受け入れ可能な証明書の範囲をできるだけ狭めることが重要です。特殊な場合には、クライアントがサーバーの識別情報を単に無視することが適切な場合もありますが、そうすると接続が能動的な攻撃にさらされたままになることを理解しなければなりません。

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

型のdNSNameのsubjectAltName拡張が存在する場合、それはIDとして使用しなければなりません (MUST)。それ以外の場合は、証明書のSubjectフィールドで（最も特定の）Common Nameフィールドを使用しなければなりません (MUST)。共通名の使用は練習を既存しているが、それが廃止されており、認証機関は、代わりのdNSNameを使用することが推奨されています。

Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

マッチングは、[RFC2459]で指定されたマッチングルールを使用して実行されます。与えられたタイプの複数のアイデンティティが証明書に存在している場合（例えば、複数のdNSName名、セットのいずれかにおけるマッチは許容できると考えられる。）名前は、任意の単一に一致するように考えられているワイルドカード文字*を含むことができドメイン名のコンポーネントまたはコンポーネントの断片。例えば、*.a.comはfoo.a.comと一致しますが、bar.foo.a.comとは一致しません。f*.comはfoo.comと一致しますが、bar.comとは一致しません。

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

いくつかのケースでは、URIは、IPアドレスではなくホスト名として指定されています。この場合、IPアドレスのsubjectAltNameは証明書に存在する必要があり、正確にURIでIPと一致する必要があります。

If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.

ホスト名が証明書内の識別情報と一致しない場合、ユーザー向けのクライアントは、ユーザーに通知する（クライアントは、いずれの場合でもユーザーに接続を続行する機会を与えてもよい (MAY)）か、不正な証明書エラーで接続を終了するかのいずれかを行わなければなりません (MUST)。自動化されたクライアントは、（可能な場合）適切な監査ログにエラーを記録しなければならず (MUST)、（不正な証明書エラーで）接続を終了すべきです (SHOULD)。自動化されたクライアントは、このチェックを無効にする構成設定を提供してもよいですが (MAY)、それを有効にする設定を提供しなければなりません (MUST)。

Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations.

多くの場合、URI自体が信頼できないソースから来ていることに注意してください。上記のチェックは、このソースが侵害された攻撃に対する保護機能はありません。 URI自体がHTTP/TLSを使用せずに得られたHTMLページをクリックすることで得られた場合には、例えば、真ん中の男はURIを交換した可能性があります。この形式の攻撃を防ぐために、ユーザーは慎重に、それは彼らの期待を満たしているかどうかを判断するために、サーバーが提示した証明書を調べる必要があります。

Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the client has a certificate chain rooted in an appropriate CA) are not possible. If a server has such knowledge (typically from some source external to HTTP or TLS) it SHOULD check the identity as described above.

通常、サーバーはクライアントの識別情報がどうあるべきかについての外部知識を持たないため、（クライアントが適切なCAをルートとする証明書チェーンを持っていること以外の）チェックは不可能です。サーバーがそのような知識を（通常はHTTPまたはTLSの外部の何らかの情報源から）持っている場合は、上述のように識別情報をチェックすべきです (SHOULD)。

References

リファレンス

[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.

[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "インターネット公開鍵インフラストラクチャ：パートI：X.509証明書とCRLプロファイル"、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, June 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "ハイパーテキスト転送プロトコル、HTTP/1.1"、RFC 2616年、1999年6月。

[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner, S., "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.

[RFC2246] Dierks, T. and C. Allen, "TLSプロトコル"、RFC 2246、1999年1月。

[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.

[RFC2817] Khare, R. and S. Lawrence, "HTTP/1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。

Security Considerations

セキュリティの考慮事項

This entire document is about security.

この全体のドキュメントはセキュリティに関するものです。

Author's Address

著者のアドレス

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

エリックレスコラRTFM、Inc.の30ニューウェル・ロード、＃16イーストパロアルト、CA 94303

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

電話：（650）328-8631 Eメール：ekr@rtfm.com

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

著作権（C）インターネット協会（2000）。全著作権所有。

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.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。