| Network Working Group | K. Bhargavan, Ed. |
| Internet-Draft | A. Delignat-Lavaud |
| Intended status: Standards Track | A. Pironti |
| Expires: October 3, 2015 | Inria Paris-Rocquencourt |
| A. Langley | |
| Google Inc. | |
| M. Ray | |
| Microsoft Corp. | |
| April 2015 |
Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
draft-ietf-tls-session-hash-05
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 3, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
In TLS, every session has a master_secret computed as: 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 DHE ciphersuites, it is the result of a Diffie-Hellman key agreement.
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. 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 the two sessions and it 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.
At this point, both connections (between C and A, and between A and S) have new sessions that share the same
The above scenario 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.
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 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 SRP and PSK, have also been shown to be vulnerable [VERIFIED-BINDINGS].
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.
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.
Critically, on 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 that 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].
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, 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 document uses the same notation and terminology used in the TLS Protocol specification.
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.
session_hash = Hash(handshake_messages)
When a full TLS handshake takes place, we define 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].
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.
There is no session_hash for resumed handshakes, as they do not lead to the creation of a new session.
master_secret = PRF(pre_master_secret, "extended master secret",
session_hash)
[0..47];
When the extended master secret extension is negotiated in a full handshake, the master_secret is computed as [RFC5246] in the following ways:
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.
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 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.
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.)
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.
If an abbreviated handshake takes place, the new connection keys are derived as usual from the (extended) master secret of the original handshake that created the resumed session.
In the following, we use "aborting 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.
If a server implementing this document receives the extended_master_secret extension, it MUST include the extended_master_secret extension in its ServerHello message.
If the server receives a ClientHello without the extension, it SHOULD abort the handshake. If it chooses to continue, then it MUST NOT include the extension in the ServerHello.
If a client receives a ServerHello without the extension, it SHOULD abort the handshake.
In a full handshake, if both the ClientHello and ServerHello contain the extension, the new session uses the extended master secret computation.
Some clients and servers may choose to continue a full handshake without the extension, in order to interoperate with legacy peers. In this case, they use the standard master secret derivation for the new session, and the considerations in Section 5.4 apply.
The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret. The client MUST send the extended_master_secret extension in its ClientHello.
If a server receives a ClientHello for an abbreviated handshake offering to resume a previous session, it behaves as follows.
If a client receives a ServerHello that accepts an abbreviated handshake, it behaves as follows.
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 connection.
To allow interoperability with legacy clients and servers, a TLS peer may decide to accept 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.
If a client or server chooses to continue with a full handshake without the extended master secret extension, the new session is 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 EAP protocol relying on compound authentication [COMPOUND-AUTH].
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 is 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 should disable renegotiation and any use of the tls-unique channel binding [RFC5929] on the current connection.
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 from the man-in-the-middle attack by the extended master secret. 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.
One way to mount a triple handshake attack has been 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.
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: [RFC5705] no longer provides a unique key bound to the current session.
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
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]).
Additionally, in a synchronized abbreviated handshake, the whole transcript is synchronized, which includes the verify_data values. So, after an abbreviated handshake, channel bindings like tls-unique [RFC5929] will not identify uniquely the connection anymore.
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, that were hence vulnerable to the attack.
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].
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.
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].
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.
The session_hash is intended to encompass all relevant session information, including ciphersuite negotiation, key exchange messages and client and server identities. The session hash needs to be available to compute the extended master secret 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.
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.
SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is equally vulnerable to the triple handshake attacks, alongside other vulnerabilities stemming from its use of obsolete cryptographic constructions that are now considered weak.
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.
IANA has added the extension code point 23 (0x0017), which has been used by prototype implementations, for the "extended_master_secret" extension to the TLS ExtensionType values registry as specified in TLS.
The triple handshake attacks were originally discovered by Antoine Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were further developed by the miTLS team: Cédric Fournet, Pierre-Yves Strub, Markulf Kohlweiss, Santiago Zanella-Béguelin. Many of the ideas in this draft emerged from discussions with Martín Abadi, Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pégourié-Gonnard, Eric Rescorla, Martin Rex, Brian Smith.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |