Internet Engineering Task Force (IETF) A. Langley
Request for Comments: 7918 N. Modadugu
Category: Informational B. Moeller
ISSN: 2070-1721 Google
August 2016
Internet Engineering Task Force (IETF) A. Langley
Request for Comments: 7918 N. Modadugu
Category: Informational B. Moeller
ISSN: 2070-1721 Google
August 2016
Transport Layer Security (TLS) False Start
传输层安全性（TLS）错误启动
Abstract
摘要
This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.
本文档指定了传输层安全性（TLS）客户端实现的可选行为，称为“错误启动”。它只影响协议定时，不影响有线协议数据，并且可以单方面实现。TLS错误启动将握手延迟减少到一次往返。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7918.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7918.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. False Start Compatibility . . . . . . . . . . . . . . . . . . 4
4. Client-Side False Start . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 6
5.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 7
5.3. Key Exchange and Client Certificate Type . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. False Start Compatibility . . . . . . . . . . . . . . . . . . 4
4. Client-Side False Start . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 6
5.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 7
5.3. Key Exchange and Client Certificate Type . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246] requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data. Thus, using TLS can add a latency penalty of two network round-trip times for application protocols in which the client sends data first, such as HTTP [RFC7230]. Figure 1 (copied from [RFC5246]) shows the message flow for a full handshake.
在TLS协议版本高达TLS 1.2[RFC5246]的情况下，完全握手需要两次完整的协议回合（四次飞行），然后握手完成，协议方可以开始发送应用程序数据。因此，对于客户端首先发送数据的应用程序协议（如HTTP[RFC7230]），使用TLS会增加两次网络往返时间的延迟惩罚。图1（从[RFC5246]复制）显示了完整握手的消息流。
Client Server
客户端服务器
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1: Message Flow for a Full Handshake
图1：完整握手的消息流
This document describes a technique that alleviates the latency burden imposed by TLS: the client-side TLS False Start. If certain conditions are met, the client can start to send application data when the full handshake is only partially complete, namely, when the client has sent its own ChangeCipherSpec and Finished messages (thus having updated its TLS Record Protocol write state as negotiated in the handshake) but has yet to receive the server's ChangeCipherSpec and Finished messages. (Per Section 7.4.9 of [RFC5246], after a full handshake, the client would have to delay sending application data until it has received and validated the server's Finished message.) Accordingly, the latency penalty for using TLS with HTTP can be kept at one round-trip time.
本文档描述了一种减轻TLS带来的延迟负担的技术：客户端TLS错误启动。如果满足某些条件，则当完全握手仅部分完成时，即当客户端已发送其自己的ChangeCipherSpec和Finished消息（从而更新了其在握手中协商的TLS记录协议写入状态）时，客户端可以开始发送应用程序数据但尚未收到服务器的ChangeCipherSpec和完成的消息。（根据[RFC5246]第7.4.9节，在完全握手后，客户端必须延迟发送应用程序数据，直到它接收并验证服务器的完成消息。）因此，使用TLS和HTTP的延迟惩罚可以保持在一个往返时间。
Note that in practice, the TCP three-way handshake [RFC0793] typically adds one round-trip time before the client can even send the ClientHello. See [RFC7413] for a latency improvement at that level.
注意，在实践中，TCP三方握手[RFC0793]通常会在客户端发送ClientHello之前增加一次往返时间。请参阅[RFC7413]了解该级别的延迟改进。
When an earlier TLS session is resumed, TLS uses an abbreviated handshake with only three protocol flights. For application protocols in which the client sends data first, this abbreviated handshake adds just one round-trip time to begin with, so there is no need for a client-side False Start. However, if the server sends application data first, the abbreviated handshake adds two round-trip times, and this could be reduced to just one added round-trip time by doing a server-side False Start. There is little need for this in practice, so this document does not consider server-side False Starts further.
当先前的TLS会话恢复时，TLS只使用三个协议航班的简短握手。对于客户端首先发送数据的应用程序协议，这种简短的握手只增加了一次往返时间，因此不需要客户端错误启动。但是，如果服务器首先发送应用程序数据，则缩短的握手会增加两次往返时间，而通过执行服务器端错误启动，这可以减少到只增加一次往返时间。在实践中很少需要这样做，所以本文不考虑服务器端错误启动。
Note also that TLS versions 1.3 [TLS13] and beyond are out of scope for this document. False Start will not be needed with these newer versions since protocol flows minimizing the number of round trips have become a first-order design goal.
另请注意，TLS版本1.3[TLS13]及更高版本不在本文件范围内。这些较新版本不需要错误启动，因为将往返次数最小化的协议流已成为首要设计目标。
In a False Start, when the client sends application data before it has received and verified the server's Finished message, there are two possible outcomes:
在错误启动中，当客户端在接收并验证服务器的已完成消息之前发送应用程序数据时，可能会出现两种结果：
o The handshake completes successfully: The handshake is retroactively validated when both Finished messages have been received and verified. This retroactively validates the handshake. In this case, the transcript of protocol data carried over the transport underlying TLS will look as usual, apart from the different timing.
o 握手成功完成：当两条完成的消息都被接收并验证后，握手将被追溯验证。这可以追溯验证握手。在这种情况下，除了不同的时间之外，通过传输底层TLS传输的协议数据的转录本将与往常一样。
o The handshake fails: If a party does not receive the other side's Finished message or if the Finished message's contents are not correct, the handshake never gets validated. This means that an attacker may have removed, changed, or injected handshake messages. In this case, data has been sent over the underlying transport that would not have been sent without the False Start.
o 握手失败：如果一方没有收到另一方已完成的消息，或者已完成消息的内容不正确，则握手永远不会得到验证。这意味着攻击者可能已删除、更改或注入握手消息。在这种情况下，数据是通过基础传输发送的，如果没有错误的启动，数据是不会发送的。
The latter scenario makes it necessary to restrict when a False Start is allowed, as described in this document. Section 3 considers basic requirements for using False Start. Section 4 specifies the behavior for clients, referring to important security considerations in Section 5.
后一种情况需要限制何时允许错误启动，如本文档所述。第3节考虑了使用假启动的基本要求。第4节指定了客户端的行为，参考第5节中的重要安全注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
TLS False Start as described in detail in the subsequent sections, if implemented, is an optional feature.
如有实施，后续章节中详细描述的TLS假启动是可选功能。
A TLS server implementation is defined to be "False Start compatible" if it tolerates receiving TLS records on the transport connection early, before the protocol has reached the state to process them. For successful use of client-side False Start in a TLS connection, the server has to be False Start compatible. Out-of-band knowledge that the server is False Start compatible may be available, e.g., if this is mandated by specific application profile standards. As discussed in Appendix A, the requirement for False Start compatibility generally does not pose a hindrance in practice.
如果TLS服务器实现允许在协议达到处理TLS记录的状态之前提前接收传输连接上的TLS记录，则该实现被定义为“假启动兼容”。要在TLS连接中成功使用客户端错误启动，服务器必须与错误启动兼容。例如，如果特定的应用程序配置文件标准强制要求这样做，则可以获得服务器与假启动兼容的带外知识。如附录A所述，假启动兼容性要求通常不会在实践中造成阻碍。
This section specifies a change to the behavior of TLS client implementations in full TLS handshakes.
本节指定在完整TLS握手中对TLS客户端实现行为的更改。
When the client has sent its ChangeCipherSpec and Finished messages, its default behavior per [RFC5246] is to not send application data until it has received the server's ChangeCipherSpec and Finished messages, which completes the handshake. With the False Start protocol modification, the client MAY send application data earlier (under the new Cipher Spec) if each of the following conditions is satisfied:
当客户端已发送其ChangeCipherSpec和Finished消息时，根据[RFC5246]，其默认行为是在收到服务器的ChangeCipherSpec和Finished消息（完成握手）之前不发送应用程序数据。通过修改假启动协议，如果满足以下每一个条件，客户端可以提前发送应用程序数据（根据新密码规范）：
o The application layer has requested the TLS False Start option.
o 应用层已请求TLS假启动选项。
o The symmetric cipher defined by the cipher suite negotiated in this handshake has been whitelisted for use with False Start according to the Security Considerations in Section 5.1.
o 根据第5.1节中的安全考虑，本次握手中协商的密码套件定义的对称密码已被列入白名单，用于假启动。
o The protocol version chosen by ServerHello.server_version has been whitelisted for use with False Start according to the Security Considerations in Section 5.2.
o 根据第5.2节中的安全注意事项，ServerHello.server_版本选择的协议版本已被列入白名单，用于错误启动。
o The key exchange method defined by the cipher suite negotiated in this handshake and, if applicable, its parameters have been whitelisted for use with False Start according to the Security Considerations in Section 5.3.
o 根据第5.3节中的安全注意事项，由本次握手中协商的密码套件定义的密钥交换方法及其参数（如适用）已被列入白名单，用于假启动。
o In the case of a handshake with client authentication, the client certificate type has been whitelisted for use with False Start according to the Security Considerations in Section 5.3.
o 在使用客户端身份验证进行握手的情况下，根据第5.3节中的安全注意事项，客户端证书类型已被列入白名单，用于假启动。
The rules for receiving data from the server remain unchanged.
从服务器接收数据的规则保持不变。
Note that the TLS client cannot infer the presence of an authenticated server until all handshake messages have been received. With False Start, unlike with the default handshake behavior, applications are able to send data before this point has been reached: from an application point of view, being able to send data does not imply that an authenticated peer is present. Accordingly, it is recommended that TLS implementations allow the application layer to query whether the handshake has completed.
请注意，在收到所有握手消息之前，TLS客户端无法推断是否存在经过身份验证的服务器。与默认握手行为不同，使用False Start时，应用程序能够在到达该点之前发送数据：从应用程序的角度来看，能够发送数据并不意味着存在经过身份验证的对等方。因此，建议TLS实现允许应用层查询握手是否已完成。
In a TLS handshake, the Finished messages serve to validate the entire handshake. These messages are based on a hash of the handshake so far processed by a Pseudorandom Function (PRF) keyed with the new master secret (serving as a Message Authentication Code (MAC)) and are also sent under the new Cipher Spec with its keyed MAC, where the MAC key again is derived from the master secret. The protocol design relies on the assumption that any server and/or client authentication done during the handshake carries over to this. While an attacker could, for example, have changed the cipher suite list sent by the client to the server and thus influenced cipher suite selection (presumably towards a less secure choice) or could have made other modifications to handshake messages in transmission, the attacker would not be able to round off the modified handshake with a valid Finished message: every TLS cipher suite is presumed to key the PRF appropriately to ensure unforgeability. Verifying the Finished messages validates the handshake and confirms that the handshake has not been tampered with; thus, secure encryption is bootstrapped from secure authentication.
在TLS握手中，完成的消息用于验证整个握手。这些消息基于迄今为止由伪随机函数（PRF）处理的握手散列，该伪随机函数以新的主密钥（用作消息认证码（MAC））为密钥，并且还根据新的密码规范及其密钥MAC发送，其中MAC密钥再次从主密钥派生。协议设计依赖于这样一种假设，即在握手过程中进行的任何服务器和/或客户端身份验证都会延续到该协议。例如，攻击者可能更改了客户端发送给服务器的密码套件列表，从而影响了密码套件的选择（可能是为了不太安全的选择），或者可能对传输中的握手消息进行了其他修改，攻击者将无法使用有效的完成消息对修改后的握手进行取整：假定每个TLS密码套件对PRF进行适当的密钥设置，以确保不可伪造性。验证完成的消息验证握手并确认握手未被篡改；因此，安全加密是从安全身份验证启动的。
Using False Start interferes with this approach of bootstrapping secure encryption from secure authentication, as application data may have already been sent before Finished validation confirms that the handshake has not been tampered with -- so there is generally no way to be sure that communication with the expected peer is indeed taking place during the False Start. Instead, the security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, it must be the legitimate peer. While an attacker could be influencing the handshake (restricting cipher suite selection, modifying key exchange messages, etc.), the attacker should not be able to benefit from this. The TLS protocol already relies on such a security property for authentication; with False Start, the same is needed for encryption. This motivates the rules put forth in the following subsections.
使用假启动会干扰这种从安全身份验证引导安全加密的方法，由于在完成验证确认握手未被篡改之前，可能已经发送了应用程序数据，因此通常无法确保在错误启动期间确实发生了与预期对等方的通信。取而代之的是，安全目标是确保如果任何人都可以解密在错误启动中发送的应用程序数据，那么它必须是合法的对等方。虽然攻击者可能会影响握手（限制密码套件选择、修改密钥交换消息等），但攻击者不应该从中获益。TLS协议已经依赖于这样的安全属性进行身份验证；如果启动错误，加密也需要相同的启动。这推动了以下小节中提出的规则。
It is prudent for applications to be even more restrictive. If heuristically a small list of cipher suites and a single protocol version is found to be sufficient for the majority of TLS handshakes in practice, it could make sense to forego False Start for any handshake that does not match this expected pattern, even if there is no concrete reason to assume a cryptographic weakness. Similarly, if handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman (ECDH) over one of a few named curves, it could make sense to disallow False Start with any other supported curve.
谨慎的做法是，对申请施加更严格的限制。如果试探性地发现一个小的密码套件列表和一个协议版本在实践中足以满足大多数TLS握手，那么放弃任何与预期模式不匹配的握手的错误启动可能是有意义的，即使没有具体理由假设密码弱点。类似地，如果握手几乎总是在几个命名曲线中的一条上使用短暂的椭圆曲线Diffie-Hellman（ECDH），那么禁止使用任何其他受支持的曲线进行错误启动可能是有意义的。
Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a symmetric cipher that is considered cryptographically strong.
客户端不得在握手中使用False Start协议修改，除非密码套件使用被视为密码学强的对称密码。
Implementations may have their own classification of ciphers (and may additionally allow the application layer to provide a classification), but generally only symmetric ciphers with an effective key length of 128 bits or more can be considered strong. Also, various ciphers specified for use with TLS are known to have cryptographic weaknesses regardless of key length (none of the ciphers specified in [RFC4492] and [RFC5246] can be recommended for use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 ciphers specified in [RFC5288] and [RFC5289] can be considered sufficiently strong for most uses. Implementations that support additional cipher suites have to be careful to whitelist only suitable symmetric ciphers; if in doubt, False Start should not be used with a given symmetric cipher.
实现可能有自己的密码分类（并且可能另外允许应用层提供分类），但是通常只有有效密钥长度为128位或更多的对称密码可以被认为是强的。此外，无论密钥长度如何，指定用于TLS的各种密码都存在密码弱点（不建议将[RFC4492]和[RFC5246]中指定的密码用于假启动）。[RFC5288]和[RFC5289]中规定的AES_128_GCM_SHA256或AES_256_GCM_SHA384密码对于大多数用途来说是足够强大的。支持附加密码套件的实现必须小心，只将合适的对称密码列入白名单；如果有疑问，则不应将假开始与给定的对称密码一起使用。
While an attacker can change handshake messages to force a downgrade to a less secure symmetric cipher than otherwise would have been chosen, this rule ensures that in such a downgrade attack, no application data will be sent under an insecure symmetric cipher.
虽然攻击者可以更改握手消息以强制降级为不安全的对称密码，但此规则可确保在此类降级攻击中，不会以不安全的对称密码发送任何应用程序数据。
Clients MUST NOT use the False Start protocol modification in a handshake unless the protocol version chosen by ServerHello.server_version has been whitelisted for this use.
客户端不得在握手中使用假启动协议修改，除非ServerHello.server\u version选择的协议版本已被列入此用途的白名单。
Generally, to avoid potential protocol downgrade attacks, implementations should whitelist only their latest (highest-valued) supported TLS protocol version (and, if applicable, any earlier protocol versions that they would use in fallback retries without TLS_FALLBACK_SCSV [RFC7507]).
通常，为避免潜在的协议降级攻击，实现应仅将其最新（最高值）支持的TLS协议版本（以及在不使用TLS_fallback_SCSV[RFC7507]的情况下在回退重试中使用的任何早期协议版本）列入白名单。
The details of nominally identical cipher suites can differ between protocol versions, so this reinforces Section 5.1.
名义上相同的密码套件的细节在协议版本之间可能有所不同，因此这加强了第5.1节。
Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a key exchange method that has been whitelisted for this use. Also, clients MUST NOT use the False Start protocol modification unless any parameters to the key exchange methods (such as ServerDHParams or ServerECDHParams) have been whitelisted for this use. Furthermore, when using client authentication, clients MUST NOT use the False Start protocol modification unless the client certificate type has been whitelisted for this use.
客户端不得在握手中使用假启动协议修改，除非密码套件使用的密钥交换方法已被列入此用途的白名单。此外，除非密钥交换方法的任何参数（如ServerDHParams或ServerECDHParams）已被列入此用途的白名单，否则客户端不得使用假启动协议修改。此外，在使用客户端身份验证时，客户端不得使用假启动协议修改，除非客户端证书类型已被列入此用途的白名单。
Implementations may have their own whitelists of key exchange methods, parameters, and client certificate types (and may additionally allow the application layer to specify whitelists). Generally, out of the options from [RFC5246] and [RFC4492], the following whitelists are recommended:
实现可能有自己的密钥交换方法、参数和客户端证书类型的白名单（还可能允许应用层指定白名单）。通常，在[RFC5246]和[RFC4492]的选项中，建议使用以下白名单：
o Key exchange methods: DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA
o 密钥交换方法：DHE_RSA、ECDHE_RSA、DHE_DSS、ECDHE_ECDSA
o Parameters: well-known DH groups (at least 3,072 bits), named curves (at least 256 bits)
o 参数：知名DH组（至少3072位）、命名曲线（至少256位）
o Client certificate types: none
o 客户端证书类型：无
However, if an implementation that supports only key exchange methods from [RFC5246] and [RFC4492] does not support any of the above key exchange methods, all of its supported key exchange methods can be
但是，如果仅支持[RFC5246]和[RFC4492]中的密钥交换方法的实现不支持上述任何密钥交换方法，则其支持的所有密钥交换方法都可以被删除
whitelisted for False Start use. Care is required with any additional key exchange methods, as these may not have similar properties.
错误启动使用的白名单。需要注意任何其他密钥交换方法，因为这些方法可能没有类似的属性。
The recommended whitelists are such that if cryptographic algorithms suitable for forward secrecy would possibly be negotiated, no False Start will take place if the current handshake fails to provide forward secrecy. (Forward secrecy can be achieved using ephemeral Diffie-Hellman or ephemeral Elliptic Curve Diffie-Hellman; there is no forward secrecy when using a key exchange method of RSA, RSA_PSK, DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) As usual, the benefits of forward secrecy may need to be balanced against efficiency, and accordingly, even implementations that support the above key exchange methods might whitelist further key exchange methods and client certificate types.
建议的白名单是这样的：如果可能协商适合前向保密的加密算法，那么如果当前握手无法提供前向保密，则不会发生错误启动。（前向保密性可通过使用瞬时Diffie-Hellman或瞬时椭圆曲线Diffie-Hellman实现；使用RSA、RSA_PSK、DH_DSS、DH_RSA、ECDH_ECDSA或ECDH_RSA的密钥交换方法，或RSA_fixed_DH、DSS_fixed_DH、RSA_fixed_ECDH或ECDSA_fixed_ECDH的客户端证书类型实现。）一如既往，前向保密的好处可能需要与效率相平衡，因此，即使支持上述密钥交换方法的实现也可能将进一步的密钥交换方法和客户端证书类型列入白名单。
Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow forward security, but using False Start with any of these means sending application data tied to the client's signature before the server's authenticity (and thus the CertificateRequest message) has been completely verified, so these too are not generally suitable for the client certificate type whitelist.
客户端证书类型rsa_-sign、dss_-sign和ecdsa_-sign确实允许前向安全性，但在服务器的真实性（以及由此产生的CertificateRequest消息）得到完全验证之前，使用这些类型中的任何一种都意味着发送与客户端签名相关的应用程序数据，因此，这些也通常不适用于客户端证书类型白名单。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288]Salowey，J.，Choudhury，A.，和D.McGrew，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，RFC 5288，DOI 10.17487/RFC5288，2008年8月<http://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.
[RFC5289]Rescorla，E.“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，DOI 10.17487/RFC5289，2008年8月<http://www.rfc-editor.org/info/rfc5289>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<http://www.rfc-editor.org/info/rfc7413>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <http://www.rfc-editor.org/info/rfc7507>.
[RFC7507]Moeller，B.和A.Langley，“用于防止协议降级攻击的TLS回退信令密码套件值（SCSV）”，RFC 7507，DOI 10.17487/RFC7507，2015年4月<http://www.rfc-editor.org/info/rfc7507>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-14, July 2016.
[TLS13]Rescorla，E.“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-TLS13-14，2016年7月。
TLS False Start is a modification to the TLS protocol, and some implementations that conform to [RFC5246] may have problems interacting with implementations that use the False Start modification. If the peer uses a False Start, application data records may be received directly following the peer's Finished message, before the TLS implementation has sent its own Finished message. False Start compatibility as defined in Section 3 ensures that these records with application data will simply remain buffered for later processing.
TLS假启动是对TLS协议的修改，一些符合[RFC5246]的实现可能在与使用假启动修改的实现交互时出现问题。如果对等方使用错误启动，则在TLS实现发送其自己的完成消息之前，应用程序数据记录可能直接在对等方的完成消息之后接收。第3节中定义的假启动兼容性可确保这些记录与应用程序数据保持缓冲，以供以后处理。
A False Start compatible TLS implementation does not have to be aware of the False Start concept and is certainly not expected to detect whether a False Start handshake is currently taking place: thanks to transport layer buffering, typical implementations will be False Start compatible without having been designed for it.
与假启动兼容的TLS实现不必知道假启动的概念，并且肯定不会检测当前是否发生了假启动握手：由于传输层缓冲，典型的实现将与假启动兼容，而不必为此进行设计。
Acknowledgments
致谢
The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson, Eric Rescorla, and Brian Smith for their input.
作者要感谢万德昌、本·劳里、马丁·汤姆森、埃里克·雷科拉和布赖恩·史密斯的投入。
Authors' Addresses
作者地址
Adam Langley Google Inc. 345 Spear St San Francisco, CA 94105 United States of America
亚当兰利谷歌公司345矛ST旧金山，CA 94105美利坚合众国
Email: agl@google.com
Email: agl@google.com
Nagendra Modadugu Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Nagendra Modadugu谷歌公司，1600圆形剧场公园路山景，加利福尼亚州94043美利坚合众国
Email: nagendra@cs.stanford.edu
Email: nagendra@cs.stanford.edu
Bodo Moeller Google Switzerland GmbH Brandschenkestrasse 110 Zurich 8002 Switzerland
Bodo Moeller谷歌瑞士有限公司Brandschenkestrase 110苏黎世8002瑞士
Email: bmoeller@acm.org
Email: bmoeller@acm.org