1

I understand the question of client certs and MITM attacks has been asked several times, but I don't believe this specific scenario has been answered.

It was my (seemingly incorrect) assumption, that the presence of a client cert would allow the server to ensure the client was correctly consuming its server certificate and not a fake one presented by a MITM (by receiving a response from the client that only the client should have sent, and that only the server could have sent to the client).

Some testing I have done shows that if the client does not correctly check the server certificates CA, then you can MITM.

I understand that a failure on the client to not correctly identify the server certificate is the point of error, but what can a server do to ensure a client is fulfilling this obligation?

  • Absolutely nothing. – Steve Feb 3 '14 at 17:12
  • Could you expand a little on the testing you have done? I thought that this arrangement did provide some protection against MITM. – paj28 Feb 3 '14 at 18:55
2

The certificate-based client authentication in SSL takes the following format: the client shows its own certificate chains, and computes a signature over all the handshake messages previously exchanged. These handshake messages include the message where the server sends its certificate chain to the client.

In that way, the server can make sure that the client (the one who owns the shown client certificate) really saw the correct server certificate, not a fake one. In that sense, requiring certificate-based client authentication can prevent a true Man-in-the-Middle (if your "testing" shows otherwise then either you broke SSL, or there is something subtly wrong in your test situation). However, the Devil is in the details...

A MitM attack is a simultaneous double impersonation: the attacker runs both a fake server (when talking to the client) and a fake client (when talking to the server). A true MitM is prevented as long as either the client or the server correctly verifies the certificate from the peer, which entails validating the certificate (verifying that it has been issued by a trustworthy CA, and so on) and also using the name in the certificate as identity of the peer (a client connects to some IP address but the certificate is about a guarantee for a server name).

However, there are other kinds of attack which, while not being MitM in a strict sense, can be troublesome. For instance, if the client does not perform a correct validation of the server's certificate, then the attacker can run a fake server and talk to the client. The genuine server is not involved at all ! That kind of thing is not a genuine MitM, but can be sufficient to recover some client secrets (the client believes that it connected to the correct server, and then sends sensitive data through the tunnel).

There is nothing that the server can do to ensure that a client always validates the server's certificate properly -- in particular when the server is not contacted at all, because the client is connecting to a fake, attacker-operated server. At best, the server can make sure, through certificate-based client authentication, that the client for this time uses the correct server public key for its cryptography.

  • Thank you so much for the response. I didn't actually do the original work but was told that improper server cert validation allowed a page to be displayed and for user credentials to be seen in plain text between the client and a real server. When you say "and computes a signature over all the handshake messages previously exchanged" - is this only the client? Because if it happened on the server it would surely fail as the original server cert was faked by the mitm? – Yan Feb 27 '14 at 22:01
0

The key point is that a fake server cannot impersonate the client.

Suppose you want to connect to goodguy.com and send your client cert. But because of an attempted MITM attack, you actually connect to badguy.com, and because you don't check the server certificate, you don't notice, and you authenticate using your client cert. At this point, badguy.com can show you any web page they like, so they could give you misleading information and attempt to capture information from you. But what they cannot do is connect to goodguy.com and use your client certificate to impersonate you.

The reason that badguy.com can't relay your authentication is because SSL certificates are based on public key cryptography. When you authenticate you prove that you have the private key associated with the certificate, but you do not reveal the private key.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.