Information Security
certificates man-in-the-middle vpn
Updated Mon, 18 Jul 2022 15:08:33 GMT

Is it possible to craft a certificate signing chain that thwarts MITM corporate VPNs?

Some companies install software on corporate VPNs which also come with a root certificate installed on all employees' machines. This allows for encrypted traffic to be decrypted by technology installed on the VPN. Some companies even have to do this to meet certain auditing and compliance requirements.

Is it possible for a website to set up a certificate signing chain in a way that if the root cert that signed it was replaced by the MITM root cert, it would either fail to load the website, or prevent it from being overwritten by the root cert entirely in the first place?

Or, if there's a root cert installed on a machine, is it impossible to prevent TLS intercepting by a MITM party?


From my understanding you are essentially asking if a web server certificate can be setup in a way that the traffic cannot be transparently intercepted and decrypted by corporate MITM solution, which a new root CA is installed as trusted at the client. I.e. the question is not specific to VPN.

In a MITM setup the MITM proxy is basically the client to the original server and thus gets the servers certificate and chain. It then works as a server to the original client but sends a different certificate and chain. Since the client has no idea how the original certificate and chain looked like but trusts the CA for the new certificate, the client will trust the new certificate too. This means that simply with some magic on the certificate and chain it is not possible to protect against MITM.

Protection can instead be done if the client has more expectations to the server certificate than just being signed by a trusted CA. Such expectations can be achieved if the clients limits which certificates it accepts by certificate, the certificates public key or the certificates issuer (CA). Such pinning is implemented for some commonly attacked domains in many browsers. But in order to facility legal SSL interception done in corporate proxies but also desktop Antivirus products, pinning is usually automatically switched off when the served certificate was issued by a root CA which was explicitly imported as trusted.

Another protection would be if the server has more expectations to the client. By requiring a client certificate issued by a specific CA the server can also make sure that the traffic cannot be successfully intercepted. Instead the TLS connection will usually just fail, unless there is an explicit exception for the target site in the MITM proxy. Of course, the client must actually have the client certificate installed in the first place to connect to the server without MITM which somehow limits this approach.

The target server could also try to detect interception by fingerprinting the TLS stack of the client and then block access if interception is detected - see Detect man-in-the-middle on server side for HTTPS for more on this. Note that this detection is not perfect, i.e. can have false positives and false negatives.