Does mutual authentication have any impact on MiTM possibilities?

Question

When doing a Man-in-the-middle attack against a classic one-way authentication server, the attacker just have to:

• Use a certificate credible enough to be trusted by the victim,
• Act as a standard client toward the real server, relaying victim's requests.

However, I was wondering if using TLS mutual authentication could have an impact in this scheme?

Can an attacker:

1. Impersonate the server during the server authentication step,
2. Initiate the TLS handshake toward the real server,
3. Relay the communication between the real server and the victim (challenges, answers, ...) to pass the client authentication step,
4. And then still be in measure to decipher, spy and alter the communication between the two hosts?

Is such a scenario always possible, is it maybe dependent on the cipher suite used?

In particular in step 3) the attacker is forced to forward genuine handshake data (even if signed by his own fake cert) from the server to the client, may this handshake data be used to establish a secret between the genuine client and server preventing further action from the attacker (some Diffie-Hellman-Merckle magic for instance) or invalidate the session (each parts having missing secrets, no one is able to pursue the communication anymore)?

Answer 1

A Man-in-the-Middle really is simultaneous double impersonation: the attackers poses as a fake server when talking to the client, and as a fake client when talking to the server. The beauty of the MitM is that since the impersonation is simultaneous, the attacker can hope to reuse answers from the genuine client or server, when responding to the genuine server or client.

Details matter. TLS uses X.509 certificates, and uses them properly, which makes it robust against some possible attacks.

Suppose that the attacker somehow managed to pose as a fake server, e.g. by bribing or compromising a CA into issuing to him a fake certificate, or, more probably, by convincing the human user to disregard the browser's warning about the server certificate not being valid. The attacker now relays the information back and forth between client and server. The server now wants to authenticate the client with some password-based protocol (e.g. the simple and very common "show the password" protocol), inside the TLS tunnel. The attacker can simply let that protocol flow, and, once it is done and the server is content, really hijack the data stream and inject his own commands.

Now, try that again, but with a client certificate. When a client certificate is used in SSL/TLS, the client demonstrates his mastery of his private key by computing a signature over a "challenge" from the server. Crucially, this "challenge" really is the concatenation of all preceding handshake messages (see the standard). In particular, the server's certificate is part of what is signed by the client. Our attacker could reach that point in the MitM by feeding a fake server certificate to the client -- that is, a certificate distinct from what the genuine server sent. Thus, what the client signs and what the server uses to verify that signature will be distinct sequences of bytes, and the signature will not match.

Summary: if by "mutual authentication" you mean "authentication with a client certificate, handled at the SSL/TLS level", then that authentication will prevent the MitM. Or, more precisely, the attacker will succeed only if he manages to obtain a fake server certificate that will convince the client and a fake client certificate that will convince the server.

However, if the two authentications are not coupled (as what happens in the password-within-TLS protocol), an attacker that succeeds at impersonating the server can easily turn that into a full MitM by reusing the client answers.