[要約] RFC 2818は、HTTP Over TLS（HTTPS）の仕様を定義しており、セキュアな通信を提供するために設計されています。このRFCの目的は、TLSを使用してHTTP通信を暗号化し、認証することで、データの機密性と信頼性を確保することです。
Network Working Group E. Rescorla
Request for Comments: 2818 RTFM, Inc.
Category: Informational May 2000
HTTP Over TLS
Status of this Memo
このメモの位置付け
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 Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
概要
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を使用するための方法を記載しています。
Table of Contents
目次
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、「アプリケーション・データ」として送らなければなりません。保持接続を含む、通常の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は、セキュア接続の閉鎖のための機能を提供します。有効な終了アラートを受信した場合、実装はそれ以上のデータは、その接続で受信されないことを保証することができます。 TLSの実装は、接続を閉じる前に閉鎖アラートの交換を開始しなければなりません。 TLSの実装は、終了アラートを送信した後、「不完全なクローズ」を生成、その終了アラートを送信する相手を待たずに接続を閉じます。これを行う実装がセッションを再利用することを選択するかもしれないことに注意してください。アプリケーションが知っている場合にのみ、それが気にすることを、すべてのメッセージデータを受信したこと（通常はHTTPメッセージの境界を検出することにより）行われるべきです。
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]で指定されているように、最初の有効な終了アラート（「時期尚早クローズ」）を受信せずに近い接続を受ける任意の実装では、そのセッションを再利用してはいけません。時期尚早近いが質問にすでに受信したデータのセキュリティを呼び出すことはありませんが、単に後続のデータが切り捨てられている可能性があることを示しています。 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は、サーバデータの終わりを知らせるために、接続の閉鎖を使用しているため、クライアントの実装はエラーとして任意の時期尚早閉じを扱わなければなりませんし、データが潜在的に切り捨てられました。いくつかのケースでは、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ヘッダに指定されている限り多くのデータを受信したために完了したすべての要求として扱うべきです。
A client detecting an incomplete close SHOULD recover gracefully. It MAY resume a TLS session closed in this fashion.
不完全なクローズを検出するクライアントは優雅に回復する必要があります。これは、この方法で閉じたTLSセッションを再開することができます。
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.
クライアントが接続を閉じる前に閉鎖警戒を送らなければなりません。任意のより多くのデータを受信する準備ができていないですクライアントは、サーバの終了アラートを待って、単にので、サーバ側で不完全なクローズを生成、接続を終了しないこともできます。
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クライアントを許可し、優雅に回復するサーバを必要とします。具体的には、サーバは、サーバデータの終わりがあるときに、クライアントが頻繁に決定することができるので、クライアントから不完全近くを受け取るために準備する必要があります。サーバーは、この方法で閉じたTLSセッションを再開するために喜んであるべきです。
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.
サーバーは、接続を閉じる前にクライアントとの閉鎖アラートの交換を開始しようとしなければなりません。サーバーは、このように、クライアント側での不完全なクローズを生成、終了アラートを送信した後、接続を閉じます。
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攻撃を防ぐために、サーバーの証明書メッセージに提示され、クライアントはサーバのアイデンティティに対してそれをチェックしなければなりません。
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.
クライアントがサーバの予想身元のような外部の情報を持っている場合は、ホスト名のチェックは省略されるかもしれません。 （例えば、クライアントは、そのアドレスとホスト名動的であるが、クライアントは、サーバが存在することの証明書を認識しているマシンに接続してもよい。）このような場合に、中に可能な限り許容される証明書の範囲を狭くすることが重要ですmiddle攻撃で男を防ぐため。特殊なケースでは、クライアントは、単にサーバーの身元を無視することが適切かもしれませんが、これは積極的な攻撃への接続を開いたままにすることを理解しなければなりません。
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として使用しなければなりません。それ以外の場合は、証明書のSubjectフィールドで（最も特定の）Common Nameフィールドを使用しなければなりません。共通名の使用は練習を既存しているが、それが廃止されており、認証機関は、代わりの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.
ホスト名が証明書で身元と一致しない場合は、ユーザー指向のクライアントは、ユーザーに通知しなければなりませんいずれか、または不正な証明書エラーとの接続を終了する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与える場合があります）。自動化されたクライアントは、適切な監査ログにエラーを記録しなければならない（可能な場合）と（悪い証明書エラーで）接続を終了すべきです。自動化されたクライアントは、このチェックを無効にしますが、それを可能に設定を提供しなければならない構成設定を提供することができます。
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）がそのような知識を持っている場合、上述のように、アイデンティティを確認してください。
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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネット公開鍵インフラストラクチャ：パート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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル、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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "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.およびS.ローレンス、 "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
Full Copyright Statement
完全な著作権声明
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機能のための基金は現在、インターネット協会によって提供されます。