Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 5746 RTFM, Inc.
Updates: 5246, 4366, 4347, 4346, 2246 M. Ray
Category: Standards Track S. Dispensa
ISSN: 2070-1721 PhoneFactor
N. Oskov
Microsoft
February 2010
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 5746 RTFM, Inc.
Updates: 5246, 4366, 4347, 4346, 2246 M. Ray
Category: Standards Track S. Dispensa
ISSN: 2070-1721 PhoneFactor
N. Oskov
Microsoft
February 2010
Transport Layer Security (TLS) Renegotiation Indication Extension
传输层安全（TLS）重新协商指示扩展
Abstract
摘要
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.
安全套接字层（SSL）和传输层安全性（TLS）重新协商容易受到攻击，在这种攻击中，攻击者与目标服务器形成TLS连接，注入其选择的内容，然后从客户端拼接新的TLS连接。服务器将客户端的初始TLS握手视为重新协商，因此认为攻击者传输的初始数据与后续客户端数据来自同一实体。本规范定义了一个TLS扩展，以加密方式将重新协商绑定到正在执行的TLS连接，从而防止此攻击。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc5746.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5746.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 ....................................................3
2. Conventions Used in This Document ...............................4
3. Secure Renegotiation Definition .................................4
3.1. Additional Connection State ................................4
3.2. Extension Definition .......................................5
3.3. Renegotiation Protection Request Signaling Cipher
Suite Value ................................................6
3.4. Client Behavior: Initial Handshake .........................6
3.5. Client Behavior: Secure Renegotiation ......................7
3.6. Server Behavior: Initial Handshake .........................7
3.7. Server Behavior: Secure Renegotiation ......................8
4. Backward Compatibility ..........................................9
4.1. Client Considerations ......................................9
4.2. Client Behavior: Legacy (Insecure) Renegotiation ..........10
4.3. Server Considerations .....................................10
4.4. Server Behavior: Legacy (Insecure) Renegotiation ..........11
4.5. SSLv3 .....................................................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Secure Renegotiation Definition .................................4
3.1. Additional Connection State ................................4
3.2. Extension Definition .......................................5
3.3. Renegotiation Protection Request Signaling Cipher
Suite Value ................................................6
3.4. Client Behavior: Initial Handshake .........................6
3.5. Client Behavior: Secure Renegotiation ......................7
3.6. Server Behavior: Initial Handshake .........................7
3.7. Server Behavior: Secure Renegotiation ......................8
4. Backward Compatibility ..........................................9
4.1. Client Considerations ......................................9
4.2. Client Behavior: Legacy (Insecure) Renegotiation ..........10
4.3. Server Considerations .....................................10
4.4. Server Behavior: Legacy (Insecure) Renegotiation ..........11
4.5. SSLv3 .....................................................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
TLS [RFC5246] allows either the client or the server to initiate renegotiation -- a new handshake that establishes new cryptographic parameters. Unfortunately, although the new handshake is carried out using the cryptographic parameters established by the original handshake, there is no cryptographic binding between the two. This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server. One form of this attack [Ray09] proceeds as shown below:
TLS[RFC5246]允许客户端或服务器启动重新协商——建立新密码参数的新握手。不幸的是，尽管新的握手是使用原始握手所建立的密码参数执行的，但两者之间没有密码绑定。这就为攻击者提供了攻击机会，在这种攻击中，能够拦截客户端传输层连接的攻击者可以将自己的流量作为前缀注入客户端与服务器的交互。此攻击的一种形式[Ray09]如下所示：
Client Attacker Server
------ ------- ------
<----------- Handshake ---------->
<======= Initial Traffic ========>
<-------------------------- Handshake ============================>
<======================== Client Traffic ==========================>
Client Attacker Server
------ ------- ------
<----------- Handshake ---------->
<======= Initial Traffic ========>
<-------------------------- Handshake ============================>
<======================== Client Traffic ==========================>
To start the attack, the attacker forms a TLS connection to the server (perhaps in response to an initial intercepted connection from the client). He then sends any traffic of his choice to the server. This may involve multiple requests and responses at the application layer, or may simply be a partial application layer request intended to prefix the client's data. This traffic is shown with == to indicate it is encrypted. He then allows the client's TLS handshake to proceed with the server. The handshake is in the clear to the attacker but encrypted over the attacker's TLS connection to the server. Once the handshake has completed, the client communicates with the server over the newly established security parameters with the server. The attacker cannot read this traffic, but the server believes that the initial traffic to and from the attacker is the same as that to and from the client.
为了启动攻击，攻击者与服务器建立TLS连接（可能是为了响应从客户端截获的初始连接）。然后，他将自己选择的任何流量发送到服务器。这可能涉及应用层的多个请求和响应，或者可能只是一个部分应用层请求，用于为客户机的数据添加前缀。此通信量以==显示，表示已加密。然后，他允许客户端与服务器进行TLS握手。握手对攻击者来说是透明的，但通过攻击者与服务器的TLS连接进行加密。握手完成后，客户机通过新建立的安全参数与服务器通信。攻击者无法读取此流量，但服务器认为，与攻击者之间的初始流量与与与客户端之间的初始流量相同。
If certificate-based client authentication is used, the server will see a stream of bytes where the initial bytes are protected but unauthenticated by TLS and subsequent bytes are authenticated by TLS and bound to the client's certificate. In some protocols (notably HTTPS), no distinction is made between pre- and post-authentication stages and the bytes are handled uniformly, resulting in the server believing that the initial traffic corresponds to the authenticated client identity. Even without certificate-based authentication, a variety of attacks may be possible in which the attacker convinces the server to accept data from it as data from the client. For instance, if HTTPS [RFC2818] is in use with HTTP cookies [RFC2965], the attacker may be able to generate a request of his choice validated by the client's cookie.
如果使用基于证书的客户端身份验证，服务器将看到一个字节流，其中初始字节受保护但未经TLS验证，后续字节由TLS验证并绑定到客户端的证书。在某些协议（尤其是HTTPS）中，在认证前和认证后阶段之间没有区别，字节的处理是统一的，这导致服务器认为初始通信量对应于经过认证的客户端身份。即使没有基于证书的身份验证，也可能发生各种攻击，其中攻击者会说服服务器接受来自服务器的数据作为来自客户端的数据。例如，如果HTTPS[RFC2818]与HTTP cookie[RFC2965]一起使用，则攻击者可能能够生成由客户端cookie验证的自己选择的请求。
Some protocols -- such as IMAP or SMTP -- have more explicit transitions between authenticated and unauthenticated phases and require that the protocol state machine be partly or fully reset at such transitions. If strictly followed, these rules may limit the effect of attacks. Unfortunately, there is no requirement for state machine resets at TLS renegotiation, and thus there is still a potential window of vulnerability, for instance, by prefixing a command that writes to an area visible by the attacker with a command by the client that includes his password, thus making the client's password visible to the attacker (note that this precise attack does not work with challenge-response authentication schemes, but other attacks may be possible). Similar attacks are available with SMTP, and in fact do not necessarily require the attacker to have an account on the target server.
某些协议（如IMAP或SMTP）在经过身份验证和未经身份验证的阶段之间有更明确的转换，并要求在此类转换时部分或完全重置协议状态机。如果严格遵守，这些规则可能会限制攻击的效果。不幸的是，不需要在TLS重新协商时重置状态机，因此仍然存在潜在的漏洞窗口，例如，通过在写入攻击者可见区域的命令前加上客户端包含其密码的命令，从而使攻击者可见客户端密码（请注意，这种精确的攻击不适用于质询-响应身份验证方案，但也可能存在其他攻击）。SMTP也有类似的攻击，事实上并不一定要求攻击者在目标服务器上拥有帐户。
It is important to note that in both cases these attacks are possible because the client sends unsolicited authentication information without requiring any specific data from the server over the TLS connection. Protocols that require a round trip to the server over TLS before the client sends sensitive information are likely to be less vulnerable.
需要注意的是，在这两种情况下都可能发生这些攻击，因为客户端发送未经请求的身份验证信息，而不需要通过TLS连接从服务器发送任何特定数据。在客户端发送敏感信息之前，需要通过TLS往返服务器的协议可能不那么容易受到攻击。
These attacks can be prevented by cryptographically binding renegotiation handshakes to the enclosing TLS cryptographic parameters, thus allowing the server to differentiate renegotiation from initial negotiation, as well as preventing renegotiations from being spliced in between connections. An attempt by an attacker to inject himself as described above will result in a mismatch of the cryptographic binding and can thus be detected. The data used in the extension is similar to, but not the same as, the data used in the tls-unique and/or tls-unique-for-telnet channel bindings described in [TLS-CHANNEL-BINDINGS]; however, this extension is not a general-purpose RFC 5056 [RFC5056] channel binding facility.
可以通过将重新协商握手以加密方式绑定到所包含的TLS加密参数来防止这些攻击，从而允许服务器区分重新协商和初始协商，并防止重新协商在连接之间拼接。攻击者尝试如上所述注入自己将导致加密绑定不匹配，因此可以检测到。扩展中使用的数据与[tls-channel-bindings]中描述的tls unique和/或tls unique中用于telnet通道绑定的数据相似，但不相同；但是，此扩展不是通用RFC 5056[RFC5056]通道绑定设施。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Both client and server need to store three additional values for each TLS connection state (see RFC 5246, Section 6.1). Note that these values are specific to connection (not a TLS session cache entry).
客户机和服务器都需要为每个TLS连接状态存储三个附加值（参见RFC 5246，第6.1节）。请注意，这些值特定于连接（而不是TLS会话缓存条目）。
o a "secure_renegotiation" flag, indicating whether secure renegotiation is in use for this connection.
o “安全重新协商”标志，指示此连接是否正在使用安全重新协商。
o "client_verify_data": the verify_data from the Finished message sent by the client on the immediately previous handshake. For currently defined TLS versions and cipher suites, this will be a 12-byte value; for SSLv3, this will be a 36-byte value.
o “客户端验证数据”：客户端在上一次握手时发送的已完成消息中的验证数据。对于当前定义的TLS版本和密码套件，这将是一个12字节的值；对于SSLv3，这将是一个36字节的值。
o "server_verify_data": the verify_data from the Finished message sent by the server on the immediately previous handshake.
o “服务器验证数据”：服务器在上一次握手时发送的已完成消息中的验证数据。
This document defines a new TLS extension, "renegotiation_info" (with extension type 0xff01), which contains a cryptographic binding to the enclosing TLS connection (if any) for which the renegotiation is being performed. The "extension data" field of this extension contains a "RenegotiationInfo" structure:
本文档定义了一个新的TLS扩展名“renegotiation_info”（扩展名类型为0xff01），该扩展名包含与正在执行重新协商的封闭TLS连接（如果有）的加密绑定。此扩展的“扩展数据”字段包含“重新协商信息”结构：
struct {
opaque renegotiated_connection<0..255>;
} RenegotiationInfo;
struct {
opaque renegotiated_connection<0..255>;
} RenegotiationInfo;
The contents of this extension are specified as follows.
此扩展的内容指定如下。
o If this is the initial handshake for a connection, then the "renegotiated_connection" field is of zero length in both the ClientHello and the ServerHello. Thus, the entire encoding of the extension is ff 01 00 01 00. The first two octets represent the extension type, the third and fourth octets the length of the extension itself, and the final octet the zero length byte for the "renegotiated_connection" field.
o 如果这是连接的初始握手，则ClientHello和ServerHello中的“重新协商的_连接”字段长度均为零。因此，扩展的整个编码是ff 01 00。前两个八位字节表示扩展类型，第三和第四个八位字节表示扩展本身的长度，最后一个八位字节表示“重新协商的_连接”字段的零长度字节。
o For ClientHellos that are renegotiating, this field contains the "client_verify_data" specified in Section 3.1.
o 对于正在重新协商的客户机，此字段包含第3.1节中指定的“客户机验证数据”。
o For ServerHellos that are renegotiating, this field contains the concatenation of client_verify_data and server_verify_data. For current versions of TLS, this will be a 24-byte value (for SSLv3, it will be a 72-byte value).
o 对于正在重新协商的ServerHello，此字段包含客户端\u验证\u数据和服务器\u验证\u数据的串联。对于当前版本的TLS，这将是一个24字节的值（对于SSLv3，这将是一个72字节的值）。
This extension also can be used with Datagram TLS (DTLS) [RFC4347]. Although, for editorial simplicity, this document refers to TLS, all requirements in this document apply equally to DTLS.
此扩展还可用于数据报TLS（DTL）[RFC4347]。尽管为便于编辑，本文件引用了TLS，但本文件中的所有要求同样适用于DTL。
Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. Instead, it has the same semantics as an empty "renegotiation_info" extension, as described in the following sections. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of [RFC5246]).
SSLv3和TLS 1.0/TLS 1.1规范都要求实现忽略ClientHello之后的数据（即扩展），如果它们不理解这些数据。但是，在这种情况下，一些SSLv3和TLS1.0实现错误地使握手失败。这意味着提供“重新协商信息”扩展的客户端可能会遇到握手失败。为了增强与此类服务器的兼容性，本文档通过特殊信令密码套件值（SCSV）“TLS_EMPTY_RENEGOTIATION_INFO_SCSV”定义了第二种信令机制，代码点为{0x00，0xFF}。此SCSV不是真正的密码套件（它不对应于任何有效的算法集），无法协商。相反，它与空的“重新协商信息”扩展具有相同的语义，如以下部分所述。由于SSLv3和TLS实现可靠地忽略未知密码套件，因此可以将SCSV安全地发送到任何服务器。SCSV也可以包含在SSLv2向后兼容客户端HELLO中（参见[RFC5246]的附录E.2）。
Note: a minimal client that does not support renegotiation at all can simply use the SCSV in all initial handshakes. The rules in the following sections will cause any compliant server to abort the handshake when it sees an apparent attempt at renegotiation by such a client.
注意：根本不支持重新协商的最小客户机可以在所有初始握手中简单地使用SCSV。以下部分中的规则将导致任何兼容服务器在看到此类客户端明显试图重新协商时中止握手。
Note that this section and Section 3.5 apply to both full handshakes and session resumption handshakes.
请注意，本节和第3.5节适用于完全握手和会话恢复握手。
o The client MUST include either an empty "renegotiation_info" extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value in the ClientHello. Including both is NOT RECOMMENDED.
o 客户端必须在ClientHello中包含空的“重新协商信息”扩展名，或TLS_empty_重新协商信息SCSV信令密码套件值。不建议将两者都包括在内。
o When a ServerHello is received, the client MUST check if it includes the "renegotiation_info" extension:
o 收到ServerHello后，客户端必须检查它是否包含“重新协商信息”扩展名：
* If the extension is not present, the server does not support secure renegotiation; set secure_renegotiation flag to FALSE. In this case, some clients may want to terminate the handshake instead of continuing; see Section 4.1 for discussion.
* 如果扩展不存在，则服务器不支持安全重新协商；将安全重新协商标志设置为FALSE。在这种情况下，一些客户端可能希望终止握手而不是继续握手；有关讨论，请参见第4.1节。
* If the extension is present, set the secure_renegotiation flag to TRUE. The client MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake (by sending a fatal handshake_failure alert).
* 如果存在扩展，请将安全重新协商标志设置为TRUE。然后，客户端必须验证“重新协商的连接”字段的长度是否为零，如果不是，则必须中止握手（通过发送致命握手失败警报）。
Note: later in Section 3, "abort the handshake" is used as shorthand for "send a fatal handshake_failure alert and terminate the connection".
注意：在第3节后面，“中止握手”用作“发送致命握手失败警报并终止连接”的简写。
o When the handshake has completed, the client needs to save the client_verify_data and server_verify_data values for future use.
o 握手完成后，客户端需要保存客户端验证数据和服务器验证数据值，以备将来使用。
This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.2).
如果连接的“安全重新协商”标志设置为TRUE（如果设置为FALSE，请参阅第4.2节），则此文本适用。
o The client MUST include the "renegotiation_info" extension in the ClientHello, containing the saved client_verify_data. The SCSV MUST NOT be included.
o 客户端必须在ClientHello中包含“重新协商信息”扩展，该扩展包含保存的客户端验证数据。不得包括SCSV。
o When a ServerHello is received, the client MUST verify that the "renegotiation_info" extension is present; if it is not, the client MUST abort the handshake.
o 当收到ServerHello时，客户端必须验证“重新协商信息”扩展是否存在；如果不是，客户端必须中止握手。
o The client MUST then verify that the first half of the "renegotiated_connection" field is equal to the saved client_verify_data value, and the second half is equal to the saved server_verify_data value. If they are not, the client MUST abort the handshake.
o 然后，客户端必须验证“重新协商的连接”字段的前半部分是否等于保存的客户端验证数据值，以及后半部分是否等于保存的服务器验证数据值。如果没有，客户端必须中止握手。
o When the handshake has completed, the client needs to save the new client_verify_data and server_verify_data values.
o 握手完成后，客户端需要保存新的客户端验证数据和服务器验证数据值。
Note that this section and Section 3.7 apply to both full handshakes and session-resumption handshakes.
请注意，本节和第3.7节适用于完全握手和会话恢复握手。
o When a ClientHello is received, the server MUST check if it includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, set the secure_renegotiation flag to TRUE.
o 当收到ClientHello时，服务器必须检查它是否包含TLS\u EMPTY\u RENEGOTIATION\u INFO\u SCSV SCSV。如果是，请将secure_重新协商标志设置为TRUE。
o The server MUST check if the "renegotiation_info" extension is included in the ClientHello. If the extension is present, set secure_renegotiation flag to TRUE. The server MUST then verify that the length of the "renegotiated_connection" field is zero, and if it is not, MUST abort the handshake.
o 服务器必须检查ClientHello中是否包含“重新协商信息”扩展。如果存在扩展，请将secure_renegotiation标志设置为TRUE。然后，服务器必须验证“重新协商的_连接”字段的长度是否为零，如果不是，则必须中止握手。
o If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the "renegotiation_info" extension was included, set the secure_renegotiation flag to FALSE. In this case, some servers may want to terminate the handshake instead of continuing; see Section 4.3 for discussion.
o 如果既不包括TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV，也不包括“RENEGOTIATION_INFO”扩展，请将secure_RENEGOTIATION标志设置为FALSE。在这种情况下，一些服务器可能希望终止握手而不是继续握手；有关讨论，请参见第4.3节。
o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message.
o 如果安全重新协商标志设置为TRUE，则服务器必须在ServerHello消息中包含空的“重新协商信息”扩展名。
o When the handshake has completed, the server needs to save the client_verify_data and server_verify_data values for future use.
o 握手完成后，服务器需要保存客户端验证数据和服务器验证数据值，以备将来使用。
TLS servers implementing this specification MUST ignore any unknown extensions offered by the client and they MUST accept version numbers higher than their highest version number and negotiate the highest common version. These two requirements reiterate preexisting requirements in RFC 5246 and are merely stated here in the interest of forward compatibility.
实现此规范的TLS服务器必须忽略客户端提供的任何未知扩展，并且必须接受高于其最高版本号的版本号，并协商最高通用版本。这两项要求重申了RFC 5246中先前存在的要求，此处仅出于前向兼容性的考虑进行说明。
Note that sending a "renegotiation_info" extension in response to a ClientHello containing only the SCSV is an explicit exception to the prohibition in RFC 5246, Section 7.4.1.4, on the server sending unsolicited extensions and is only allowed because the client is signaling its willingness to receive the extension via the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST continue to comply with Section 7.4.1.4 for all other extensions.
请注意，发送“重新协商信息”扩展以响应仅包含SCSV的ClientHello是RFC 5246第7.4.1.4节中禁止的明确例外，在服务器上发送未经请求的扩展，仅当客户端通过TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV表示愿意接收扩展时才允许。对于所有其他扩展，TLS实施必须继续遵守第7.4.1.4节。
This text applies if the connection's "secure_renegotiation" flag is set to TRUE (if it is set to FALSE, see Section 4.4).
如果连接的“安全重新协商”标志设置为TRUE（如果设置为FALSE，请参阅第4.4节），则此文本适用。
o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.
o 当收到ClientHello时，服务器必须验证它不包含TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV。如果存在SCSV，服务器必须中止握手。
o The server MUST verify that the "renegotiation_info" extension is present; if it is not, the server MUST abort the handshake.
o 服务器必须验证“重新协商信息”扩展是否存在；如果不是，服务器必须中止握手。
o The server MUST verify that the value of the "renegotiated_connection" field is equal to the saved client_verify_data value; if it is not, the server MUST abort the handshake.
o 服务器必须验证“重新协商的\u连接”字段的值是否等于保存的客户端\u验证\u数据值；如果不是，服务器必须中止握手。
o The server MUST include a "renegotiation_info" extension containing the saved client_verify_data and server_verify_data in the ServerHello.
o 服务器必须包含“重新协商信息”扩展，该扩展包含服务器Hello中保存的客户端验证数据和服务器验证数据。
o When the handshake has completed, the server needs to save the new client_verify_data and server_verify_data values.
o 握手完成后，服务器需要保存新的客户端验证数据和服务器验证数据值。
Existing implementations that do not support this extension are widely deployed and, in general, must interoperate with newer implementations that do support it. This section describes considerations for backward compatible interoperation.
不支持此扩展的现有实现被广泛部署，并且通常必须与支持此扩展的新实现进行互操作。本节介绍向后兼容互操作的注意事项。
If a client offers the "renegotiation_info" extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply with "renegotiation_info" in the ServerHello, then this indicates that the server does not support secure renegotiation. Because some attacks (see Section 1) look like a single handshake to the client, the client cannot determine whether or not the connection is under attack. Note, however, that merely because the server does not acknowledge the extension does not mean that it is vulnerable; it might choose to reject all renegotiations and simply not signal it. However, it is not possible for the client to determine purely via TLS mechanisms whether or not this is the case.
如果客户端提供了“重新协商信息”扩展或TLS_EMPTY_renegotiation_info_SCSV SCSV，而服务器在ServerHello中没有使用“renegotiation_info”进行回复，则表示服务器不支持安全重新协商。由于某些攻击（参见第1节）看起来像是与客户端的一次握手，因此客户端无法确定连接是否受到攻击。但是，请注意，仅仅因为服务器不确认扩展，并不意味着它易受攻击；它可能选择拒绝所有重新谈判，而只是不发出信号。但是，客户机不可能纯粹通过TLS机制来确定是否存在这种情况。
If clients wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to receive the extension without completing the handshake. Such clients MUST generate a fatal "handshake_failure" alert prior to terminating the connection. However, it is expected that many TLS servers that do not support renegotiation (and thus are not vulnerable) will not support this extension either, so in general, clients that implement this behavior will encounter interoperability problems. There is no set of client behaviors that will guarantee security and achieve maximum interoperability during the transition period. Clients need to choose one or the other preference when dealing with potentially un-upgraded servers.
如果客户端希望确保此类攻击不可能发生，则需要在没有完成握手的情况下接收扩展失败后立即终止连接。此类客户端必须在终止连接之前生成致命的“握手失败”警报。但是，预计许多不支持重新协商（因此不易受攻击）的TLS服务器也不会支持此扩展，因此一般来说，实现此行为的客户端将遇到互操作性问题。在过渡期间，没有一组客户端行为可以保证安全性并实现最大的互操作性。在处理可能未升级的服务器时，客户端需要选择一个或另一个首选项。
This text applies if the connection's "secure_renegotiation" flag is set to FALSE.
如果连接的“安全重新协商”标志设置为FALSE，则此文本适用。
It is possible that un-upgraded servers will request that the client renegotiate. It is RECOMMENDED that clients refuse this renegotiation request. Clients that do so MUST respond to such requests with a "no_renegotiation" alert (RFC 5246 requires this alert to be at the "warning" level). It is possible that the apparently un-upgraded server is in fact an attacker who is then allowing the client to renegotiate with a different, legitimate, upgraded server. If clients nevertheless choose to renegotiate, they MUST behave as described below.
未升级的服务器可能会请求客户端重新协商。建议客户拒绝此重新协商请求。这样做的客户端必须以“无重新协商”警报响应此类请求（RFC 5246要求此警报处于“警告”级别）。显然未升级的服务器可能实际上是一个攻击者，该攻击者随后允许客户端与另一个合法的升级服务器重新协商。如果客户仍然选择重新协商，他们必须按照以下所述行事。
Clients that choose to renegotiate MUST provide either the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in their ClientHello. In a legitimate renegotiation with an un-upgraded server, that server should ignore both of these signals. However, if the server (incorrectly) fails to ignore extensions, sending the "renegotiation_info" extension may cause a handshake failure. Thus, it is permitted, though NOT RECOMMENDED, for the client to simply send the SCSV. This is the only situation in which clients are permitted to not send the "renegotiation_info" extension in a ClientHello that is used for renegotiation.
选择重新协商的客户必须在其客户机中提供TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV或“RENEGOTIATION_INFO”。在与未升级服务器的合法重新协商中，该服务器应忽略这两个信号。但是，如果服务器（错误地）未能忽略扩展，则发送“重新协商信息”扩展可能会导致握手失败。因此，允许（但不建议）客户端简单地发送SCSV。这是唯一允许客户端不在用于重新协商的ClientHello中发送“重新协商信息”扩展的情况。
Note that in the case of a downgrade attack, if this is an initial handshake from the server's perspective, then use of the SCSV from the client precludes detection of this attack by the server (if this is a renegotiation from the server's perspective, then it will detect the attack). However, the attack will be detected by the client when the server sends an empty "renegotiation_info" extension and the client is expecting one containing the previous verify_data. By contrast, if the client sends the "renegotiation_info" extension, then the server will immediately detect the attack.
请注意，在降级攻击的情况下，如果从服务器的角度来看这是一次初始握手，那么从客户端使用SCSV将阻止服务器检测到该攻击（如果从服务器的角度来看这是一次重新协商，那么它将检测到该攻击）。但是，当服务器发送一个空的“重新协商信息”扩展名并且客户端希望该扩展名包含以前的验证信息数据时，客户端将检测到攻击。相反，如果客户端发送“重新协商信息”扩展，那么服务器将立即检测到攻击。
When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. (Because the server has already indicated it does not support secure renegotiation, the only way that this can happen is if the server is broken or there is an attack.)
当收到ServerHello时，客户端必须验证它不包含“重新协商信息”扩展。如果是这样，客户端必须中止握手。（因为服务器已经表示它不支持安全重新协商，所以发生这种情况的唯一方法是服务器损坏或发生攻击。）
If the client does not offer the "renegotiation_info" extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that the client does not support secure renegotiation. Although the attack described in Section 1 looks like two handshakes to the
如果客户端不提供“重新协商信息”扩展或TLS_EMPTY_重新协商信息SCSV SCSV，则表示客户端不支持安全重新协商。尽管第1节中描述的攻击看起来像是两次握手
server, other attacks may be possible in which the renegotiation is seen only by the client. If servers wish to ensure that such attacks are impossible, they need to terminate the connection immediately upon failure to negotiate the use of secure renegotiation. Servers that do choose to allow connections from unpatched clients can still prevent the attack described in Section 1 by refusing to renegotiate over those connections.
如果只有客户端才能看到重新协商，则可能会发生其他攻击。如果服务器希望确保此类攻击不可能发生，则需要在协商使用安全重新协商失败时立即终止连接。选择允许来自未修补客户端的连接的服务器仍然可以通过拒绝对这些连接重新协商来防止第1节中描述的攻击。
In order to enable clients to probe, even servers that do not support renegotiation MUST implement the minimal version of the extension described in this document for initial handshakes, thus signaling that they have been upgraded.
为了使客户端能够进行探测，即使是不支持重新协商的服务器也必须实现本文档中描述的用于初始握手的扩展的最低版本，从而表明它们已经升级。
This text applies if the connection's "secure_renegotiation" flag is set to FALSE.
如果连接的“安全重新协商”标志设置为FALSE，则此文本适用。
It is RECOMMENDED that servers not permit legacy renegotiation. If servers nevertheless do permit it, they MUST follow the requirements in this section.
建议服务器不允许旧版重新协商。如果服务器确实允许，则必须遵守本节中的要求。
o When a ClientHello is received, the server MUST verify that it does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If the SCSV is present, the server MUST abort the handshake.
o 当收到ClientHello时，服务器必须验证它不包含TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV。如果存在SCSV，服务器必须中止握手。
o The server MUST verify that the "renegotiation_info" extension is not present; if it is, the server MUST abort the handshake.
o 服务器必须验证“重新协商信息”扩展不存在；如果是，服务器必须中止握手。
While SSLv3 is not a protocol under IETF change control (see [SSLv3]), it was the original basis for TLS and most TLS implementations also support SSLv3. The IETF encourages SSLv3 implementations to adopt the "renegotiation_info" extension and SCSV as defined in this document. The semantics of the SCSV and extension are identical to TLS stacks except for the size of the verify_data values, which are 36 bytes long each. Note that this will require adding at least minimal extension processing to such stacks. Clients that support SSLv3 and offer secure renegotiation (either via SCSV or "renegotiation_info") MUST accept the "renegotiation_info" extension from the server, even if the server version is {0x03, 0x00}, and behave as described in this specification. TLS servers that support secure renegotiation and support SSLv3 MUST accept SCSV or the "renegotiation_info" extension and respond as described in this specification even if the offered client version is {0x03, 0x00}. SSLv3 does not define the "no_renegotiation" alert (and does
虽然SSLv3不是IETF变更控制下的协议（参见[SSLv3]），但它是TLS的原始基础，大多数TLS实现也支持SSLv3。IETF鼓励SSLv3实施采用本文件中定义的“重新协商信息”扩展和SCSV。SCSV和扩展的语义与TLS堆栈相同，只是verify_数据值的大小不同，每个值长36字节。请注意，这将需要向此类堆栈添加至少最小的扩展处理。支持SSLv3并提供安全重新协商（通过SCSV或“重新协商_信息”）的客户端必须接受来自服务器的“重新协商_信息”扩展，即使服务器版本为{0x03，0x00}，并且按照本规范中的描述进行操作。支持安全重新协商和支持SSLv3的TLS服务器必须接受SCSV或“重新协商信息”扩展，并按照本规范所述响应，即使提供的客户端版本为{0x03，0x00}。SSLv3没有定义“不重新协商”警报（并且
not offer a way to indicate a refusal to renegotiate at a "warning" level). SSLv3 clients that refuse renegotiation SHOULD use a fatal handshake_failure alert.
不提供表示拒绝在“警告”级别重新谈判的方式）。拒绝重新协商的SSLv3客户端应使用致命握手失败警报。
The extension described in this document prevents an attack on TLS. If this extension is not used, TLS renegotiation is subject to an attack in which the attacker can inject their own conversation with the TLS server as a prefix to the client's conversation. This attack is invisible to the client and looks like an ordinary renegotiation to the server. The extension defined in this document allows renegotiation to be performed safely. Servers SHOULD NOT allow clients to renegotiate without using this extension. Many servers can mitigate this attack simply by refusing to renegotiate at all.
本文档中描述的扩展可防止对TLS的攻击。如果不使用此扩展，TLS重新协商将受到攻击，攻击者可以将自己与TLS服务器的对话作为前缀注入客户端对话。这种攻击对于客户端是不可见的，对于服务器来说就像普通的重新协商。本文件中定义的扩展允许安全地执行重新协商。服务器不应允许客户端在不使用此扩展的情况下重新协商。许多服务器只要拒绝重新协商就可以减轻这种攻击。
While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way.
虽然此扩展减轻了概述中描述的中间人攻击，但如果应用程序不知道重新协商，则它无法解决所有可能遇到的问题。例如，在重新协商期间，客户机或服务器可以提供与先前使用的证书不同的证书。这可能会让应用程序开发人员感到惊讶（例如，他们可能预期“getPeerCertificates（）”API调用如果调用两次将返回相同的值），并且可能会以不安全的方式进行处理。
TLS implementations SHOULD provide a mechanism to disable and enable renegotiation.
TLS实现应该提供一种机制来禁用和启用重新协商。
TLS implementers are encouraged to clearly document how renegotiation interacts with the APIs offered to applications (for example, which API calls might return different values on different calls, or which callbacks might get called multiple times).
鼓励TLS实现者清楚地记录重新协商如何与提供给应用程序的API交互（例如，哪些API调用可能在不同调用上返回不同的值，或者哪些回调可能被多次调用）。
To make life simpler for applications that use renegotiation but do not expect the certificate to change once it has been authenticated, TLS implementations may also wish to offer the applications the option to abort the renegotiation if the peer tries to authenticate with a different certificate and/or different server name (in the server_name extension) than was used earlier. TLS implementations may alternatively offer the option to disable renegotiation once the client certificate has been authenticated. However, enabling these options by default for all applications could break existing applications that depend on using renegotiation to change from one certificate to another. (For example, long-lived TLS connections could change to a renewed certificate; or renegotiation could select a different cipher suite that requires using a different certificate.)
为了简化使用重新协商但不希望证书在经过身份验证后更改的应用程序的操作，TLS实现可能还希望为应用程序提供一个选项，以便在对等方尝试使用不同的证书和/或服务器名称进行身份验证时中止重新协商（在服务器名称扩展名中）TLS实现也可以提供在客户端证书经过身份验证后禁用重新协商的选项。但是，默认情况下为所有应用程序启用这些选项可能会中断依赖于使用重新协商从一个证书更改为另一个证书的现有应用程序。（例如，长期TLS连接可能会更改为更新的证书；或者重新协商可能会选择需要使用不同证书的不同密码套件。）
Finally, designers of applications that depend on renegotiation are reminded that many TLS APIs represent application data as a simple octet stream; applications may not be able to determine exactly which application data octets were received before, during, or after renegotiation. Especially if the peer presents a different certificate during renegotiation, care is needed when specifying how the application should handle the data.
最后，提醒依赖于重新协商的应用程序的设计者，许多TLSAPI将应用程序数据表示为一个简单的八位字节流；应用程序可能无法准确确定在重新协商之前、期间或之后收到了哪些应用程序数据八位字节。特别是当对等方在重新协商期间提供不同的证书时，在指定应用程序应如何处理数据时需要小心。
IANA has added the extension code point 65281 (0xff01), which has been used for prototype implementations, for the "renegotiation_info" extension to the TLS ExtensionType values registry.
IANA已将用于原型实现的扩展代码点65281（0xff01）添加到TLS ExtensionType值注册表的“重新协商信息”扩展中。
IANA has added TLS cipher suite number 0x00,0xFF with name TLS_EMPTY_RENEGOTIATION_INFO_SCSV to the TLS Cipher Suite registry.
IANA已将名为TLS_EMPTY_RENEGOTIATION_INFO_SCSV的TLS密码套件编号0x00,0xFF添加到TLS密码套件注册表中。
This vulnerability was originally discovered by Marsh Ray and independently rediscovered by Martin Rex. The general concept behind the extension described here was independently invented by Steve Dispensa, Nasko Oskov, and Eric Rescorla with refinements from Nelson Bolyard, Pasi Eronen, Michael D'Errico, Stephen Farrell, Michael Gray, David-Sarah Hopwood, Ben Laurie, David Makepeace, Bodo Moeller, Martin Rex, Peter Robinson, Jesse Walker, Nico Williams, and other members of the Project Mogul team and the TLS WG.
该漏洞最初由Marsh Ray发现，并由Martin Rex独立重新发现。这里描述的扩展背后的一般概念是由Steve Dispensa、Nasko Oskov和Eric Rescorla独立发明的，经过Nelson Bolyard、Pasi Eronen、Michael D'Errico、Stephen Farrell、Michael Gray、David Sarah Hopwood、Ben Laurie、David Makepeace、Bodo Moeller、Martin Rex、Peter Robinson、Jesse Walker、，Nico Williams，以及项目莫卧儿团队和TLS工作组的其他成员。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[TLS-CHANNEL-BINDINGS] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", Work in Progress, October 2009.
[TLS-CHANNEL-BINDINGS]Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，正在进行的工作，2009年10月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965]Kristol，D.和L.Montulli，“HTTP状态管理机制”，RFC 29652000年10月。
[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", November 2009, <http://extendedsubset.com/?p=8>.
[Ray09]Ray，M.“TLS重新谈判中的认证差距”，2009年11月<http://extendedsubset.com/?p=8>.
[SSLv3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", Work in Progress, November 1996.
[SSLv3]Freier，A.，Karlton，P.，和P.Kocher，“SSL协议版本3.0”，正在进行的工作，1996年11月。
Authors' Addresses
作者地址
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com
Marsh Ray PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA
美国堪萨斯州陆上公园129街西7301
EMail: marsh@extendedsubset.com
EMail: marsh@extendedsubset.com
Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park, KS 66213 USA
Steve Dispensa PhoneFactor 7301 W 129th Street Overland Park，KS 66213美国
EMail: dispensa@phonefactor.com
EMail: dispensa@phonefactor.com
Nasko Oskov Microsoft One Microsoft Way Redmond, WA 98052 USA
Nasko Oskov微软一路微软雷德蒙德，华盛顿州98052美国
EMail: nasko.oskov@microsoft.com
EMail: nasko.oskov@microsoft.com