The Enterprise, the Subverted PKI Trust Relationship, and You
by Mike (mike@tofet.net)
A Sinister Plot
I work for a large, buttoned-down, conservative organization that frowns upon unreadable network traffic.
This organization had decided it wanted to be able to decrypt all HTTPS web traffic so it would be inspectable. The main reason for this was to prevent data leaks of sensitive, proprietary, or privacy-act related information. Part of our job contract and our network user agreement at this organization is the explicit acceptance of constant monitoring. We know this from the start, so we shouldn't expect privacy.
But when we go to an SSL-protected website and see our little friend the padlock, we do expect a reasonable level of privacy. For me, the only information I generate from my work computer that I want to protect are the passwords to my banking, credit cards, utility accounts, etc. I don't spend much time doing this sort of thing at work, but the fact remains if you want to contact someone during business hours about your account, you are likely doing it during your business hours as well.
Being in a bit of a leadership role at this organization, I was privy to the initial plan put forth to open up the SSL traffic to inspection. Without going into details, I knew the initial plan was doomed to failure. I dutifully pointed out the flaws, but was reassigned before I got insight into the final plan. To keep the growing hacker outrage I can already hear in check, I had known about the reassignment before my review of the plan.
Nevertheless, I know with certainty that the organization will pursue the goal of inspectable SSL/TLS traffic until they get what they are looking for.
So How Do You Do It?
The only really reliable way of inspecting SSL/TLS traffic is to conduct "man-in-the-middle" (MITM) observations.
In short, this means all traffic leaving the client must go through a middleman before continuing on to the distant server. These middlemen are called proxy servers, or gateways in network parlance. It is trivial to set up a man-in-the-middle proxy server capable of interjecting itself into the SSL flow. As an example, check out Python Micro Interceptor Proxy.1
Right out of the box, this very compact Python-based proxy server will decode all SSL traffic and give you full access to the traffic for logging, exploration, password sniffing, et cetera. pymiproxy is just one such tool that can do this with ease. There are also very popular tools such as SSLSniff and SSLStrip available; the choice is a matter of preference and environment.
But there is a problem.
If you set up your MITM proxy server, point your browser to it, and then surf to an SSL encrypted page (such as google.com), you will almost certainly get a big glaring error page.
This page will say something similar to: "The certificate for this web page cannot be trusted. We recommend you leave town immediately. Or, you can do a bunch of mouse clicking to tell us you know what you are talking about."
This is because the MITM proxy server has violated trusted Public Key Infrastructure (PKI).
On the way to Google's servers, your request for a secure web connection was intercepted and repackaged as though the proxy server itself was making the connection request. Google's servers dutifully sent a very expensive, special, cryptographically-signed identity certificate to the proxy server. The proxy server used this certificate to establish a secure connection with Google. Then, the proxy server generated a free, less-special, but still cryptographically-signed identity certificate to your browser. Well, your browser can smell a rat and lets you know before establishing a connection.
Your browser can detect the difference because Google's certificate was protected by GeoTrust's Global Certificate Authority (CA) cryptographic signature. Your browser was taught from birth that this signature is digital gold and anything signed by it must glitter. The MITM proxy's certificate was signed by an automatically-generated CA that your browser doesn't know. So it gets mad, warns you, and you run away screaming.
This difference between known Certificate Authorities and rather wonky ones is the root of trusted Public Key Infrastructure. Your browser has been taught that a select few certificates - though more than you probably realize - should be trusted implicitly; anything else is likely evil.
Whew! That Should Protect Me! Right?
No.
Your browser can be taught that any given certificate should be trusted as much as GeoTrusts' are. The functionality to add, delete, modify, and otherwise manage trusted certificates is built into every modern browser and operating system. Simply search for "manage certificates" followed by your browser name and you'll get a nice list of tutorials.
In this case, if the CA used by the MITM proxy server is trusted by your browser, there will be almost no visual warning that anything is amiss. You will connect to Google, complete with a nice padlock, and conduct your searches in blissful ignorance. In the meantime, everything you send is being decrypted and logged before being sent on to Google's servers.
There are some differences in the presentation of the security indicators, but there will be no large, glaring warning such as the one you originally saw. You, as a reader of this magazine, may catch the difference, but I can guarantee you your coworkers won't.
You can see this difference in action by setting up a known CA, having your browser trust it, and then making the MITM proxy use it.2
Got It. Don't Trust Strange Certificates.
This is where the enterprise comes in.
In this sense, enterprise is short for: "We, the corporate entity, control every aspect of your computing environment to include hardware, software, configuration, and connections." Most large business entities have standardized computer deployments; everyone uses the exact same hardware and exact same initial software setup, typically cloned from a Norton GHOST image. This is, in fact, a security best practice because it greatly simplifies the patching and update process.
If that standard configuration comes with a pre-loaded, company-controlled Certificate Authority and that CA is used to sign the identity certificates received by your browser, you may not ever realize your SSL-encrypted communications are being watched. The enterprise has subverted the PKI trust relationship by trusting a CA for you.
That Sucks. How Can I Know?
The easiest way to know is to examine the CA path of your most commonly used websites from a trusted computer and network location.
Make note of the name of the root CA used and then compare this to the root CA when you use the website from a less-trusted location. If the root CA matches, then there is a very high probability that the end-to-end SSL connection to your website is secure. In short, you have to become more vigilant in your use of the technology and not simply trust the security indicators.
But this is also easy to subvert.
When you make your own CA signature, you can literally name it anything you want. You could name it "GeoTrust Global CA" and install it in your browser. Then anything signed by this CA will have a root CA of "GeoTrust Global CA."3
I tested this in Firefox on Ubuntu and it worked like a charm. The trusty lock icon turns from a full-color picture to a mere gray shadow of security, but there are no large errors. Firefox didn't even complain when I imported the certificate file. Instead, it filed the new cert under the actual GeoTrust Inc. group in the certificate manager!
You could make one of these up for all of the major CA companies out there and put them in the browser's certificate store. It would be trivial to program your MITM server to send the appropriate fake root CA depending on what CA was sent by the distant server. If all you do is check the name of the CA, you may once again not realize you are being had.
The next level up from checking the names individually is to visit a few secure websites and note the root CA used. If it is the same root CA for each website, odds are there is a man-in-the-middle proxy involved.
For instance, Google currently uses GeoTrust Global CA but Yahoo uses "VeriSign Class 3 Secure Server CA - G3" as their root CA right now. But, if I surf to Yahoo! through my MITM proxy, it says GeoTrust Global CA.
If you visit four or five sites and they all have the same root CA, your SSL traffic is being inspected. This method isn't foolproof, of course, since the MITM proxy could serve up an appropriately named CA for each site as already discussed.
The only surefire way to detect a MITM proxy is to examine one of the mathematically calculated hex-encoded field values that all certificates have.
There are several to choose from, but the one that would absolutely ensure you are using the correct certificate is the public key. If the public key matches every time, then it is the correct certificate. You wouldn't need to memorize and check the whole public key - perhaps just the first eight bytes and the last eight bytes would be enough to ensure the certificate was right. If they do match, I would say you are in very good shape, crypto wise.
Although it might seem daunting to make this check, you don't need to check every site you use. If you do the public key check on two popular websites that default to SSL - say google.com and yahoo.com - and everything checks out, odds are very high there is no MITM SSL-inspection proxy server at work.
As an example, when I surf to google.com without a MITM proxy in the way, the first eight bytes of the GeoTrust Global CA certificate are: DA CC 18 63 30 FD F4 17
If I surf to Google through my MITM proxy with the fake GeoTrust Global CA certificate discussed above, the first eight bytes of the public key are: F0 0A 93 56 DE DB 4F 49
You can see I didn't even need eight bytes to make this determination. Just one byte is enough to tell me they are different.
The only real downside to this method is when sites change their certificates. Certificates expire, of course, or a site may change root CA providers to get a better deal. So you need to spend a little time making sure you stay up to date on the current public keys of your test sites. But really, that isn't much of a price to pay for a little sense of security.
Moral of the Story
A MITM SSL inspection proxy is just one of the ways a corporate enterprise can reduce the security level of otherwise secure computer use. Since they control your entire desktop, they could easily put in key loggers or other software that gives them insight into all of your activity.
Since you are working on their networks, under their constraints, and they are paying you, there isn't much you can do about it. But, you do have the right to know your secure information isn't so secure. Since they aren't likely to tell you, you need to come up with techniques like the ones discussed above to detect their intrusion.
Update: You're not safe away from the enterprise either. A few months after I wrote this article, a story broke about Lenovo and Superfish. It turns out certain models of Lenovo laptops had a piece of adware/malware installed at the factory called "Superfish." Superfish did many things, but the most insidious was installing a pre-trusted root CA. This root CA could then be used to spoof secure connections in exactly the way I discussed.
Bottom line: you need to stay alert no matter what computer you are using.
Notes
1.) pymiproxy can be downloaded from GitHub: github.com/allfro/pymiproxy.git
2.) I used the instructions at: Becoming a X.509 Certificate Authority to set up my CA. I had to make the following changes to the openssl.cnf to get it to work reliably:
Once the PEM and key files have been made, you need to concatenate the files into a single PEM file. You can then start pymiproxy with: python proxy.py yourCAfile.pem
Make sure you import the PEM file into your browser and configure the trust settings correctly.
3.) You can set your certificate to any name you like with the "organizationName" and "commonName" fields in the openssl.cnf file.