VPNs vulnerable to MiTM because ANY certificate goes

Question

I spoke to a sysadmin in a business center today who intended to basically perform a MiTM (as he called it) on every connection in his network because people in his office building are using VPNs and https connections to stream video, download torrents etc.. These services use up all the bandwidth but because they are encrypted connections his load balancer doesn't work.

The security firm he hired convinced him it is possible to set up a proxy server with his own valid and signed certificate (for the proxy server of course) which would dupe all browsers and VPN connections to accept the proxy as their endpoint. This would allow him to decrypt all traffic, verify its content and throttle if necessary, encrypt it once more and send it on its intended way without anyone being the wiser.

On the https part I managed to explain/convince him that any half decent https implementation is meant specifically to avoid MiTM attacks because certificates are linked to a specific domain or company. There is no way his proxy can dupe a browser to think it is connecting to the website while in fact connecting to the proxy server.

However, concerning VPNs he is adamant (or better yet, the security firm he hired for his network) that many VPN services or protocols will accept any certificate signed by a CA to create a secure connection. Whether or not that certificate is actually attributed to the server you are connecting to is not checked.

This seems highly unlikely to me and contrary to everything I know of secure connections but before I pick up that discussion I want to make sure I'm not missing some little known vulnerability in VPN protocols of software that very few people know about.

My question: is it true that some VPN protocols or VPN software will only check the validity of a certificate by checking whether it is signed by a CA and will not at all verify if the certificate is in fact attributed to the server you are connecting to?

-- small edit -- To specify why this should be possible: according to the security firm quite a few VPN softwares will accept any valid certificate and do not check if the certificate is actually linked to the server: any valid certificate is accepted.

Answer 1

Short answer:

Nope, can't be done. This is because a reputable Certificate Authority will not issue a certificate for a domain that your sysadmin does not control.

Long answer:

It can be done under some scenarios.

For example - if you're using OpenVPN to create a TLS connection to a VPN concentrator elsewhere in the world called...say...awesomevpn.sx, one of the first steps in the TLS handshake is server certificate validation. Your sysadmin could attempt to MITM this connection, but he would not be able to present a certificate for awesomevpn.sx because no CA will issue it to him, which would cause the connection to fail.

However, consider a scenario where a company has contracted a vendor to install packet inspection appliances. In order to perform MITM attacks on secure connections, the vendors will compel the installation of their own "root" certs onto client machines. That way, they can use their own CA to sign certificates for any domain. This can be done on the fly by the inspection appliances. When those certificates are presented to the client during the MITM sequence, they will be accepted, allowing the connection to complete, and the packets to be inspected in the clear.

This sounds like a weakness of the CA system, but remember that in a corporate environment, you do not have physical control over the machines owned by the company. Without physical control, it's game over in terms of security.

So the explanation you've been given is missing a key point - they did not mention the requirement to install their own root certs on client machines. It has nothing to do with a weakness in the VPN clients, or the various protocols used for secure connections.

Answer 2

You might want to read this piece on the Gibson Research Corporation site: The “S” added to the end of the “HTTP” means SECURE. (Or at least it was supposed to.)

The presence of the unbroken key or the lock icon on the web browser once meant that the connection between the user and the remote web server was authenticated, secured, encrypted . . . and not susceptible to any form of eavesdropping by any third party. Unfortunately, that is no longer always true.

And

How is this elegant system [cfr. CA-system] subverted?

Any corporation, educational institution, or other Internet connectivity provider who wishes to monitor every Internet action of its employees, students or users — every private user ID & password of every social networking or banking site they visit, their medical records, all “secure” eMail . . . EVERYTHING — simply arranges to add one additional “Pseudo Certificate Authority” to their users' browsers or computers. It's that simple.