Our privacy vs. their security: What's wrong with SSL/TLS Man-in-the-middle, Anyway?

Expectation vs. Reality

Our common expectation when using SSL/TLS (https) to connect to a web site is that our communication with that site are encrypted and therefore private. This is true only when both parties, client & server, are authenticated to one another using Public Key Certificates. However, the vast majority of websites that use SSL/TLS use single-sided authentication. They don't use SSL Client authentication and certificates. If you only use a Client Certificate with corresponding private key to connect to SSL/TLS enabled web sites - the following isn't relevant to you. However,

Transparently or otherwise, it is likely that at least some of your SSL/TLS sessions have been, or continue to be, read by a third party. For a sizable proportion of us, MITM monitoring falls completely within bounds of our employment contracts, whether we remember it or not.

In the employment case, SSL/TLS MITM is often described as the equivalent of having a security guard rifle through your backpack, purse, or briefcase before you leave the building. Security is simply enforcing company policy, looking for and 'blocking' assets that the employee is not authorized to carry off premise. When MITM is used in the employment or 'secure' facility case - it is the network equivalent of the security inspection before leaving the work.

What is SSL/TLS Man-in-the-middle?

SSL/TLS MITM is not about 'breaking' encryption, as no encryption is broken. It is about the man in the middle, or proxy acting as server to client, and as client to server.

If you think you've connected with Bank of Freedonia, and it looks and smells like Bank of Freedonia, and you 'know' that SSL/TLS is about encryption - it's understandable that you believe your communication is confidential. But is it?

SSL/TLS, based on public key cryptography, provides two basic capabilities - authentication and confidentiality. It provides for mutual authentication, each party authenticated to the other, and for server only authentication, where the server is authenticated to the client,  but the client is not authenticated to the server - hence, single-sided 

Single-sided Authentication is by far the most common web server deployment, the server is authenticated to the client, but the client is not authenticated (via SSL) to the server. Enter the Man-in-the-Middle.

In a MITM scenario, a middleman (or proxy) represents itself to the server as a client, and to the client as the server. Instead of one connection directly between client and server, there are two connections established: the client user to the proxy, and the proxy to the Server. The proxy can see all the traffic in-between.

How to impersonate a legitimate site

The way the proxy represents itself to the client is as the legitimate server. It crafts a PKI Certificate that the client will accept as trusted. Among the ways a client might trust a certificate is by:

1. The user deliberately installing a 'MITM' certificate in their browser, keychain, or certificate store and marking as trusted
2. The client's organization installing a MITM certificate on the employee's machine via endpoint management and marking the certificate as trusted
3. A proxy forging a legitimate site certificate, signed by a Certificate Authority that has been granted 'Root' status. In this case the forged certificate is in the trust chain of a trusted root, and will be automatically installed in the client's 'Root Certificates' through operating system update, managed endpoint installation, or otherwise obtaining the current 'Global Roots.'

In the first two cases, this can be made completely transparent to the user. If I'm an employee, I know that my company requires such ability; there's no need such monitoring be hidden. I see the security inspection before I leave the building.

In the last case - forging certificates by means of a trusted Root or Intermediate CA - not only can the MITM do so opaquely (to the end user), but they do so by introducing serious vulnerabilities into the entire PKI infrastructure.

Why do you think this case introduces serious vulnerabilities? Legitimate vendors provide this for their legitimate customers!

Few legitimate MITM vendors use the Intermediate Trusted CA in their implementations. They understand the risks the the public key infrastructure. Remember DigiNotar?

Quietly forging certificates to impersonate a legitimate site

In order to craft a 'forged' certificate that will not cause an alert in the client's browser, the proxy must

1. Create a certificate with the destination Server's URL, to match the one requested by the client;
2. Sign the certificate with a private key corresponding to the trusted Root or Intermediate CA's certificate.

If the proxy creates the server certificate 'on-the-fly,' it must have access to a private key corresponding to the trusted Root or Intermediate Certificate. Anyone with access to the proxy can conceivably obtain the private key and generate 'trusted' certs ad nauseum.

Alternatively, a proxy vendor owning a Root or Intermediate Certificate could pre-forge popular site's server certificates and populate them into it's proxy, although there are technical challenges if the legitimate certificate binds the server's IP address to it's URL. In this case the forging will likely occur at the proxy, as the client's browser 'sees' the proxy's IP address as the servers.

The missing counter-party

You may have observed that outside of forging their certificates, I've made little mention of the expectation of the Web Service whose certificates are being forged. Like users, Web Services usually have an expectation that their SSL/TLS enabled service provides for confidential exchange of information between themselves and their users. Or do they?

Countering MITM

Web Service Providers are increasingly using techniques like Certificate Pinning and http strict transport security (HSTS) to mitigate MITM techniques. At the same time, MITM vendors (and attackers) are researching new ways to circumvent these techniques. 

Conclusion

SSL/TLS MITM may have legitimate use cases in which all parties agree, Employer and Employees for example. Legitimate vendors provide this service in a way that is transparent to all parties. Such use may reflect genuine business need while respecting employee privacy by white-listing (no-inspection) financial, healthcare, or other user sensitive sites.

SSL/TLS MITM if institutionalized by allowing vendors to use trusted Root or Intermediate CA's to forge legitimate certificates, will continue to erode the security and reliability of the SSL/TLS PKI infrastructure.

Compromise of a MITM proxy that uses Root or Intermediate CA certificates techniques may provide an attacker with either the MITM CA's private key, or a pre-forged collection of otherwise legitimate certificates enabling them to do likewise, anywhere.

In order to distinguish itself from illegitimate or criminal exploitation, legitimate use of MITM should be accompanied by full disclosure and agreement of all parties.

~r