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

[Liz meeks <[e-mail]>]

Please stop sending me these emails
On Mar 3, 2014 8:47 AM, "Karthikeyan Bhargavan" <
[e-mail]> wrote:

>
> 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.
>
>
> 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
> 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.
>
>
> 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?
>
> 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).
>
>
> 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
>
>
>
> 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.
>
> The more accurate description from Karthik's text is this:
>
> Step 3. (Renegotiation C-M-S)
>
>
> ...
> 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.)
>
>
>
> 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"
> <[e-mail]> wrote:
>
> 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
> <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 <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
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>