Network Working Group E. Rescorla
Request for Comments: 2818 RTFM, Inc.
Category: Informational May 2000
Network Working Group E. Rescorla
Request for Comments: 2818 RTFM, Inc.
Category: Informational May 2000
HTTP Over TLS
TLS上的HTTP
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].
本备忘录描述了如何使用TLS保护Internet上的HTTP连接。当前的做法是在SSL上分层HTTP（TLS的前身），通过使用不同的服务器端口区分安全流量和不安全流量。本文档记录了使用TLS的实践。附带文档描述了在与普通HTTP相同的端口上使用HTTP/TLS的方法[RFC2817]。
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
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]最初用于Internet上的clear。然而，对敏感应用程序越来越多地使用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].
本文件中出现的关键词“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照[RFC2119]中所述进行解释。
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.
从概念上讲，HTTP/TLS非常简单。只需在TLS上使用HTTP，就像在TCP上使用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 ClientHello以开始TLS握手。当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
如[RFC2246]中所述，任何接收到连接关闭而未首先接收到有效关闭警报（“过早关闭”）的实现都不得重用该会话。请注意，过早关闭不会对已接收数据的安全性产生疑问，而只是表示后续数据可能会丢失
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.
已被截断。由于TLS不受HTTP请求/响应边界的影响，因此有必要检查HTTP数据本身（特别是内容长度头），以确定截断是发生在消息内部还是消息之间。
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协议数据中；特别值得注意的是两个案例：
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响应。由于这种情况下的数据长度由连接关闭发出信号，因此无法将服务器生成的过早关闭与攻击者生成的虚假关闭区分开来。
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响应。由于TLS不提供面向文档的保护，因此无法确定服务器是否错误计算了内容长度，或者攻击者是否截断了连接。
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.
上述规则有一个例外。当遇到过早关闭时，客户机应将其已收到内容长度标头中指定的数据的所有请求视为已完成。
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.
RFC2616允许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服务器期望从客户机接收的第一个数据是请求行生产。TLS服务器（因此也是HTTP/TLS服务器）希望接收的第一个数据是ClientHello。因此，通常的做法是在一个单独的端口上运行HTTP/TLS，以区分正在使用哪个协议。通过TCP/IP连接运行HTTP/TLS时，默认端口为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 URI的区别在于使用“https”协议标识符代替“HTTP”协议标识符。指定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的引用而生成的。因此，客户端知道服务器的主机名。如果主机名可用，客户端必须根据服务器的证书消息中显示的服务器身份进行检查，以防止中间人攻击。
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.
使用[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地址而不是主机名。在这种情况下，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是通过点击HTML页面获得的，而HTML页面本身不需要使用HTTP/TLS，中间的一个人就可以替换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.，Ford，W.，Polk，W.和D.Solo，“互联网公钥基础设施：第一部分：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.，弗里斯泰克，H.，马斯特，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]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议”，RFC2246，1999年1月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年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
Eric Rescorla RTFM，Inc.加利福尼亚州东帕洛阿尔托市纽厄尔路30号，邮编：94303
Phone: (650) 328-8631 EMail: ekr@rtfm.com
电话：（650）328-8631电子邮件：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编辑功能的资金目前由互联网协会提供。