RFC 7627

Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension

📅 published September 2015, from ietf

Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension 🎀

okay bestie, let's get into RFC 7627 🧚💖 it's titled Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension, and it's an IETF Standards Track doc from September 2015 (ISSN 2070-1721). The editor is K. Bhargavan, with A. Delignat-Lavaud, A. Pironti (all at Inria Paris-Rocquencourt), A. Langley (Google Inc.), and M. Ray (Microsoft Corp.). It updates RFC 5246, and the title block doesn't list anything it obsoletes 🌸

Abstract ✨

okay so the TLS master secret isn't cryptographically tied to the important session stuff, like the server certificate 😭 that means an active attacker can set up two sessions, one with a client and one with a server, and end up with the same master secret on both. 💀 After that, anything that uses the master secret for auth (session resumption included) is open to a man-in-the-middle attack, where the attacker just forwards messages back and forth. This spec defines a TLS extension that binds the master secret to a log of the full handshake that computes it, which stops these attacks 🛡️🦋

Status of This Memo

this is an Internet Standards Track document 🍓

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 5741.

info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7627 💅

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜

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 ✨

okay so in TLS [RFC5246], every session has a "master_secret" computed like this 🔥

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
                    [0..47];

the "pre_master_secret" is whatever comes out of some key exchange protocol. For an RSA ciphersuite, the client makes this value uniformly at random. For Ephemeral Diffie-Hellman (DHE) ciphersuites, it's the result of a Diffie-Hellman key agreement 🧪

per [TRIPLE-HS], in both RSA and DHE exchanges, an active attacker can sync two TLS sessions so they share the same "master_secret" 😳 here's how that works with an RSA exchange where the client isn't authenticated. Say a client C connects to a server A. C has no clue that A is malicious, and A quietly connects to an honest server S and finishes both handshakes. To keep it simple, assume C and S only use RSA ciphersuites 👀

  1. C sends a ClientHello to A, and A forwards it to S.
  2. S sends a ServerHello to A, and A forwards it to C.
  3. S sends a Certificate, containing its certificate chain, to A. A swaps in its own certificate chain and sends that to C.
  4. S sends a ServerHelloDone to A, and A forwards it to 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.
  6. C sends a Finished to A. A computes a Finished for its connection with S and sends it to S.
  7. S sends a Finished to A. A computes a Finished for its connection with C and sends it to C.

so now both connections (C to A, and A to S) are new sessions sharing the same pre_master_secret, ClientHello.random, and ServerHello.random, plus other session parameters like the session identifier and, optionally, the session ticket 🫣 that means the master_secret is equal for both, and C and S both associate it with the same session ID, even though the server identities on the two connections are different. C only sees A's certificate and has no idea about A's connection with S. And the record keys on the two connections end up the same too 😭

the big takeaway is that TLS doesn't guarantee the master secrets and keys on different connections will be different. Even if client authentication is in play, the scenario still works. The only difference is the two sessions now disagree on the client and server identities.

a similar thing can happen with a DHE ciphersuite. Even if the client or server doesn't prefer RSA or DHE, the attacker can force them into 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 stronger adversaries, other key exchanges like Secure Remote Password (SRP) and Pre-Shared Key (PSK) have also been shown to be vulnerable [VERIFIED-BINDINGS] 💀

once A has synced the two connections, the keys match on both sides, so A can step back and transparently forward messages between C and S, reading and modifying whatever it wants 😈 In key exchange literature, these are called unknown key-share attacks, since C and S share a secret but each thinks the secret is shared only with A. On their own, these attacks don't break integrity or confidentiality between the honest parties. But they're a useful starting point for impersonation attacks on C and S 🫠

now say C tries to resume its session on a new connection with A. A can resume its session with S on a new connection and forward the abbreviated handshake messages unchanged between C and S. The abbreviated handshake only relies on the master secret for auth and doesn't mention client or server identities, so both handshakes complete fine, with the same session keys and the same handshake log. A still knows the connection keys and can message both C and S 🫢

even worse, on the new connection the handshake log is identical on C and S. That defeats any man-in-the-middle protection that depends on finished messages being unique, like the secure renegotiation indication extension [RFC5746] or TLS channel bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on these session synchronization attacks. In particular, it describes a man-in-the-middle attack, called the "triple handshake", that gets around the protections in [RFC5746] to break client-authenticated TLS renegotiation after session resumption. Similar attacks apply to application-level auth mechanisms that rely on channel bindings [RFC5929] or on key material exported from TLS [RFC5705] 🧵

the root issue is that the TLS master secret isn't guaranteed to be unique across sessions, because it isn't context-bound to the full handshake that generated it. If we fix that in the initial master secret computation, all these attacks can be prevented 🔒 This spec adds a TLS extension that changes how master_secret is computed in a full handshake, by including the log of the handshake messages. That way, different sessions will have different master secrets by construction. This blocks the attacks described in [TRIPLE-HS] and documented in Section 2.11 of [RFC7457] 👑

2. Requirements Notation ✨

this doc uses the same notation and terminology as the TLS protocol spec [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] 🎯

3. The TLS Session Hash 🌈

when a full TLS handshake happens, we define

session_hash = Hash(handshake_messages)

where "handshake_messages" means all handshake messages sent or received, starting at the ClientHello and going up to and including the ClientKeyExchange message, including the type and length fields of the handshake messages. It's 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 earlier versions of TLS, the "Hash" function computes the concatenation of MD5 and SHA1 🫶

there's no "session_hash" for resumed handshakes, since they don't create a new session 🦋

4. The Extended Master Secret ✨

okay so when the extended master secret extension gets negotiated in a full handshake, the master_secret gets computed like this 👇

   master_secret = PRF(pre_master_secret, "extended master secret",
                       session_hash)
                       [0..47];

the extended computation is basically the [RFC5246] one with two glow-ups 💅

  • the "extended master secret" label replaces "master secret" 🎀
  • session_hash takes the place of ClientHello.random and ServerHello.random 🌸

the session_hash is built from a handshake log. that log includes ClientHello.random and ServerHello.random, plus the ciphersuites, key exchange info, and certificates (if there are any) from both the client and the server 🧚 so the extended master secret depends on ALL of those session parameters. no cap, that's the whole point ✨

this design is based on the idea that keys should be bound to the security contexts that compute them [SP800-108]. mixing a hash of the key exchange messages into key derivation is already a move in other well-known protocols too, like Secure Shell (SSH) [RFC4251]. it's giving consistency 🦋

clients and servers SHOULD NOT accept handshakes that don't use the extended master secret 🙈 this is especially true if they rely on stuff like compound authentication, because that falls into the vulnerable cases described in Section 6.1. not worth the risk, bestie 💀

5. Extension Negotiation 🎀

5.1. Extension Definition

this document introduces a new TLS extension called extended_master_secret (extension type 0x0017) 💖 its job is to tell both the client and the server to use the extended master secret computation. the extension_data field is empty, so the whole encoding of the extension is 00 17 00 00 (in hexadecimal). tiny but mighty 🌟

even though this document only talks about TLS, this extension can also be used with Datagram TLS (DTLS) [RFC6347] ✨

if the client and server agree on this extension and a full handshake happens, both of them MUST use the extended master secret derivation algorithm from Section 4. everything else in the cryptography stays exactly the same 🫶

5.2. Client and Server Behavior: Full Handshake

quick vocab 📚 in the rest of this section, "abort the handshake" is shorthand for ending the handshake by sending a fatal handshake_failure alert 🚨

in every handshake, a client implementing this document MUST send the extended_master_secret extension in its ClientHello 💅

if a server implementing this document gets the extended_master_secret extension, it MUST include the extension in its ServerHello message 🎀

if BOTH the ClientHello and the ServerHello have the extension, the new session uses the extended master secret computation. main character energy ✨

if the server gets a ClientHello WITHOUT the extension, it SHOULD abort the handshake, but only if it doesn't want to interoperate with legacy clients 🙈 if it does decide to keep going, it MUST NOT include the extension in its ServerHello.

if a client gets a ServerHello WITHOUT the extension, it SHOULD abort the handshake, again only if it doesn't want to interoperate with legacy servers 🦋

if the client and server choose to keep going with a full handshake without the extension, they MUST use the standard master secret derivation for the new session 💀 and here's the tea: the new session is NOT protected by the mechanisms in this document. so implementers should follow the guidelines in Section 5.4 to avoid dangerous usage scenarios. especially, the master secret from that new session should not be used for application-level authentication. not me being dramatic, it's just a real risk 😭

5.3. Client and Server Behavior: Abbreviated Handshake

the client SHOULD NOT offer an abbreviated handshake to resume a session that doesn't use an extended master secret 🙅‍♀️ instead, it SHOULD offer a full handshake 🌸

if the client still wants to offer an abbreviated handshake for those sessions, 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 to avoid dangerous usage scenarios. renegotiation is also no longer secure on this connection, even if the client and server support the renegotiation indication extension [RFC5746] 💀

when the client offers an abbreviated handshake, it MUST send the extended_master_secret extension in its ClientHello 💖

if a server gets a ClientHello for an abbreviated handshake that's trying to resume a known previous session, here's how it handles it 👇

  • if the original session did NOT use the extended_master_secret extension but the new ClientHello DOES contain it, 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 🧚
  • if the original session DID use the extended_master_secret extension but the new ClientHello does NOT contain it, the server MUST abort the abbreviated handshake 🚨
  • if neither the original session nor the new ClientHello uses the extension, the server SHOULD abort the handshake. if it keeps going with an abbreviated handshake anyway 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 ✨
  • 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 🎀

if a client gets a ServerHello that accepts an abbreviated handshake, here's the check 🔍

  • if the original session did NOT use the extended_master_secret extension but the new ServerHello DOES contain it, the client MUST abort the handshake 😭
  • if the original session DID use the extension but the new ServerHello does NOT contain it, the client MUST abort the handshake 💅

if the client and server do continue the abbreviated handshake, they derive the connection keys for the new session as usual, starting from the master secret of the original session. lowkey the cleanest path 🌈

5.4. Interoperability Considerations

to play nice with legacy clients and servers, a TLS peer may decide to accept full handshakes that use the legacy master secret computation 🫶 if it does, it needs to tell apart sessions that use legacy master secrets from ones that use extended master secrets, and the way to do that is 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, then the new session becomes vulnerable to the man-in-the-middle key synchronization attack described in Section 1 😱 so the client or server MUST NOT export any key material based on the new master secret for any later application-level authentication. specifically, it MUST disable [RFC5705] and any Extensible Authentication Protocol (EAP) that relies 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 becomes vulnerable to a man-in-the-middle handshake log synchronization attack, as described in Section 1 🚨 so the client or server MUST NOT use the current handshake's verify_data for application-level authentication. and the client MUST disable renegotiation, plus 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 doesn't include the extension, it MAY be safe to continue the abbreviated handshake, since it's protected by the extended master secret of the original session 🦋 this could happen, for example, when a server that implements this extension sets up a session, but the session gets resumed at a different server that doesn't support the extension. since situations like this are unusual and probably the result of transient or accidental misconfigurations, this document recommends that the client and server MUST abort such handshakes 🌸

6. Security Considerations 🔥

6.1. Triple Handshake Preconditions and Impact ✨

okay so Section 1 already gave us one way to pull off a triple handshake attack, plus a look at which security mechanisms faceplant because of it 💀. If you want the deep dive with diagrams, go check [TRIPLE-HS]. Here I'm just going to talk about what has to be true for the attack to work and how much damage it does 🫶

To pull off a triple handshake attack, it must be possible to force the same master secret on two different sessions. For that to happen, two preconditions have to be met:

  • The client, C, must be willing to connect to a malicious server, A. In certain contexts, like the web, this is super easy to set up, since a browser can be told to load content from an untrusted origin 🙈
  • The pre-master secret must be synchronized on the two sessions. This is especially easy to pull off with the RSA and DHE key exchanges, but under some conditions, ECDHE, SRP, and PSK key exchanges can be exploited for this too 😭

Once the master secret is synchronized across two sessions, any security property that relies on the master secret being unique is compromised 💔 For example, a TLS exporter [RFC5705] no longer gives you a unique key bound to the current session. Not it 💅

TLS session resumption also depends on the master secret being unique to authenticate the resuming peers. So if a synchronized session gets resumed, the peers can't be sure about each other's identities, and the attacker knows the connection keys. Clearly, a precondition for this step is that both client and server support session resumption (either via session identifier or session tickets [RFC5077]) 🎀

Also, 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] won't uniquely identify the connection anymore 🥲

Synchronizing "verify_data" in abbreviated handshakes also undermines the security guarantees of the renegotiation indication extension [RFC5746], which brings back a prefix-injection flaw that's similar to the renegotiation attack [Ray09] 👀 However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes. So a precondition for this stage of the attack is that the client accepts different certificates at each handshake, even if their common names don't match. Before the triple handshake attack was discovered, this was widespread behavior, at least among some web browsers, and those browsers were therefore vulnerable to the attack 😬

The extended master secret extension stops triple handshake attacks at their first stage by making sure that different sessions always end up with different master secret values ✨ So all security properties that rely on the uniqueness of the master secret are now expected to hold. Specifically, if a TLS session is protected by the extended master secret extension, it's safe to resume it, to use its channel bindings, and to allow certificate changes across renegotiation, meaning all certificates are controlled by the same peer. Main character energy, honestly 👑 A symbolic cryptographic protocol analysis justifying the extended master secret extension is in [VERIFIED-BINDINGS] 🧚

6.2. Cryptographic Properties of the Hash Function

The session hashes of two different sessions need to be distinct. That means the "Hash" function used to compute the "session_hash" needs to be collision resistant 🔐 So hash functions like MD5 or SHA1 are NOT RECOMMENDED. Bye bye 👋

We also notice that the "Hash" function used in the Finished message computation already needs to be collision resistant for the renegotiation indication extension [RFC5746] to work. That's because a meaningful collision on the handshake messages (and therefore on the "verify_data") could bring back 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 doesn't require legacy implementations to add support for new hash functions. In those versions, the session hash uses the concatenation of MD5 and SHA1, same as in the Finished message 🌸

6.3. Handshake Messages Included in the Session Hash

The "session_hash" is meant to cover all the relevant session information, including ciphersuite negotiation, key exchange messages, and client and server identities 🍓 The hash is needed to compute the extended master secret, so it has to 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, those messages include all the significant contents of the new session. CertificateVerify doesn't change the session content, so it's not part of the picture 🙄 At the same time, this lets the extended master secret be computed right after the pre-master secret, so implementations can shred the temporary pre-master secret from memory as early as possible 🗑️✨ Iconic efficiency.

New ciphersuites or TLS extensions might add extra messages between ClientKeyExchange and Finished that carry important session context. In those cases, some of the security guarantees of this specification may no longer apply, and new man-in-the-middle attacks may become possible 😰 For example, if the client and server support the session ticket extension [RFC5077], the session hash doesn't cover the new session ticket sent by the server. So a man-in-the-middle might be able to get a client to store a session ticket that wasn't meant for the current session. No attacks based on this vector are known yet, but applications that store additional information in session tickets beyond what's covered in the session hash need careful analysis 🧐

6.4. No SSL 3.0 Support

The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a predecessor of TLS, and it's just as vulnerable to triple handshake attacks. It also has other vulnerabilities that come from its use of obsolete cryptographic constructions that are now considered weak 💀 SSL 3.0 has been deprecated [RFC7568], so it's giving "retired" energy 🕰️

The countermeasure described in this document relies on a TLS extension, so it can't 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 anyway, the resulting sessions MUST use the legacy master secret computation, and the interoperability considerations of Section 5.4 apply 🚫

7. IANA Considerations ✨

IANA has added the extension code point 23 (0x0017), which prototype implementations have already been using, for the extended_master_secret extension to the "ExtensionType Values" registry specified in the TLS specification [RFC5246] 🎀

8. References ✨

8.1. Normative References

8.2. Informative References

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 came out of discussions with Martin Abadi, Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric Rescorla, Martin Rex, and Brian Smith 💜

Authors' Addresses 💌

okay bestie, this is the contact list at the end of the doc 📇 five people wrote RFC 7627, and here's how to reach each of them 🫶

Karthikeyan Bhargavan is the editor 👑 Here's where to find him 🇫🇷

Karthikeyan Bhargavan (editor)
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris  75214 CEDEX 13
France

Email: karthikeyan.bhargavan@inria.fr

Next up is Antoine Delignat-Lavaud, also at Inria Paris-Rocquencourt 🥐

Antoine Delignat-Lavaud
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris  75214 CEDEX 13
France

Email: antoine.delignat-lavaud@inria.fr

Then there's Alfredo Pironti, same Inria address, which is giving team energy 🤝

Alfredo Pironti
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris  75214 CEDEX 13
France

Email: alfredo.pironti@inria.fr

Adam Langley is over at Google Inc. in Mountain View 🌈

Adam Langley
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA  94043
United States

Email: agl@google.com

Last but not least, Marsh Ray at Microsoft Corp. in Redmond 💜 iconic way to wrap up the list 💅

Marsh Ray
Microsoft Corp.
1 Microsoft Way
Redmond, WA  98052
United States

Email: maray@microsoft.com
📦 where this page comes from