Subject: [TLS] MITM Attacks on Client Authentication after Resumption

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 3 Mar 2014 15:20:55 +0000

We are going to present some new man-in-the-middle attacks on TLS
applications in Tuesday’s working group meeting. These attacks were
found as part of our research on trying to prove cryptographic
security for a TLS implementation [1].  We presenting some of the
materials here to kick-start some discussion and get early comments on
our proposed countermeasure. Some people on the list already know of
these attacks but this is the first public disclosure.

More details are at https://secure-resumption.com [2]

Scenario
======
Consider a client C that normally authenticates to a server S using a
client certificate.  If C uses the same certificate to authenticate to
a malicious server M, then we show that M can use C’s certificate to
authenticate its own connection to S.

The attack relies on the combination of an initial RSA or DHE
handshake, followed by session resumption on a new connection,
followed by a client-authenticated renegotiation. During the first two
handshakes, C has a connection to M and M has a connection to
S. During the third handshake, M is able to authenticate as C to S and
as S to C.

This server-based man-in-the-middle attack should normally have been
prevented by the Renegotiation Indication (RI) extension [3] but by
injecting session resumption between the two full handshakes, we are
able to bypass the renegotiation countermeasure.

Triple Handshake Attack
================
I’ll briefly summarise the attack below for an initial RSA key
exchange.  The webpage [2] has diagrams that will be easier to follow,
describes more attack variants, and provides some disclosure status.

The attack proceeds in three steps:

Step 1. (Initial Handshakes C-M, M-S)
- C connects to M and M connects to S, both handshakes use RSA.
- M forwards C’s and S’s client hellos to each other.
- M receives an encrypted PMS from C and reencrypts it towards S.
- Both handshakes complete with new sessions and record keys.
  Both sessions have the same master secret, random nonces, and session id.
  (M knows the master secret and record keys since it participated in both handshakes)

Step 2. (Session Resumption C-M, M-S)
- C resumes its session with M on a new connection.	     
- M resumes its session with S on a new connection.
- M forwards all the abbreviated handshake messages unchanged between C and S.
- Note that the RI extensions on both handshakes are empty, 
  since it is the first handshake on the connection
- Both handshakes complete with new record keys (and reuse old sessions)
  Both connections have the same record keys and handshake logs (verify data)
  (M still knows the record keys and can send messages in either direction.)

Step 3. (Renegotiation C-M-S)
- S requests M for renegotiation with client certificate. 
  M requests C for renegotiation with client certificate.
- M forwards all renegotiation messages unchanged between C and S 
- Note that since the handshake logs in the preceding handshake were the same, 
  the RI extensions on both handshakes will be the same.
- Both handshakes complete with new mutually-authenticated sessions and record keys.
  C now thinks it is connected to S and S thinks it is connected to C.
  (M does not know the new record keys but its previous messages to S on the same connection 
  may be treated as authenticated by C.)

At the end of Step 3, S has an incoming connection on which it
initially received data from an anonymous client (M) and later
received data from an authenticated client (C). This breaks the
intended guarantees of the RI extension.

Countermeasures 
===========
During Step 3, C has a connection on which it first received M’s
certificate and later S’s certificate. If C refuses to accept this
change of server identity, then it can prevent Step 3 of the
attack. Indeed, we recommend mainstream web browsers and HTTPS
libraries should systematically forbid the change of server identities
during renegotiation.

However, already at the end of Step 2, a number of connection and
session parameters, such as the tls-unique channel binding for the two
connections are the same. So any application-level mechanism that
relies on the TLS master secret [4] or channel bindings [5] or exports
TLS keying material [6] is vulnerable to a similar man-in-the-middle
attack.

We argue that the core vulnerability here is that the TLS master
secret is not bound to enough elements of the TLS session. We propose
a new TLS extension that binds the master secret to the hash of the
all relevant handshake messages in the initial handshake.

The proposed draft is available at:
 http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt

The key idea is that each full handshake is associated with a session
hash, computed as
	
	session_hash = Hash(handshake_messages) 
	
where handshake_messages consist of all messages up to and including
the ClientKeyExchange.  The extended master secret computation enabled
by the extension is then computed as
	
	master_secret = PRF(pre_master_secret, 
                                        "extended master secret", 
                                         session_hash) [0..47]; 
	
We’ve implemented this extension in OpenSSL without much difficulty.
Changing the master secret derivation may seem radical, but we believe
it is the main way to counter future attacks that may rely on the
session synchronization (step 1) that we exploit here.

An alternative countermeasure would be an extension (along the lines
of [3]) that includes the session hash as defined above in the
ClientHello and ServerHello messages of the abbreviated
handshake. This would provide an explicit link between the resumption
handshake and its original full handshake, and hence prevent the
renegotiation attack described above.

We welcome comments and suggestions.
-Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti

[1] http://mitls.org
[2] https://secure-resumption.com
[3] RFC5746: Transport Layer Security Renegotiation Indication Extension
[4] The Compound Authentication Binding Problem (draft-puthenkulam-eap-binding-04)
[5] RFC5929: Channel Bindings for TLS
[6] RFC5705: Keying Material Exporters for Transport Layer Security

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 3 Mar 2014 16:30:03 +0000

Hi

Great work, and much kudos to Karthik and the team for finding this
attack, documenting it, and engaging in its responsible disclosure.

I think it's important to highlight one issue in the high-level
description given by Karthik, below. Although the 3-step attack is
described as a "server-based man-in-the-middle attack", the attacking
server M, at the very end of the attack after step 3, does NOT end up
knowing the keys being used by the attacked client and server, C and S.

Rather, an application running at C might end up using TLS-protected data
that was supplied by M in step 2 of the attack as if it came from S (or
vice-versa). This is a comparable attack to the original renegotiation
attack of Ray&Dispensa and Rex.

So the text in Karthik's message:

> During the third handshake, M is able to authenticate as C to S and as S
>to C 

is not correct, as far as I can see - for the 3rd step of the attack, it
seems that M just passes messages backwards and forwards and ends up NOT
knowing the keys shared by C and S. Any authentication protocol is
vulnerable to a "message passing" attack of this type in which the
adversary simply acts as a wire, and it's not considered an attack on such
protocols.

What matters here is how a server application running at S interprets data
that may have been sent under TLS protection in the first 2 steps in the
attack: it may assume it came from C when in fact it came from M.

> ...
> Both handshakes complete with new mutually-authenticated sessions and
>record keys.

Indeed, it's correct that C *is* connected to S and S *is* connected to C
after step 3! (not just that they "think" they are so-connected).

Cheers

Kenny

On 03/03/2014 15:20, "Karthikeyan Bhargavan"
<[email-masked]> wrote:

applications in Tuesday¹s working group meeting. These attacks were

More details are at https://secure-resumption.com
<https://secure-resumption.com/> [2]

Scenario
======
Consider a client C that normally authenticates to a server S using a
client certificate.  If C uses the same certificate to authenticate to
a malicious server M, then we show that M can use C¹s certificate to
authenticate its own connection to S.

Triple Handshake Attack
================
I¹ll briefly summarise the attack below for an initial RSA key
exchange.  The webpage [2] has diagrams that will be easier to follow,
describes more attack variants, and provides some disclosure status.

Step 1. (Initial Handshakes C-M, M-S)
- C connects to M and M connects to S, both handshakes use RSA.
- M forwards C¹s and S¹s client hellos to each other.
- M receives an encrypted PMS from C and reencrypts it towards S.
- Both handshakes complete with new sessions and record keys.
  Both sessions have the same master secret, random nonces, and session id.
  (M knows the master secret and record keys since it participated in both
handshakes)

Step 2. (Session Resumption C-M, M-S)
- C resumes its session with M on a new connection.
- M resumes its session with S on a new connection.
- M forwards all the abbreviated handshake messages unchanged between C
and S.
- Note that the RI extensions on both handshakes are empty,
  since it is the first handshake on the connection
- Both handshakes complete with new record keys (and reuse old sessions)
  Both connections have the same record keys and handshake logs (verify
data)
  (M still knows the record keys and can send messages in either
direction.)

Step 3. (Renegotiation C-M-S)
- S requests M for renegotiation with client certificate.
  M requests C for renegotiation with client certificate.
- M forwards all renegotiation messages unchanged between C and S
- Note that since the handshake logs in the preceding handshake were the
same, 
  the RI extensions on both handshakes will be the same.
- Both handshakes complete with new mutually-authenticated sessions and
record keys.
  C now thinks it is connected to S and S thinks it is connected to C.
  (M does not know the new record keys but its previous messages to S on
the same connection
  may be treated as authenticated by C.)

Countermeasures 
===========
During Step 3, C has a connection on which it first received M¹s
certificate and later S¹s certificate. If C refuses to accept this
change of server identity, then it can prevent Step 3 of the
attack. Indeed, we recommend mainstream web browsers and HTTPS
libraries should systematically forbid the change of server identities
during renegotiation.

We¹ve implemented this extension in OpenSSL without much difficulty.
Changing the master secret derivation may seem radical, but we believe
it is the main way to counter future attacks that may rely on the
session synchronization (step 1) that we exploit here.

[1] http://mitls.org <http://mitls.org/>
[2] https://secure-resumption.com <https://secure-resumption.com/>
[3] RFC5746: Transport Layer Security Renegotiation Indication Extension
[4] The Compound Authentication Binding Problem
(draft-puthenkulam-eap-binding-04)
[5] RFC5929: Channel Bindings for TLS
[6] RFC5705: Keying Material Exporters for Transport Layer Security

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 03 Mar 2014 16:36:43 +0000

> More details are at https://secure-resumption.com [2]

I'll just repeat an observation I made at the time. I'm assuming this is still
valid.

If the client verifies certificate chains whenever they are presented[1] the
attacker needs a certificate and corresponding private key the client trusts,
typically from a public CA. If not the client will typically reject the
certificate and abort the handshake immediately.

Assuming due diligence by the CA anyone detecting the attack will know the
identity of the attacker or more accurately the identity presented to and
checked by the CA.

If the client checks the hostname against the certificate whenever a
certificate is presented[2] then additionally the attacker needs a certificate
with the same hostname as the attacked server.

Steve.
1. As opposed to letting everything through and verifying chains after the
handshake is complete. Not something I'd consider wise...
2. This isn't always the case. Some applications check the hostname only after
the handshake has completed.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 3 Mar 2014 16:46:51 +0000

> attack of Ray&Dispensa and Rex.

Yes, indeed, the impact of our renegotiation attack is comparable to the 2009 renegotiation attacks.
In fact, the setup of our attack is closer to Rex’s version than Ray’s version:
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

> as far as I can see - for the 3rd step of the attack, it

I would note that the renegotiation handshake we are speaking about is not exactly a standalone authentication protocol. It is the second handshake on a connection, with different client or server identity than the first handshake. This leaves room for confusion: should an implementation associate the connection to the first set of principals or the second? 

> after step 3! (not just that they "think" they are so-connected).

Kenny, you seem to suggest that only the second should be considered. Common web browsers and HTTPS libraries only consider the first. It is interesting to try and understand which is the right answer here.

-Karthik

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Mar 2014 08:47:20 -0800

>                                         "extended master secret",

This would prevent the use of false start, would it not?

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 3 Mar 2014 16:54:41 +0000

Karthik,

Sorry, I was just trying to clarify the impact of your attack for
non-experts - the suggestion that it is a MITM attack might make some
readers think that M ends up knowing the keys at the end of the attack.

I totally agree that it's unclear as to what "bindings" should be assumed
by the protocol participants at the end of step 3.

As I said, and I'll reiterate - great work guys!

Cheers

Kenny

On 03/03/2014 16:46, "Karthikeyan Bhargavan"
<[email-masked]> wrote:

>I would note that the renegotiation handshake we are speaking about is
>not exactly a standalone authentication protocol. It is the second
>handshake on a connection, with different client or server identity than
>the first handshake. This leaves room for
> confusion: should an implementation associate the connection to the
>first set of principals or the second?
>
>
>
>Kenny, you seem to suggest that only the second should be considered.
>Common web browsers and HTTPS libraries only consider the first. It is
>interesting to try and understand which is the right answer here.
>
>
>-Karthik
>
>
>
>
>

---

From: Adam Langley <[email-masked]>
Date: Mon, 3 Mar 2014 12:06:45 -0500

> This would prevent the use of false start, would it not?

I don't believe so, unless I've missed something. This doesn't delay
the master-secret's availability and so I don't see that it would
impact False Start.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Mon, 3 Mar 2014 20:37:37 +0100 (CET)

> the handshake has completed.

An application client that is using a TLS library _without_ callbacks,
and requests a blocking TLS handshake to be performed, will only get to
see the server certificate after the handshake has completed.

While the X.509 cert chain validation might be performed in-band
by the TLS stack, the rfc2818 Section 3.1 server endpoint
identification is left up to the application caller.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Mon, 3 Mar 2014 21:07:04 +0000

Ø  I would note that the renegotiation handshake we are speaking about is not exactly a standalone authentication protocol. It is the second handshake on a connection, with different client or server identity than the first handshake. This leaves room for confusion: should an implementation associate the connection to the first set of principals or the second?

When a renegotiation happens, the TLS client must validate the newly negotiated parameters, including the server cert, the cipher suites, Finished hash, etc. A TLS client that neglects to validate the server certificate after renegotiation simply has a bug.

It appears that the attack described is only feasible when two implementation defects are present:

1.       TLS implementation error in the client (failure to validate the server cert),  and

2.       A server application that associates data received from an unauthenticated client with the data received after enabling TLS client authentication.

While we cannot prevent the latter at the TLS protocol layer, I believe fixing the bug in the TLS client effectively thwarts this attack.

Thanks,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Karthikeyan Bhargavan
Sent: Monday, March 3, 2014 4:47 PM
To: Paterson, Kenny
Cc: [email-masked]
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption

Yes, indeed, the impact of our renegotiation attack is comparable to the 2009 renegotiation attacks.
In fact, the setup of our attack is closer to Rex's version than Ray's version:
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

-Karthik

...

Cheers

Kenny

On 03/03/2014 15:20, "Karthikeyan Bhargavan"
<[email-masked]<mailto:[email-masked]>> wrote:

Scenario
======

Triple Handshake Attack
================

Countermeasures
===========

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Mar 2014 13:55:32 -0800

Dear all,
This is the third time we've had a bug in the protocol in an area that was
supposedly fixed. In this case it's the interaction between two different
flows breaking a tacit assumption in the state machine, and the complex
semantics of session renegotiation, both of which were previously noticed
in 2009 with the Rex/Ray attack.

There are two ways to make apparently secure systems: make the system so
simple it can't have flaws, and make it so complicated we can't find the
flaws. Luckily the authors are completing a verification which should
hopefully ensure that there aren't any more flaws. Unluckily we have
decided to make TLS 1.3. Will TLS 1.3 actually make a protocol so simple
that it has no flaws? Or will it continue to be filled with surprises?

Furthermore,  I would like to ask the chairs what they plan to do about the
clear issues in the process that this has exposed, and why users should
continue to trust TLS with confidential information.

Username password and cookies continue to be widely used in part because
client authentication in TLS has not had a good run. We need a new
mechanism for client authentication.

Sincerely,
Watson Ladd

---

From: Adam Langley <[email-masked]>
Date: Mon, 3 Mar 2014 17:07:05 -0500

> implementation defects are present:

That's not an unreasonable characterisation of the renegotiation-based
attacks, but the problem with tls-unique is more fundamental.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Tue, 4 Mar 2014 00:13:15 +0100 (CET)

Andrei Popov wrote:
>
> Ø  I would note that the renegotiation handshake we are speaking about
> is not exactly a standalone authentication protocol.

But we know since at least late 2009 that TLS server that use/allow
delayed authentication through renegotiation abuse the rengotiation
handshake in EXACTLY such a fashion, they have been turning the mere
technical successful completion of a TLS renegotiation handshake into
an OTP scheme that authorizes a previously received, unauthenticated
request.
 
As I wrote in my 2009 posting about the problem:

  The victim [] TLS server has no means to detect that it has been
  attacked.  Whether the TLS client cares about receiving a different
  TLS server cert in the renegotiation handshake and what it will
  do about it -- if anything, depends entirely on the application
  of the TLS client.  At the TLS level, everything looks just fine.

  I'm not sure that all clients will repeat the server authentication.
  They can be expected to verify the server certificate before sending
  off their request.  Depending on the API architecture, they may not
  always realize or care that a renegotiation was performed while they
  were sitting on SSL_read() waiting for the server reply.

  And even if they decide to perform an additional server endpoint
  identification, they might be doing it after the renegotiate
  handshake has been successfully completed -- a point where the
  victim [] TLS server has started performing the action requested
  in the anonymous request from the MITM.

Because of the nature of this problem, that the server reinterprets
a technically successful renegotiation handshake into an OTP authentication
scheme to authenticate a previously received, unrelated and unauthenticated
request, the following guidance was added to rfc5746:

  http://tools.ietf.org/html/rfc5746#section-5

   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.

   TLS implementations SHOULD provide a mechanism to disable and enable
   renegotiation.

   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).

   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. 

>
> It is the second handshake on a connection, with different client or
> server identity than the first handshake. This leaves room for confusion:
> should an implementation associate the connection to the first set
> of principals or the second?

The guidance from rfc5746 should be clear.

The server which is doing delayed authentication through renegotiation
is still comitting the sin here.  Currently, it dumps the problem and its
mitigation for this risky server-side behaviour entirely on the client.

> 
> When a renegotiation happens, the TLS client must validate the newly
> negotiated parameters, including the server cert, the cipher suites,
> Finished hash, etc. A TLS client that neglects to validate the server
> certificate after renegotiation simply has a bug.

The problem can easily be an "added value" provided transparently by the
underlying TLS client implementation, and the application client may not
be aware that it has to cover the ass of the server, who is abusing
the renegotiatiation handshake for delayed authentication.

> 1.  TLS implementation error in the client (failure to validate

After rfc5746 this would be a defect of an rfc5746-enhanced TLS client
to "transparently" replace the server cert after the first handshake
completed without being explicitly authorized by the application caller
to do so.

> 
> 2. A server application that associates data received from an
>    unauthenticated client with the data received after enabling
>    TLS client authentication.

Requesting TLS clients through renegotiation rather than upfront seems
to be pretty common (it even seems to be the default in IIS 7.x),
and some browser even have small difficulties being asked for a
certificate upfront (such as Safari).

> 
> While we cannot prevent the latter at the TLS protocol layer,
> I believe fixing the bug in the TLS client effectively thwarts this attack.

The original renegotiation problem and the newly describe session resumption
problem are very similar:  flawed assumptions about a cryptographic binding
that doesn't exist.  But until you write down the exact properties and
think about it, you may not notice the problem.  As soon as you write it
down, the problem becomes obvious.

The abbreviated TLS handshake authenticates only the MasterSecret.
But the MasterSecret is derived exclusively from ClientHello.random,
ServerHello.random and the keyExchange transform, there is no cryptographic
binding to any identities that are authenticated during the TLS handshake.

So the fix of the abbreviated TLS handshake needs to account for the
(re-)authentication of the identities of the original full handshake,
either by modifying the MasterSecret computation or by authenticating
the original full handshake during the abbreviated TLS handshake
through a TLS extension similar to how the renegotiation_info extension
does this in the renegotiation handshake.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Mar 2014 18:32:36 -0500

> both of which were previously noticed in 2009 with the Rex/Ray attack.

Hmm…  Four-plus years is a pretty darn good record, I’d say.

> why users should continue to trust TLS with confidential information.

At the risk of being flip or snarky, because it’s the only thing we have. Therefore everyone uses it and therefore there are lots more “interesting” places for an adversary to attack.  As the old joke goes, I don’t have to outrun the bear, I just have to outrun you.

At one point, the most common way banks transferred money amongst themselves was PGP signed data over FTP. I don’t know if it’s still true. The US Federal Reserve requires TLS over direct leased lines for banks doing transactions more than $10Million.

> Username password and cookies continue to be widely used in part because client authentication in TLS has not had a good run.

You mean because client certs are not widely deployed, right?  Perhaps some name/pbkdf2 is better?
                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Mar 2014 19:53:05 -0800

> Hmm…  Four-plus years is a pretty darn good record, I’d say.

Protocols are not houses. They do not get mildew under the eves. Ants
and termites do not eat the foundation. Unless you are an extreme
intuitionist, TLS was as broken in 2009 as it was today. The pattern
of decision making by this WG is clear: mistakes are noticed, and the
fix doesn't actually cut to the core of the issue. This needs to end.
I'll submit a TLS 2 draft that will be formally verified, easy to
implement (modulo X509), and provide the secure channel semantics that
TLS still doesn't. The big nonsecurity payoff: very few round trips.
(1 if lucky, 2 if not)

> At the risk of being flip or snarky, because it’s the only thing we have.
> Therefore everyone uses it and therefore there are lots more “interesting”
> places for an adversary to attack.  As the old joke goes, I don’t have to
> outrun the bear, I just have to outrun you.

I'm not sure if that's comforting or alarming. As the old saying goes,
if you don't know who the sucker is, it's you. That's why I never play
poker thanks to application of Zorn's lemma. (Well, induction)

>
> At one point, the most common way banks transferred money amongst themselves
> was PGP signed data over FTP. I don’t know if it’s still true. The US
> Federal Reserve requires TLS over direct leased lines for banks doing
> transactions more than $10Million.

There's your answer: the Fed will not trust TLS with amounts over $10
million. Anyone here about to retire? My suggestion: call your broker
and never use their website ever again. Because if the Fed gets robbed
of $10 million they can print more.

>> client authentication in TLS has not had a good run.
>

The idea was that the browser would make certs and use them
transparently: this was the idea behind Channel ID. But that got
broken in this latest attack, unless you used ECDHE only.

Password based derivations don't solve the phishing problem, unless
you do something somewhat clever. (mix with hostname, then derive?)
But thanks to backwards compat, a phisher can always get the password.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Mar 2014 23:11:34 -0600

[Cross-posting to [email-masked].  Please drop one of tls or kitten
when responding.  For KITTEN readers, see the TLS list archives,
there's an MITM vulnerability when using tls-unique in conjunction
with session resumption.]

> attacks, but the problem with tls-unique is more fundamental.

The problem for tls-unique is more fundamental indeed, and Andrei's
characterization is not applicable.

We should talk about how to fix tls-unique.  The best fix may be to
keep track of the original (non-resumed) connection's tls-unique CB
and add that to the resumed connection's tls-unique CB.  This requires
adding to the session cache on the client side.

In the short-term, client and server applications should not permit
session resumption prior to channel-bound authentication (if using
tls-unique).  Except that, of course, how is the application to know
if session resumption is involved?  Assuming that it can't know or
prevent the use of session resumption, I'd say that tls-unique is just
simply not to be used.  We should publish a new tls-unique that
doesn't have this problem.

Nico
--

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Mar 2014 14:03:15 +0000

> identification is left up to the application caller.

A stack might have an option to check the hostname as part of the in-band cert
validation and, on failure, abort the handshake at that point just like any
other validation error.

For example OpenSSL 1.0.2 can do that but previous versions do not. Since that's
an unreleased version it's likely no existing clients use that option.

I performed a few checks with an experimental option to change the server
certificate during renegotiation, which I believe simulates the attack
mechanism. If the client checks certificates in band then all versions choke
with a verification error if a chain is untrusted. For 1.0.2 only it also chokes
if the chain is trusted but the hostname doesn't match.

Steve.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Mar 2014 15:23:41 +0000

> if the chain is trusted but the hostname doesn't match.

This is an interesting option.  I like the general idea, but wonder
what "hostname doesn't match" means in this case.

To provide some context, in HTTP/2 we are considering having multiple
names share the same connection, as long as they are covered by
wildcards or additional subjectAltName values.  You might start out
looking for "foo.example.com", but as long as you have "*.example.com"
or "bar.example.com" in subjectAltName, you will proceed with requests
to "bar.example.com" on that connection.

I think that it would be unlikely that a renegotiated certificate
would include some names from a previous certificate, but not others,
but that might be a problem if an implementation fixates on a single
name.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Mar 2014 16:05:14 +0000

> but that might be a problem if an implementation fixates on a single

Well in the specific case of OpenSSL a hostname is supplied via the API and that
is checked against the server certificate whenever it is presented. So it would
allow the certificate to change but an attacker would need a trusted certificate
matching the server's hostname. If they have that they can MITM the server
(provided it doesn't support client authentication) anyway.

It has been suggested that clients could be stricter and prohibit changes of
server certificate during renegotiation entirely, if not outright at least by
default.

I'd be interested if anyone knows of examples where the server certificate does
have to change during renegotiation and how common that practice is.

Steve.

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Mar 2014 11:11:10 -0500

> have to change during renegotiation and how common that practice is.

Chrome outright rejects renegotiations where the leaf certificate
changes and we've had no reported issues.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Tue, 4 Mar 2014 20:56:10 +0100 (CET)

Adam Langley wrote:
> Dr Stephen Henson <[email-masked]> wrote:
>>
>> I'd be interested if anyone knows of examples where the server certificate
>> does have to change during renegotiation and how common that practice is.
> 

I'd be glad to enforce such a policy, but I'm less confident that
it'll work that smoothly.  While it would be intuitively obvious
that a server that replaces his server credential/cert should also
dispose of his server-side TLS session cache contents along with
the old credential/cert, it largely depends on how the stuff
is implemented.

There seem to be some funny server-side TLS session cache designs
out there in the wild.

A while ago I noticed that it was possible to resume a TLS session
originally established with https://www.google.com/ when proposing
that session for resumption to https://docs.google.com/ (not using
any TLS extension here, neither SNI or TLS session tickets).

However these two servers/services use distinct server certificates,
and the server certificate returned by https://www.google.com/ fails
rfc2818 section 3.1 server endpoint identification for docs.google.com,
which is why my SSL wrapper noticed that behaviour (the client should
not have proposed that session resumption in the underyling scenario,
so fixing it was straightforward).

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 04 Mar 2014 20:16:50 +0000

> changes and we've had no reported issues.

If a client currently doesn't want to leak SNI to a passive attacker and
is willing to burn roundtrips, it can make a non-SNI TLS handshake to
the server (accepting whatever certificate is given) and then
immediately trigger renegotiation with the SNI header.

tstclnt (from mozilla's NSS) has command line options to offer different
SNI values at renegotiation.

If chrome doesn't do this, it's reasonable for it to reject changed EE
certs on renegotiation.  But that doesn't rule out this use case.

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Mar 2014 14:43:14 -0600

Scott Cantor points out -rightly- that tls-server-end-point channel
bindings also have a problem if resumption+renegotiation can result in
the session over which authentication takes place to have the correct
server certificate.

Nico
--

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 4 Mar 2014 18:25:00 -0800

> identification is left up to the application caller.

I certainly agree that there's an issue here, but I don't see how (in the
context of the Triple Handshake Attack) this is about whether a handshake
has completed.  Maybe what you (Steve and Martin) mean is that some
applications only check once, after the *initial* handshake on the
connection has completed (not checking again if another, renegotiation,
handshake completes)?

Bodo

---

From: Xuelei Fan <[email-masked]>
Date: Wed, 05 Mar 2014 12:09:07 +0800

>> what "hostname doesn't match" means in this case.
JSSE enabled the hostname checking during handshaking for HTTPS and 
LDAP.  If hostname doesn't match, the handshaking is terminated immediately.

> have to change during renegotiation and how common that practice is.
I was wondering, if the cipher suite is changed from RSA cert based to 
EC cert based (and vice versa), the server certificate would have to 
change accordingly.  Not sure about the case in practice.

Xuelei

---

From: [email-masked] (Martin Rex)
Date: Wed, 5 Mar 2014 13:56:42 +0100 (CET)

I've just started wondering:  Is the real problem acutally
worse than described, and will changing the Master Secret computation
actually _not_ fix the renegotiation problem?

> does this in the renegotiation handshake.

The only "non-static" data covered by the Finished handshake messages of
the abbbreviated TLS handshake (i.e. that goes into the renegotiation_info
of the resumed TLS handshake are):

    ClientHello.random
    ServerHello.random
    ClientHello.session_id == ServerHello.session_id

In particular, there is *NO* dependency on the MasterSecret, so
the attack by an MitM should be possible, even if the MasterSecrets
differ between the two sessions that are merged (I never had a
requirement in my attack scenario that the MasterSecrets are the
same; in fact I wasn't even aware that it was possible to
create two SSL sessions with identical MasterSecrets & traffic keys
when I described my attack).  The MitM will only have to
decrypt and re-encrypt the data during the original two sessions.

The handshake_message hash does not "see" the encryption, it operates
on the plaintext only.

So it seems to me that changing the MasterSecret computation will
not help.  We need a TLS extension on the abbreviated TLS handshake
that authenticates the original full handshake, such as the
renegotiation_info from that handshake.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Wed, 5 Mar 2014 08:07:22 -0500

> any TLS extension here, neither SNI or TLS session tickets).

Yes, both of these services are terminated by the same frontend
machines and they shared a session cache.

Completely unrelated to this matter, you should find that's no longer
the case. Sessions for www.google.com should no longer be resumable
for docs.google.com.

Cheers

AGL

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 5 Mar 2014 14:07:36 +0100

>     ClientHello.session_id == ServerHello.session_id

Renego Indication uses the client and server verify data:

verify_data = PRF(master_secret, label, Hash(handshake_message)

So, it is bound to the master_secret

-K.

---

From: Karthik Bhargavan <[email-masked]>
Date: Wed, 5 Mar 2014 14:09:20 +0100

After my talk at the meeting, its worth summarizing comments on the triple
handshake attack and its impact on client-authenticated TLS renegotiation.

In the common case (e.g HTTPS) where a server presents  a certificate in
both the initial handshake and during renegotiation, it would be enough for
the client to verify that the certificate doesn't change. (More precisely,
the client needs to verify that the principals represented by both
certificates are equally trustworthy.)

There are other cases, and I'd be curious to know how common they are, when
one or both handshakes does not have a server certificate. These would be
more difficult to fix with a general TLS library-level policy.

Typical examples (from discussion at the meeting):

- Initial handshake uses DH_anon or a self-signed server cert
  and renegotiation uses the real server certificate

- Initial handshake uses a server certificate,
  and renegotiation uses PSK or SRP to authenticate the user

In the first case, I guess the purpose is to protect the server name from
passive attackers. In the second, the purpose is privacy for the user's
SRP/PSK identity.

In both cases, if both handshakes happen on the same connection, RFC5746
(renego indication) gives us a pretty strong guarantee that the principals
on both ends do not change. In effect, the second handshake retroactively
authenticates the first.

The triple handshake attack shows that this nice guarantee does not hold if
there is session resumption between the two handshakes.

I can't think of easy implementation-level ways of fixing the DH_anon and
PSK/SRP cases.

Best,
Karthik

On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan <[email-masked]> wrote:

> EC cert based (and vice versa), the server certificate would have to change
> accordingly.  Not sure about the case in practice.
>
> Xuelei
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: [email-masked] (Martin Rex)
Date: Wed, 5 Mar 2014 14:40:53 +0100 (CET)

> So, it is bound to the master_secret

*Blush*

You're correct.  I'm sorry for the confusion.

-Martin