SSL, man-in-the-middle attacks and root CAs

This post explains how your employer might have access to all your SSL-encrypted communication, including for example the internet bank.

Usually secured, HTTPS connections to your internet bank, e-mail, Facebook and whatever else go roughly like this:

  1. Your browser initiates a session with the server,
  2. The server responds with some sort of a key or certificate,
  3. The rest of the session is encrypted with the key provided by the server.

This key is signed by some Certificate Authority (CA), which ensures that the server really is the guy you want to talk to (you don’t want to send your GMail passwords to some rogue server, for instance). Your computer (probably the web browser, or maybe the operating system) stores public keys of all the CAs and the browser checks the signature on the key the server sent, during the start of each SSL session.

At IoC, all the web services that move your passwords (like webmail, trips, wiki) are SSL-secured, but the SSL certificates for the webservices are generated by IoC itself, and signed with a IoC root certificate. Thus, when a web browser connects to, say, trips, then it is going to get a certificate ensuring that trips is actually trips and nobody’s listening in. Unfortunately, as this certificate is not signed by any CA trusted by your computer, your browser is going to complain.

A man-in-the-middle attack (MitM) is when somebody intercepts the traffic on the way from your computer to the webserver and back, decrypts the traffic, logs down your passwords (or susbstitutes some information, possibly) and reencrypts the information again.

To get access to trips, one now has three options:

  1. Either you can make an exception upon every connection (and every time accept the risk that a man-in-the-middle attack has been performed, leaking your IoC passwords),
  2. Or you can store the exception (thus reducing the opportunity for a MitM attack to the first time when you connect, but for some weird reason I can’t find a way to do this in Google Chrome), for every secured IoC web service,
  3. Or you install the IoC CA root certificate into the list of CAs in your browser, thus accepting every certificate signed by the IoC CA.

Here’s where the admins of IoC network come into play: they are not limited to producing certificates for IoC webservices, they can also produce a certificate for,, your internet bank, etc. If you installed the IoC CA root certificate into your browser, it is silently going to accept those certificates, thus cheating your browser into trusting the fake SSL connection to be secure. Further on, some router would then have a web server accepting the web requests from you, decrypting the request, just like the real server, logging down or substituting whatever necessary, then (faking you) re-sending the web requests to the real server, giving you the full illusion of talking to the internet bank.

Obviously, this sort of trick can be played by any CA you trust. The difference is that Verisign and friends are huge and distant, it’s probably going to be extremely difficult to convince them to give a SSL certificate for for anybody but the real Facebook. Funnily enough, however, there have been cases when due to sheer monumental stupidity, some trusted reseller guys issued certificates to the wrong guys, with NO validation of any kind: meaning that anyone could set up a perfect MitM attack that’d work for everybody, not only IoC employees who have installed the IoC CA. There have also been cases where CAs have been hacked, leading to identical effects: Link

In conclusion, there is no good way out of stupidity or getting hacked. For IoC, getting proper certificates would mean some expense (either major restructuring of webservices plus one certificate, or one certificate per webservice) and bureaucracy. Right now, Firefox’s ability to permanently store exceptions seems like the best solution for us—if you do it just once per IoC web service, then you’re almost safe.


4 thoughts on “SSL, man-in-the-middle attacks and root CAs

  1. Pingback: A stupidly easy way to hack into computers | Theory Lunch

  2. Yes, I think that explicitly accepting the server certificate once when connecting for the first time is the best solution. In order to have more confidence that a man-in-the-middle attack is not happening during this first connection, I perform the first connection only while being within the IoC network, connected via cable. If you can already establish a reliable SSH connection to IoC’s shell server (that is, you accepted the right SSH server key once), then you can also log in via SSH and generate the fingerprint of the SSL certificate, so that you can check that it is the same as the fingerprint of the SSL certificate you are going to accept. To generate the fingerprint, try this command:

    openssl x509 -fingerprint -md5 -in /etc/ssl/certs/

    Alternatively, use -sha1 instead of -md5.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s