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.
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].
このメモは、 TLS を使ってインターネット上の HTTP 接続を安全にする方法を説明します。現在の慣習は HTTP を SSL (TLS の先駆け) 上の層とし、 違った鯖のポートを使って安全な通信と安全でない通信を分けるというものです。 RFC 2817 は通常の HTTP と同じポート上で 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 は元々インターネット上で平文で使われていました。 しかし、繊細な応用に HTTP を使うことが増えて参りましたので、 安全の仕組みが必要になっています。 SSL とその後継である TLS はチャンネル指向の安全を提供するよう設計されました。 この文書は HTTP を TLS 上で使う方法を説明します。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.
概念的には、 HTTP/TLS は非常に簡単です。 HTTP を TCP の上で使うのと同じように、単純に HTTP を TLS の上で使います。
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 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.
RFC 2246 で規定されているとおり、
妥当な終結通知なしの接続終結 (早すぎる終結
)
を受取った実装は、そのセッションを再利用してはなりません。
早すぎる終結はすでに受信したデータの安全性についての疑問は呈さず、
単純に以降のデータは切り捨てられているかもしれないということを示しています。
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 プロトコルは場合によってはクライアントが切捨てが行われたかどうかを判断することを認めていますが、
完全な返答を受信したなら、人に優しく自分に厳しく
(送信の時は厳密に、受信の時は寛大に) の原則に従って、
そのような誤りも多めに見てもかまいません。しばしば、
切捨ては 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.
HTTP 応答に Content-Length]] 頭がない場合。
この状況ではデータ長は接続の終結で通知されますから、
鯖が早すぎる終結を行うと攻撃者による偽の終結と区別できません。
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.
HTTP 応答に妥当な Content-Length 頭があり、
すべてのデータを読む前に閉じられた場合。
TLS は文書指向の保護を提供しませんから、
鯖が Content-Length を誤計算したのか、
攻撃者が接続を切り捨てたのかは決定できません。
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 実装では、
鯖は普通接続を閉じることによってデータの終了を通知することができると期待されます。
しかし、 Content-Length が使われる場合、
クライアントは既に終結通知を送信していて接続を落とすかもしれません。
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-Line 生成規則です。
TLS 鯖 (そして後に HTTP/TLS 鯖) が最初に受信することを期待するデータは
ClientHello です。ですから、
共通の慣習はどちらのプロトコルが使われているのかを区別するために HTTP/TLS
を別のポートで走らせるということになっています。
HTTP/TLS が TCP/IP 接続の上で動いている時は、
既定のポートは 443 です。これは HTTP/TLS
を他の輸送路で動かすことを禁ずるものではありません。 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
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 の参照を解くことにより生成されます。
従って、クライアントには鯖のホスト名は分かっています。
クライアントは、ホスト名が利用可能であれば、途中の人攻撃を防ぐため、
それと鯖の Certificate メッセージに示された識別情報を確認しなければなりません。
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.
クライアントが期待される鯖の識別についての外部情報を持っていれば、 ホスト名の確認は省略して構いません。 (たとえば、クライアントは番地とホスト名が動的であってもクライアントがその鯖が示す証明書を知っている機械なら、 接続して構いません。) その場合、可能な限り途中の人攻撃を防ぐため、 受け入れる証明の範囲を狭めることが重要です。特別な場合、 クライアントは鯖の識別を単に無視するのが適当かもしれませんが、 接続を開き放しで攻撃を活性化することを理解しなければなりません。
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 拡張が提示されている場合、
これは識別として使わなければなりません。そうでなければ、
証明書の 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.
一致は、RFC 2459 で規定された一致規則を使って行います。
証明書にある型の識別が複数存在する場合 (たとえば dNSName
名が複数ある場合)、その中のどれに対する一致も受入れ可能と考えます。
名前は、 wildcard 文字 * を含んでも構いません。
* は任意の一つのドメイン名部品または部品素片を表します。
たとえば、 *.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 番地で指定されています。
この場合には、証明書中に IPAddress 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 以外の外部の出所から) 持ち合わせているときは、前述のように識別を検査するべきです。
[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.This entire document is about security.
この文書は全体が安全性についてです。
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.
Funding for the RFC Editor function is currently provided by the Internet Society.