New flaw found in TLS

New flaw found in TLS cryptographic protocol. The flaw was uncovered by security researchers at the French National Institute for Research in Computer Science and Control (INRIA). The security researchers explain on their website:

TLS Protocol Weaknesses

We identify four vulnerable features of the TLS protocol:

1. In the RSA handshake, a client C sends the pre-master secret (PMS) to a server A encrypted under A‘s public key. If A is malicious, it can then (acting as a client) send the same PMS on a new connection to a different server S. The two connections can be further synchronized, because A can also use the same client and server random values and session identifier (SID) on both connections and thus obtain two sessions that share the same identifier, master secret (MS) and connection keys, but are between different pairs of principals; notably, the server certificate differs. In key exchange terminology, this is an unknown key-share attack (UKS); by itself it is not a serious vulnerability, but we amplify it below.
2. In the DHE handshake, the server A gets to choose the Diffie-Hellman group parameters. If A is malicious, it can choose a non-prime group such that the resulting PMS is fully under its control. Consequently, like with RSA, A can mount a man-in-the-middle attack between a client C and server Sto obtain two sessions that share the same SID, MS, and connection keys (another UKS attack).
3. Session resumption on a new connection uses an abbreviated handshake that only verifies that the client and server share the same MS, ciphersuite, and SID (or server-issued session ticket, if used). Notably, it does not reauthenticate the client and server identities. Hence, if a malicious server Amounts a UKS attack to obtain two sessions (one with C and the other with S) that share the same MS, ciphersuite, and SID, it can forward the abbreviated handshake unchanged from one connection to the other. Notably, the abbreviated handshake log provides no guarantees that the original handshakes were the same. The secure renegotiation indication extension only binds handshakes on the same connection, but does not apply if the session is resumed on a new connection.
4. During renegotiation, both the server and client certificates can change. This is allowed by TLS (and supported in its main implementations) but no definitive guidance is given to applications on how to deal with such changes. Some implementations associate a connection with the first certificate, others with the last, but neither of these may be the best choice.

Triple Handshake Attack

We describe the attack on a client C and server S that enable the RSA key exchange and support both resumption and renegotiation. The server is willing to accept connections from clients that are initially unauthenticated but subsequently use certificate-based authentication during renegotiation. (Other variations of the attack below apply if the client and server use DHE or always force client authentication.)