Do client certificates provide protection against MITM?

A man-in-the-middle attack is when an attacker inserts himself between client and server, and impersonates the client when talking to the server, and impersonates the server when talking to the client. "Impersonation" makes sense only insofar as there is an expected peer identity; you cannot impersonate an anonymous client.

From the point of view of the server, if the client shows a certificate and uses his private key as part of a CertificateVerify message (as described in the SSL/TLS standard, section 7.4.8), and the server validates the client certificate with regards to a set of trust anchors which does not include an hostile or incompetent root CA, then the server has a guarantee that it is talking to the right client (the one identified by the client certificate). The guarantee holds for all subsequent data within the connection (it does NOT extend to data exchanged prior to the handshake where the client showed a certificate, in case that handshake was a "renegotiation").

This means that a client certificate indeed protects against the specific scenario of a rogue CA injected in the client trust store. In that scenario, the "attacker" succeeded in making the client trust a specific root CA that is attacker-controlled, allowing the attacker to run a MitM attack by creating on-the-fly a fake certificate for the target server (this is exactly what happens with some "SSL content filtering" proxies that are deployed in some organizations). Such MitM breaks client certificate authentication, because what the client signs as part of a CertificateVerify message is a hash computed over a lot of data, including the server certificate -- in the MitM scenario, the client does not see the "right" certificate and thus computes a wrong signature, which the server detects.

From the point of view of the client, if a client certificate was requested by the server and shown by the client, then the client knows that the true server will detect any MitM. The client will not detect the MitM itself; and if there is an ongoing MitM attack, then the client is really talking to the attacker, and the attacker will not tell the client "by the way, you are currently being attacked".

In that sense, a client certificate prevents a true MitM (aka "two-sided impersonation") but does not protect against simpler frauds (one-sided impersonation, i.e. fake servers).

Bottom line: In the presence of SSL with mutual client-server authentication (both send a certificate to the other), a successful MitM requires the attacker to plant rogue CA in both the client and the server. However, if the attacker can plant a rogue CA in the client only, the client is still in a rather bad situation (even though a complete MitM is thwarted).

A client-side certificate , as does any secure public-private key technology, will provide protection against MITM.

The main problem with client side certificates on this end is phishing or the attacker otherwise retrieving the certificate/private key from the end-user, which is usually much easier than from a server because end-users don't know much about security. When an attacker has retrieved the pk/certificate he can execute a MITM attack by relaying all information coming from the client, since he can just re-encrypt the data using the pk/certificate.

Note that for a fully successful MITM attack both client and server pk's/certificates are needed, since otherwise one part of the communication cannot be decrypted.