More details are at https://secure-resumption.com 
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  but by injecting session resumption between the two full handshakes, we are able to bypass the renegotiation countermeasure.
I'll briefly summarise the attack below for an initial RSA key exchange. The webpage  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)
Step 2. (Session Resumption C-M, M-S)
Step 3. (Renegotiation C-M-S)
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.
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  or channel bindings  or exports TLS keying material  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",
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 ) 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
 http://mitls.org  https://secure-resumption.com  RFC5746: Transport Layer Security Renegotiation Indication Extension  The Compound Authentication Binding Problem (draft-puthenkulam-eap-binding-04)  RFC5929: Channel Bindings for TLS  RFC5705: Keying Material Exporters for Transport Layer Security