Internet Engineering Task Force (IETF) K. Bhargavan, Ed.
Request for Comments: 7627 A. Delignat-Lavaud
Updates: 5246 A. Pironti
Category: Standards Track Inria Paris-Rocquencourt
ISSN: 2070-1721 A. Langley
Google Inc.
M. Ray
Microsoft Corp.
September 2015
Internet Engineering Task Force (IETF) K. Bhargavan, Ed.
Request for Comments: 7627 A. Delignat-Lavaud
Updates: 5246 A. Pironti
Category: Standards Track Inria Paris-Rocquencourt
ISSN: 2070-1721 A. Langley
Google Inc.
M. Ray
Microsoft Corp.
September 2015
Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
传输层安全（TLS）会话哈希和扩展主密钥扩展
Abstract
摘要
The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.
传输层安全性（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/rfc7627.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7627.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Requirements Notation ...........................................5
3. The TLS Session Hash ............................................5
4. The Extended Master Secret ......................................6
5. Extension Negotiation ...........................................6
5.1. Extension Definition .......................................6
5.2. Client and Server Behavior: Full Handshake .................7
5.3. Client and Server Behavior: Abbreviated Handshake ..........7
5.4. Interoperability Considerations ............................9
6. Security Considerations .........................................9
6.1. Triple Handshake Preconditions and Impact ..................9
6.2. Cryptographic Properties of the Hash Function .............11
6.3. Handshake Messages Included in the Session Hash ...........11
6.4. No SSL 3.0 Support ........................................12
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Acknowledgments ...................................................14
Authors' Addresses ................................................15
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. The TLS Session Hash ............................................5
4. The Extended Master Secret ......................................6
5. Extension Negotiation ...........................................6
5.1. Extension Definition .......................................6
5.2. Client and Server Behavior: Full Handshake .................7
5.3. Client and Server Behavior: Abbreviated Handshake ..........7
5.4. Interoperability Considerations ............................9
6. Security Considerations .........................................9
6.1. Triple Handshake Preconditions and Impact ..................9
6.2. Cryptographic Properties of the Hash Function .............11
6.3. Handshake Messages Included in the Session Hash ...........11
6.4. No SSL 3.0 Support ........................................12
7. IANA Considerations ............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................13
Acknowledgments ...................................................14
Authors' Addresses ................................................15
In TLS [RFC5246], every session has a "master_secret" computed as:
在TLS[RFC5246]中，每个会话都有一个“主密钥”，计算如下：
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
master_secret=PRF（pre_master_secret，“master secret”，ClientHello.random+ServerHello.random）[0..47]；
where the "pre_master_secret" is the result of some key exchange protocol. For example, when the handshake uses an RSA ciphersuite, this value is generated uniformly at random by the client, whereas for Ephemeral Diffie-Hellman (DHE) ciphersuites, it is the result of a Diffie-Hellman key agreement.
其中，“pre_master_secret”是某些密钥交换协议的结果。例如，当握手使用RSA密码套件时，该值由客户端统一随机生成，而对于短暂的Diffie-Hellman（DHE）密码套件，它是Diffie-Hellman密钥协议的结果。
As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same "master_secret". For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client C connects to a server A. C does not realize that A is malicious and that A connects in the background to an honest server S and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites.
如[TRIPLE-HS]中所述，在RSA和DHE密钥交换中，主动攻击者可以同步两个TLS会话，以便它们共享相同的“主密钥”。对于客户端未经身份验证的RSA密钥交换，可通过以下方式实现。假设客户机C连接到服务器a。C没有意识到a是恶意的，a在后台连接到诚实的服务器S并完成两次握手。为简单起见，假设C和S只使用RSA密码套件。
1. C sends a "ClientHello" to A, and A forwards it to S.
1. C向a发送一个“ClientHello”，a将其转发给S。
2. S sends a "ServerHello" to A, and A forwards it to C.
2. S向a发送“ServerHello”，a将其转发给C。
3. S sends a "Certificate", containing its certificate chain, to A. A replaces it with its own certificate chain and sends it to C.
3. S将包含其证书链的“证书”发送给a。a将其替换为自己的证书链并发送给C。
4. S sends a "ServerHelloDone" to A, and A forwards it to C.
4. S向a发送一个“ServerHelloDone”，a将其转发给C。
5. C sends a "ClientKeyExchange" to A, containing the "pre_master_secret", encrypted with A's public key. A decrypts the "pre_master_secret", re-encrypts it with S's public key, and sends it on to S.
5. C向a发送一个“ClientKeyExchange”，其中包含用a的公钥加密的“pre_master_secret”。A解密“pre_master_secret”，用S的公钥重新加密，然后发送给S。
6. C sends a "Finished" to A. A computes a "Finished" for its connection with S and sends it to S.
6. C向a发送一个“完成的”。a为其与S的连接计算一个“完成的”，并将其发送给S。
7. S sends a "Finished" to A. A computes a "Finished" for its connection with C and sends it to C.
7. S向a发送一个“完成的”。a为其与C的连接计算一个“完成的”，并将其发送给C。
At this point, both connections (between C and A, and between A and S) have new sessions that share the same "pre_master_secret", "ClientHello.random", "ServerHello.random", as well as other session parameters, including the session identifier and, optionally, the session ticket. Hence, the "master_secret" value will be equal for
此时，两个连接（C和A之间以及A和S之间）都有新会话，它们共享相同的“pre_master_secret”、“ClientHello.random”、“ServerHello.random”以及其他会话参数，包括会话标识符和会话票证（可选）。因此，“master_secret”值将等于
the two sessions and will be associated both at C and S with the same session ID, even though the server identities on the two connections are different. Recall that C only sees A's certificate and is unaware of A's connection with S. Moreover, the record keys on the two connections will also be the same.
尽管两个连接上的服务器标识不同，但这两个会话和将在C和S处与相同的会话ID相关联。回想一下，C只看到A的证书，不知道A与s的连接。此外，两个连接上的记录键也将相同。
The scenario above shows that TLS does not guarantee that the master secrets and keys used on different connections will be different. Even if client authentication is used, the scenario still works, except that the two sessions now differ on both client and server identities.
上面的场景表明，TLS不能保证在不同连接上使用的主机密和密钥是不同的。即使使用了客户端身份验证，该场景仍然有效，只是这两个会话现在在客户端和服务器身份上有所不同。
A similar scenario can be achieved when the handshake uses a DHE ciphersuite. Note that even if the client or server does not prefer using RSA or DHE, the attacker can force them to use it by offering only RSA or DHE in its hello messages. Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. Against more powerful adversaries, other key exchanges, such as Secure Remote Password (SRP) and Pre-Shared Key (PSK), have also been shown to be vulnerable [VERIFIED-BINDINGS].
当握手使用DHE密码套件时，也可以实现类似的场景。请注意，即使客户端或服务器不喜欢使用RSA或DHE，攻击者也可以通过在其hello消息中仅提供RSA或DHE来强制他们使用RSA或DHE。如果使用临时椭圆曲线Diffie-Hellman（ECDHE）密码套件的握手允许使用任意显式曲线或使用带有小子群的曲线，则握手也容易受到攻击。针对更强大的对手，其他密钥交换，如安全远程密码（SRP）和预共享密钥（PSK），也被证明是易受攻击的[验证绑定]。
Once A has synchronized the two connections, since the keys are the same on the two sides, it can step away and transparently forward messages between C and S, reading and modifying when it desires. In the key exchange literature, such occurrences are called unknown key-share attacks, since C and S share a secret but they both think that their secret is shared only with A. In themselves, these attacks do not break integrity or confidentiality between honest parties, but they offer a useful starting point from which to mount impersonation attacks on C and S.
一旦A同步了这两个连接，因为两边的键是相同的，所以它可以离开，在C和S之间透明地转发消息，在需要时读取和修改。在密钥交换文献中，这种情况称为未知密钥共享攻击，因为C和S共享一个秘密，但他们都认为他们的秘密只与a共享。就其本身而言，这些攻击不会破坏诚实方之间的完整性或机密性，但它们提供了一个有用的起点，可以从中对C和S发起模拟攻击。
Suppose C tries to resume its session on a new connection with A. A can then resume its session with S on a new connection and forward the abbreviated handshake messages unchanged between C and S. Since the abbreviated handshake only relies on the master secret for authentication and does not mention client or server identities, both handshakes complete successfully, resulting in the same session keys and the same handshake log. A still knows the connection keys and can send messages to both C and S.
假设C尝试在与a的新连接上恢复其会话。然后，a可以在新连接上恢复与S的会话，并在C和S之间不改变地转发缩写握手消息。由于缩写握手仅依赖于主密钥进行身份验证，而不提及客户端或服务器身份，两次握手都成功完成，从而产生相同的会话密钥和相同的握手日志。A仍然知道连接密钥，可以向C和S发送消息。
Critically, at the new connection, even the handshake log is the same on C and S, thus defeating any man-in-the-middle protection scheme that relies on the uniqueness of finished messages, such as the secure renegotiation indication extension [RFC5746] or TLS channel bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on such session synchronization attacks. In particular, it describes a man-in-the-middle attack, called the "triple handshake", that
关键的是，在新连接上，甚至握手日志在C和S上都是相同的，因此击败了任何依赖于完成消息唯一性的中间人保护方案，例如安全重新协商指示扩展[RFC5746]或TLS通道绑定[RFC5929]。[TRIPLE-HS]描述了基于此类会话同步攻击的几种攻击。特别是，它描述了一种中间人攻击，称为“三重握手”，即
circumvents the protections of [RFC5746] to break client-authenticated TLS renegotiation after session resumption. Similar attacks apply to application-level authentication mechanisms that rely on channel bindings [RFC5929] or on key material exported from TLS [RFC5705].
绕过[RFC5746]的保护，在会话恢复后中断客户端验证的TLS重新协商。类似的攻击适用于依赖通道绑定[RFC5929]或从TLS[RFC5705]导出的密钥材料的应用程序级身份验证机制。
The underlying protocol issue leading to these attacks is that the TLS master secret is not guaranteed to be unique across sessions, since it is not context-bound to the full handshake that generated it. If we fix this problem in the initial master secret computation, then all these attacks can be prevented. This specification introduces a TLS extension that changes the way the "master_secret" value is computed in a full handshake by including the log of the handshake messages, so that different sessions will, by construction, have different master secrets. This prevents the attacks described in [TRIPLE-HS] and documented in Section 2.11 of [RFC7457].
导致这些攻击的潜在协议问题是，TLS主密钥不能保证在会话中是唯一的，因为它没有上下文绑定到生成它的完整握手。如果我们在初始主秘密计算中解决了这个问题，那么所有这些攻击都可以被阻止。本规范引入了一个TLS扩展，该扩展通过包含握手消息的日志来更改在完整握手中计算“master_secret”值的方式，因此通过构造不同的会话将具有不同的主密钥。这可以防止[TRIPLE-HS]中描述的攻击，并在[RFC7457]第2.11节中记录。
This document uses the same notation and terminology used in the TLS protocol specification [RFC5246].
本文件使用TLS协议规范[RFC5246]中使用的相同符号和术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
When a full TLS handshake takes place, we define
当发生完全TLS握手时，我们定义
session_hash = Hash(handshake_messages)
会话\u散列=散列（握手\u消息）
where "handshake_messages" refers to all handshake messages sent or received, starting at the ClientHello up to and including the ClientKeyExchange message, including the type and length fields of the handshake messages. This is the concatenation of all the exchanged Handshake structures, as defined in Section 7.4 of [RFC5246].
其中，“握手_消息”指发送或接收的所有握手消息，从ClientHello开始直到ClientKeyExchange消息，包括握手消息的类型和长度字段。这是[RFC5246]第7.4节中定义的所有交换握手结构的串联。
For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 of [RFC5246] for the Finished message computation. For all previous versions of TLS, the "Hash" function computes the concatenation of MD5 and SHA1.
对于TLS 1.2，“哈希”函数是[RFC5246]第7.4.9节中为完成消息计算而定义的函数。对于TLS的所有以前版本，“Hash”函数计算MD5和SHA1的串联。
There is no "session_hash" for resumed handshakes, as they do not lead to the creation of a new session.
恢复的握手没有“会话\u散列”，因为它们不会导致创建新会话。
When the extended master secret extension is negotiated in a full handshake, the "master_secret" is computed as
当在完全握手中协商扩展主密钥扩展时，“主密钥”计算为
master_secret = PRF(pre_master_secret, "extended master secret", session_hash) [0..47];
master_secret=PRF（pre_master_secret，“扩展master secret”，会话散列）[0..47]；
The extended master secret computation differs from that described in [RFC5246] in the following ways:
扩展主秘密计算与[RFC5246]中描述的计算有以下不同：
o The "extended master secret" label is used instead of "master secret".
o 使用“扩展主密钥”标签代替“主密钥”。
o The "session_hash" is used instead of the "ClientHello.random" and "ServerHello.random".
o 使用“session_hash”代替“ClientHello.random”和“ServerHello.random”。
The "session_hash" depends upon a handshake log that includes "ClientHello.random" and "ServerHello.random", in addition to ciphersuites, key exchange information, and certificates (if any) from the client and server. Consequently, the extended master secret depends upon the choice of all these session parameters.
“session_hash”依赖于握手日志，其中包括“ClientHello.random”和“ServerHello.random”，以及来自客户端和服务器的密码套件、密钥交换信息和证书（如果有）。因此，扩展主密钥取决于所有这些会话参数的选择。
This design reflects the recommendation that keys should be bound to the security contexts that compute them [SP800-108]. The technique of mixing a hash of the key exchange messages into master key derivation is already used in other well-known protocols such as Secure Shell (SSH) [RFC4251].
这种设计反映了密钥应该绑定到计算它们的安全上下文的建议[SP800-108]。将密钥交换消息的散列混合到主密钥派生中的技术已经在其他众所周知的协议中使用，例如secureshell（SSH）[RFC4251]。
Clients and servers SHOULD NOT accept handshakes that do not use the extended master secret, especially if they rely on features like compound authentication that fall into the vulnerable cases described in Section 6.1.
客户端和服务器不应接受不使用扩展主密钥的握手，特别是如果它们依赖于复合身份验证等属于第6.1节所述的易受攻击情况的功能。
This document defines a new TLS extension, "extended_master_secret" (with extension type 0x0017), which is used to signal both client and server to use the extended master secret computation. The "extension_data" field of this extension is empty. Thus, the entire encoding of the extension is 00 17 00 00 (in hexadecimal.)
本文档定义了一个新的TLS扩展名“extended_master_secret”（扩展名类型为0x0017），用于通知客户端和服务器使用扩展的master secret计算。此扩展的“扩展数据”字段为空。因此，扩展的整个编码是00 17 00 00（十六进制）
Although this document refers only to TLS, the extension proposed here can also be used with Datagram TLS (DTLS) [RFC6347].
尽管本文档仅涉及TLS，但此处提出的扩展也可用于数据报TLS（DTL）[RFC6347]。
If the client and server agree on this extension and a full handshake takes place, both client and server MUST use the extended master secret derivation algorithm, as defined in Section 4. All other cryptographic computations remain unchanged.
如果客户机和服务器同意此扩展，并且进行了完全握手，则客户机和服务器都必须使用第4节中定义的扩展主密钥派生算法。所有其他加密计算保持不变。
In the following, we use the phrase "abort the handshake" as shorthand for terminating the handshake by sending a fatal "handshake_failure" alert.
在下文中，我们使用短语“中止握手”作为通过发送致命的“握手失败”警报来终止握手的缩写。
In all handshakes, a client implementing this document MUST send the "extended_master_secret" extension in its ClientHello.
在所有握手中，实现此文档的客户端必须在其ClientHello中发送“extended_master_secret”扩展名。
If a server implementing this document receives the "extended_master_secret" extension, it MUST include the extension in its ServerHello message.
如果实现此文档的服务器接收到“extended\u master\u secret”扩展名，则必须在其ServerHello消息中包含该扩展名。
If both the ClientHello and ServerHello contain the extension, the new session uses the extended master secret computation.
如果ClientHello和ServerHello都包含扩展，则新会话将使用扩展的主密钥计算。
If the server receives a ClientHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy clients. If it chooses to continue the handshake, then it MUST NOT include the extension in the ServerHello.
如果服务器接收到一个没有扩展名的ClientHello，如果它不希望与旧客户端交互，则应该中止握手。如果选择继续握手，则不能在ServerHello中包含扩展名。
If a client receives a ServerHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy servers.
如果客户机收到一个没有扩展名的ServerHello，如果它不希望与旧服务器交互，它应该中止握手。
If the client and server choose to continue a full handshake without the extension, they MUST use the standard master secret derivation for the new session. In this case, the new session is not protected by the mechanisms described in this document. So, implementers should follow the guidelines in Section 5.4 to avoid dangerous usage scenarios. In particular, the master secret derived from the new session should not be used for application-level authentication.
如果客户机和服务器选择在没有扩展的情况下继续完全握手，则它们必须为新会话使用标准主密钥派生。在这种情况下，新会话不受本文档中描述的机制的保护。因此，实施者应遵循第5.4节中的指南，以避免危险的使用场景。特别是，从新会话派生的主密钥不应用于应用程序级身份验证。
The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret. Instead, it SHOULD offer a full handshake.
客户端不应提供简短的握手来恢复不使用扩展主密钥的会话。相反，它应该提供完整的握手。
If the client chooses to offer an abbreviated handshake even for such sessions in order to support legacy insecure resumption, then the current connection is not protected by the mechanisms in this document. So, the client should follow the guidelines in Section 5.4
如果客户机选择为此类会话提供简短握手，以支持传统的不安全恢复，则当前连接不受本文档中机制的保护。因此，客户应遵循第5.4节中的指南
to avoid dangerous usage scenarios. In particular, renegotiation is no longer secure on this connection, even if the client and server support the renegotiation indication extension [RFC5746].
避免危险的使用场景。特别是，重新协商在此连接上不再安全，即使客户端和服务器支持重新协商指示扩展[RFC5746]。
When offering an abbreviated handshake, the client MUST send the "extended_master_secret" extension in its ClientHello.
当提供简短握手时，客户端必须在其ClientHello中发送“extended_master_secret”扩展名。
If a server receives a ClientHello for an abbreviated handshake offering to resume a known previous session, it behaves as follows:
如果服务器收到一个简短握手服务的ClientHello，以恢复已知的前一个会话，则其行为如下：
o If the original session did not use the "extended_master_secret" extension but the new ClientHello contains the extension, then the server MUST NOT perform the abbreviated handshake. Instead, it SHOULD continue with a full handshake (as described in Section 5.2) to negotiate a new session.
o 如果原始会话未使用“extended_master_secret”扩展，但新的ClientHello包含该扩展，则服务器不得执行缩写握手。相反，它应该继续进行完整的握手（如第5.2节所述），以协商新的会话。
o If the original session used the "extended_master_secret" extension but the new ClientHello does not contain it, the server MUST abort the abbreviated handshake.
o 如果原始会话使用了“extended_master_secret”扩展，但新的ClientHello不包含该扩展，则服务器必须中止缩写握手。
o If neither the original session nor the new ClientHello uses the extension, the server SHOULD abort the handshake. If it continues with an abbreviated handshake in order to support legacy insecure resumption, the connection is no longer protected by the mechanisms in this document, and the server should follow the guidelines in Section 5.4.
o 如果原始会话和新ClientHello都没有使用扩展，服务器应该中止握手。如果为了支持传统的不安全恢复而继续进行简短握手，则连接不再受本文档中的机制保护，服务器应遵循第5.4节中的指导原则。
o If the new ClientHello contains the extension and the server chooses to continue the handshake, then the server MUST include the "extended_master_secret" extension in its ServerHello message.
o 如果新的ClientHello包含扩展，并且服务器选择继续握手，那么服务器必须在其ServerHello消息中包含“extended_master_secret”扩展。
If a client receives a ServerHello that accepts an abbreviated handshake, it behaves as follows:
如果客户端接收到接受简短握手的ServerHello，则其行为如下：
o If the original session did not use the "extended_master_secret" extension but the new ServerHello contains the extension, the client MUST abort the handshake.
o 如果原始会话未使用“extended\u master\u secret”扩展，但新ServerHello包含该扩展，则客户端必须中止握手。
o If the original session used the extension but the new ServerHello does not contain the extension, the client MUST abort the handshake.
o 如果原始会话使用扩展，但新ServerHello不包含扩展，则客户端必须中止握手。
If the client and server continue the abbreviated handshake, they derive the connection keys for the new session as usual from the master secret of the original session.
如果客户机和服务器继续进行简短的握手，它们会像往常一样从原始会话的主密钥中导出新会话的连接密钥。
To allow interoperability with legacy clients and servers, a TLS peer may decide to accept full handshakes that use the legacy master secret computation. If so, they need to differentiate between sessions that use legacy and extended master secrets by adding a flag to the session state.
为了允许与遗留客户端和服务器的互操作性，TLS对等方可以决定接受使用遗留主密钥计算的完全握手。如果是这样，他们需要通过在会话状态中添加标志来区分使用传统主机密和扩展主机密的会话。
If a client or server chooses to continue with a full handshake without the extended master secret extension, then the new session becomes vulnerable to the man-in-the-middle key synchronization attack described in Section 1. Hence, the client or server MUST NOT export any key material based on the new master secret for any subsequent application-level authentication. In particular, it MUST disable [RFC5705] and any Extensible Authentication Protocol (EAP) relying on compound authentication [COMPOUND-AUTH].
如果客户端或服务器选择在没有扩展主密钥扩展的情况下继续进行完全握手，则新会话容易受到第1节中描述的中间人密钥同步攻击。因此，客户端或服务器不得基于新的主密钥导出任何密钥材料，以用于任何后续的应用程序级身份验证。特别是，它必须禁用[RFC5705]和任何依赖复合身份验证[COMPLONE-AUTH]的可扩展身份验证协议（EAP）。
If a client or server chooses to continue an abbreviated handshake to resume a session that does not use the extended master secret, then the current connection becomes vulnerable to a man-in-the-middle handshake log synchronization attack as described in Section 1. Hence, the client or server MUST NOT use the current handshake's "verify_data" for application-level authentication. In particular, the client MUST disable renegotiation and any use of the "tls-unique" channel binding [RFC5929] on the current connection.
如果客户端或服务器选择继续简短握手以恢复不使用扩展主密钥的会话，则当前连接容易受到中间人握手日志同步攻击，如第1节所述。因此，客户端或服务器不得使用当前握手的“验证数据”进行应用程序级身份验证。特别是，客户端必须在当前连接上禁用重新协商和任何“tls唯一”通道绑定[RFC5929]的使用。
If the original session uses an extended master secret but the ClientHello or ServerHello in the abbreviated handshake does not include the extension, it MAY be safe to continue the abbreviated handshake since it is protected by the extended master secret of the original session. This scenario may occur, for example, when a server that implements this extension establishes a session but the session is subsequently resumed at a different server that does not support the extension. Since such situations are unusual and likely to be the result of transient or inadvertent misconfigurations, this document recommends that the client and server MUST abort such handshakes.
如果原始会话使用扩展主密钥，但缩写握手中的ClientHello或ServerHello不包括扩展，则可以安全地继续缩写握手，因为它受原始会话的扩展主密钥保护。例如，当实现此扩展的服务器建立会话，但随后在不支持该扩展的其他服务器上恢复会话时，可能会出现这种情况。由于这种情况是不寻常的，可能是暂时或无意的错误配置造成的，因此本文档建议客户端和服务器必须中止此类握手。
One way to mount a triple handshake attack is described in Section 1, along with a mention of the security mechanisms that break due to the attack; more in-depth discussion and diagrams can be found in [TRIPLE-HS]. Here, some further discussion is presented about attack preconditions and impact.
第1节描述了发起三次握手攻击的一种方法，并提到了因攻击而中断的安全机制；更深入的讨论和图表可在[TRIPLE-HS]中找到。这里，我们将进一步讨论攻击的前提条件和影响。
To mount a triple handshake attack, it must be possible to force the same master secret on two different sessions. For this to happen, two preconditions must be met:
要发起三重握手攻击，必须能够在两个不同会话上强制使用相同的主密钥。要做到这一点，必须满足两个先决条件：
o The client, C, must be willing to connect to a malicious server, A. In certain contexts, like the web, this can be easily achieved, since a browser can be instructed to load content from an untrusted origin.
o 客户端C必须愿意连接到恶意服务器a。在某些情况下，如web，这很容易实现，因为可以指示浏览器从不受信任的来源加载内容。
o The pre-master secret must be synchronized on the two sessions. This is particularly easy to achieve with the RSA and DHE key exchanges, but under some conditions, ECDHE, SRP, and PSK key exchanges can be exploited to this effect as well.
o 前主密钥必须在两个会话上同步。使用RSA和DHE密钥交换特别容易实现这一点，但在某些情况下，ECDHE、SRP和PSK密钥交换也可以达到这一效果。
Once the master secret is synchronized on two sessions, any security property that relies on the uniqueness of the master secret is compromised. For example, a TLS exporter [RFC5705] no longer provides a unique key bound to the current session.
一旦主密钥在两个会话上同步，依赖于主密钥唯一性的任何安全属性都会被破坏。例如，TLS导出器[RFC5705]不再提供绑定到当前会话的唯一密钥。
TLS session resumption also relies on the uniqueness of the master secret to authenticate the resuming peers. Hence, if a synchronized session is resumed, the peers cannot be sure about each other's identities, and the attacker knows the connection keys. Clearly, a precondition to this step of the attack is that both client and server support session resumption (either via session identifier or session tickets [RFC5077]).
TLS会话恢复还依赖于主密钥的唯一性来验证正在恢复的对等方。因此，如果同步会话恢复，对等方无法确定彼此的身份，攻击者也知道连接密钥。显然，此攻击步骤的先决条件是客户端和服务器都支持会话恢复（通过会话标识符或会话票证[RFC5077]）。
Additionally, in a synchronized abbreviated handshake, the whole transcript (which includes the "verify_data" values) is synchronized. So, after an abbreviated handshake, channel bindings like "tls-unique" [RFC5929] will not uniquely identify the connection anymore.
此外，在同步的缩写握手中，整个转录本（包括“verify_data”值）是同步的。因此，在一次简短的握手之后，像“tls unique”[RFC5929]这样的通道绑定将不再唯一地标识连接。
Synchronization of the "verify_data" in abbreviated handshakes also undermines the security guarantees of the renegotiation indication extension [RFC5746], re-enabling a prefix-injection flaw similar to the renegotiation attack [Ray09]. However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes. Hence, a precondition to mount this stage of the attack is that the client accepts different certificates at each handshake, even if their common names do not match. Before the triple handshake attack was discovered, this used to be widespread behavior, at least among some web browsers; such browsers were hence vulnerable to the attack.
缩写握手中“验证_数据”的同步也破坏了重新协商指示扩展[RFC5746]的安全保证，重新启用了类似于重新协商攻击[Ray09]的前缀注入漏洞。但是，在三次握手攻击中，客户端会看到服务器证书在不同的完全握手中发生变化。因此，装载此阶段攻击的先决条件是客户端在每次握手时接受不同的证书，即使它们的通用名称不匹配。在发现三重握手攻击之前，这种行为曾经很普遍，至少在一些web浏览器中是如此；因此，此类浏览器容易受到攻击。
The extended master secret extension thwarts triple handshake attacks at their first stage by ensuring that different sessions necessarily end up with different master secret values. Hence, all security
扩展的主密钥扩展通过确保不同会话必然以不同的主密钥值结束，从而在第一阶段阻止三次握手攻击。因此，所有的安全
properties relying on the uniqueness of the master secret are now expected to hold. In particular, if a TLS session is protected by the extended master secret extension, it is safe to resume it, to use its channel bindings, and to allow for certificate changes across renegotiation, meaning that all certificates are controlled by the same peer. A symbolic cryptographic protocol analysis justifying the extended master secret extension appears in [VERIFIED-BINDINGS].
依赖于主密钥唯一性的属性现在有望保持不变。特别是，如果TLS会话受扩展主密钥扩展保护，则可以安全地恢复该会话，使用其通道绑定，并允许在重新协商过程中更改证书，这意味着所有证书都由同一对等方控制。[VERIFIED-BINDINGS]中出现了一个用于证明扩展主密钥扩展的符号密码协议分析。
The session hashes of two different sessions need to be distinct; hence, the "Hash" function used to compute the "session_hash" needs to be collision resistant. As such, hash functions such as MD5 or SHA1 are NOT RECOMMENDED.
两个不同会话的会话哈希需要不同；因此，用于计算“session_Hash”的“Hash”函数需要具有抗冲突性。因此，不建议使用MD5或SHA1等散列函数。
We observe that the "Hash" function used in the Finished message computation already needs to be collision resistant for the renegotiation indication extension [RFC5746] to work, because a meaningful collision on the handshake messages (and hence on the "verify_data") may re-enable the renegotiation attack [Ray09].
我们观察到，完成的消息计算中使用的“哈希”函数已经需要具有抗冲突性，以便重新协商指示扩展[RFC5746]能够工作，因为握手消息（以及“验证数据”）上的有意义冲突可能会重新启用重新协商攻击[Ray09]。
The hash function used to compute the session hash depends on the TLS protocol version. All current ciphersuites defined for TLS 1.2 use SHA256 or better, and so does the session hash. For earlier versions of the protocol, only MD5 and SHA1 can be assumed to be supported, and this document does not require legacy implementations to add support for new hash functions. In these versions, the session hash uses the concatenation of MD5 and SHA1, as in the Finished message.
用于计算会话哈希的哈希函数取决于TLS协议版本。为TLS 1.2定义的所有当前密码套件都使用SHA256或更高版本，会话哈希也是如此。对于协议的早期版本，可以假定只支持MD5和SHA1，并且本文档不需要传统实现来添加对新哈希函数的支持。在这些版本中，会话哈希使用MD5和SHA1的串联，就像在完成的消息中一样。
The "session_hash" is intended to encompass all relevant session information, including ciphersuite negotiation, key exchange messages, and client and server identities. The hash is needed to compute the extended master secret and hence must be available before the Finished messages.
“会话_散列”旨在包含所有相关会话信息，包括密码套件协商、密钥交换消息以及客户端和服务器标识。散列是计算扩展主密钥所必需的，因此必须在完成消息之前可用。
This document sets the "session_hash" to cover all handshake messages up to and including the ClientKeyExchange. For existing TLS ciphersuites, these messages include all the significant contents of the new session -- CertificateVerify does not change the session content. At the same time, this allows the extended master secret to be computed immediately after the pre-master secret, so that implementations can shred the temporary pre-master secret from memory as early as possible.
本文档将“会话\u散列”设置为包括ClientKeyExchange之前的所有握手消息。对于现有的TLS密码套件，这些消息包括新会话的所有重要内容——CertificateVerify不会更改会话内容。同时，这允许在预主密钥之后立即计算扩展主密钥，以便实现可以尽早从内存中分割临时预主密钥。
It is possible that new ciphersuites or TLS extensions may include additional messages between ClientKeyExchange and Finished that add important session context. In such cases, some of the security guarantees of this specification may no longer apply, and new man-in-the-middle attacks may be possible. For example, if the client and server support the session ticket extension [RFC5077], the session hash does not cover the new session ticket sent by the server. Hence, a man-in-the-middle may be able to cause a client to store a session ticket that was not meant for the current session. Attacks based on this vector are not yet known, but applications that store additional information in session tickets beyond those covered in the session hash require careful analysis.
新的密码套件或TLS扩展可能包括ClientKeyExchange和Finished之间添加重要会话上下文的附加消息。在这种情况下，本规范的某些安全保证可能不再适用，并且可能会出现新的中间人攻击。例如，如果客户机和服务器支持会话票证扩展[RFC5077]，则会话哈希不会覆盖服务器发送的新会话票证。因此，中间人可能会导致客户端存储不适用于当前会话的会话票证。基于此向量的攻击尚不清楚，但在会话散列中包含的信息之外，在会话票据中存储额外信息的应用程序需要仔细分析。
The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is equally vulnerable to triple handshake attacks, alongside other vulnerabilities stemming from its use of obsolete cryptographic constructions that are now considered weak. SSL 3.0 has been deprecated [RFC7568].
安全套接字层（SSL）协议3.0版[RFC6101]是TLS协议的前身，它同样容易受到三重握手攻击，同时也容易受到其他因使用过时的加密结构而产生的漏洞的攻击，这些结构现在被认为很弱。SSL 3.0已被弃用[RFC7568]。
The countermeasure described in this document relies on a TLS extension and hence cannot be used with SSL 3.0. Clients and servers implementing this document SHOULD refuse SSL 3.0 handshakes. If they choose to support SSL 3.0, the resulting sessions MUST use the legacy master secret computation, and the interoperability considerations of Section 5.4 apply.
本文档中描述的对策依赖于TLS扩展，因此不能与SSL 3.0一起使用。实现此文档的客户端和服务器应拒绝SSL 3.0握手。如果选择支持SSL 3.0，则生成的会话必须使用传统的主密钥计算，并且第5.4节中的互操作性注意事项适用。
IANA has added the extension code point 23 (0x0017), which has been used by prototype implementations, for the "extended_master_secret" extension to the "ExtensionType Values" registry specified in the TLS specification [RFC5246].
IANA为TLS规范[RFC5246]中指定的“ExtensionType Values”注册表添加了扩展代码点23（0x0017），该扩展代码点已被原型实现使用。
[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>.
[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>.
[COMPOUND-AUTH] Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication Protocols", Security Protocols, LNCS, Volume 3364, DOI 10.1007/11542322_6, 2005.
[复合认证]Asokan，N.，Valtteri，N.，和K.Nyberg，“隧道认证协议中的中间人”，安全协议，LNCS，第3364卷，DOI 10.1007/11542322_6，2005年。
[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.
[Ray09]Ray，M.“TLS重新谈判中的认证差距”，2009年。
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，DOI 10.17487/RFC4251，2006年1月<http://www.rfc-editor.org/info/rfc4251>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://www.rfc-editor.org/info/rfc5077>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<http://www.rfc-editor.org/info/rfc5705>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 5746，DOI 10.17487/RFC5746，2010年2月<http://www.rfc-editor.org/info/rfc5746>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <http://www.rfc-editor.org/info/rfc5929>.
[RFC5929]Altman，J.，Williams，N.和L.Zhu，“TLS的通道绑定”，RFC 5929，DOI 10.17487/RFC5929，2010年7月<http://www.rfc-editor.org/info/rfc5929>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.
[RFC6101]Freier，A.，Karlton，P.，和P.Kocher，“安全套接字层（SSL）协议版本3.0”，RFC 6101，DOI 10.17487/RFC6101，2011年8月<http://www.rfc-editor.org/info/rfc6101>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457]Sheffer，Y.，Holz，R.，和P.Saint Andre，“总结对传输层安全（TLS）和数据报TLS（DTLS）的已知攻击”，RFC 7457，DOI 10.17487/RFC7457，2015年2月<http://www.rfc-editor.org/info/rfc7457>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <http://www.rfc-editor.org/info/rfc7568>.
[RFC7568]Barnes，R.，Thomson，M.，Pironti，A.，和A.Langley，“不推荐安全套接字层版本3.0”，RFC 7568，DOI 10.17487/RFC7568，2015年6月<http://www.rfc-editor.org/info/rfc7568>.
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", NIST Special Publication 800-108, 2009.
[SP800-108]Chen，L.“使用伪随机函数进行密钥推导的建议（修订版）”，NIST特别出版物800-108，2009年。
[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, 2014.
[TRIPLE-HS]Bhargavan，K.，Delignat Lavaud，A.，Fournet，C.，Pironti，A.，和P-Y.Strub，“三重握手和切饼干器：通过TLS破坏和修复认证”，IEEE安全和隐私研讨会，DOI 10.1109/SP.2014.14，2014年。
[VERIFIED-BINDINGS] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, "Verified Contributive Channel Bindings for Compound Authentication", Network and Distributed System Security Symposium (NDSS), 2015.
[VERIFIED-BINDINGS]Bhargavan，K.，Delignat-Lavaud，A.，和A.Pironti，“复合认证的已验证贡献通道绑定”，网络和分布式系统安全研讨会（NDSS），2015年。
Acknowledgments
致谢
Triple handshake attacks were originally discovered by Antoine Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti. They were further developed by the miTLS team: Cedric Fournet, Pierre-Yves Strub, Markulf Kohlweiss, and Santiago Zanella-Beguelin. Many of the ideas in this document emerged from discussions with Martin Abadi, Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric Rescorla, Martin Rex, and Brian Smith.
三重握手攻击最初由Antoine Delignat Lavaud、Karthikeyan Bhargavan和Alfredo Pironti发现。miTLS团队进一步开发了它们：塞德里克·福内特（Cedric Fournet）、皮埃尔·伊夫·斯特鲁布（Pierre-Yves Strub）、马尔库夫·科尔维斯（Markulf Kohlweiss）和圣地亚哥·扎内拉·贝古林（Santiago Zanella Beguelin）。本文件中的许多想法来自与Martin Abadi、Ben Laurie、Nikos Mavrogiannopoulos、Manuel Pegourie Gonnard、Eric Rescorla、Martin Rex和Brian Smith的讨论。
Authors' Addresses
作者地址
Karthikeyan Bhargavan (editor) Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
Karthikeyan Bhargavan（编辑）Inria Paris Rocuncourt 23，Avenue d'Italie Paris 75214 CEDEX 13法国
Email: karthikeyan.bhargavan@inria.fr
Email: karthikeyan.bhargavan@inria.fr
Antoine Delignat-Lavaud Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
法国巴黎意大利大道23号巴黎罗库库尔安托万Delignat Lavaud酒店75214 CEDEX 13
Email: antoine.delignat-lavaud@inria.fr
Email: antoine.delignat-lavaud@inria.fr
Alfredo Pironti Inria Paris-Rocquencourt 23, Avenue d'Italie Paris 75214 CEDEX 13 France
阿尔弗雷多·皮龙蒂（Alfredo Pironti），法国巴黎意大利大道23号，法国塞迪斯13号，邮编75214
Email: alfredo.pironti@inria.fr
Email: alfredo.pironti@inria.fr
Adam Langley Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Adam Langley Google Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: agl@google.com
Email: agl@google.com
Marsh Ray Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 United States
美国华盛顿州雷德蒙微软路1号Marsh Ray微软公司，邮编：98052
Email: maray@microsoft.com
Email: maray@microsoft.com