I'm looking for a way to protect clients from a MITM attack without using a VPN, and ToR. My thought is that client certificates might do the job, but I'm not entirely sure since not too much server or browser support has been extended in this area.

Can anyone tell me if Client Certificates provide any MITM protection?

Is that protection just for the authentication exchange or does it protect the entire TLS session?

Is there any good resource for studying this in deep detail?

  • I guess that with browser based certificates you mean SSL certificates? Or do you mean some form of certificate I'm not aware of?
    – dtech
    Commented Dec 28, 2012 at 23:40
  • @dtech I clarified the question. I'm referring to these certificates: security.stackexchange.com/questions/1430/… Commented Dec 28, 2012 at 23:54
  • TOR is your enemy in this scenario. If you are not using SSL now and are handling user sessions through this connection all traffic can be MITM'ed or sniffed at the exit node or anywhere else en route.
    – Mark S.
    Commented Dec 30, 2012 at 6:50

3 Answers 3


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).

  • Should I infer that mutual auth sessions are safe from a ToR user to a HTTPS based server? (assuming the client side key was already generated and issued out of band) Commented Dec 29, 2012 at 13:49
  • 1
    "Safe from a ToR user": what does this mean ? Anyway, ToR is about anonymous surfing: the server does not know who the client is. Authenticating clients is about the exact opposite: the server makes sure of who is at the other end. Commented Dec 29, 2012 at 13:54
  • Suppose a user is blocked from accessing a wordpress blog while traveling in a foreign country and they are unable to update it. They used to update it via ToR but now know that usernames and passwords are collected at some exit nodes. In this case I need network routing anonymity (to bypass the firewall), and the server to know who is permitted to make the blog updates. I also don't want malicious exit nodes to modify the content between the server and exit node. A VPN may be ideal (and faster) but for now I think mutual auth TLS may be administratively easier to implement. Commented Dec 29, 2012 at 14:01
  • 1
    Rogue CAs are how corporate TLS proxies work.
    – Phil Lello
    Commented Mar 13, 2016 at 17:44
  • 1
    So even if client trusts the attacker (but server doesn't), so long as client doesn't disclose private key, attacker can't impersonate client to perform actions on the server — neither during attack nor later? Did I get this right? Commented May 10, 2018 at 8:08

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.


If you stick to the strict definition of a MiTM (which does not involve manipulations of certificate stores), then the answer is provided in the TLS RFC, appendix F.1.1: "Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks". So for a pure MiTM, client certificates are not even needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .