SSL and the Man in the Middle

Privacy and Security are important topics for anyone who uses technology.  In this weeks post I will describe a technique that is used by Proxy Servers to intercept encrypted traffic.

SSL is used to encrypt data between a user’s web browser and a web server on the internet.  SSL is used everywhere from gmail to online banking.  It is often taken for granted.  Many users don’t understand the way that SSL works.  Web browsers have been designed to display a lock symbol to indicate that a connection is secure.  Web browsers have also been designed to alert a user to  potential security issues.  This takes the technical burden off of the end user.  They don’t have to understand the underlying technology.  They see a lock symbol and trust that their connection is private.  When they see an error message indicating a problem with security they know to close their browser and get out of there.  Some browsers will not even let a user proceed to an insecure site without first making them jump through several hoops and acknowledging that they understand the risks.

SSL uses Certificates that are based on a series of trusts.  There are may commercial Certification Authorities on the internet.  Web browsers such as Mozilla Firefox are designed to trust these Certification Authorities.  A list of CAs trusted by Firefox can be found here: https://wiki.mozilla.org/CA:IncludedCAs.

The basic logic follows that the creators of Firefox trust these CAs so they build that trust into their product, the browser.  Website owners who want to use SSL to secure traffic on their website then purchase certificates from these CAs.  When a user sends a request to the website from their browser the website returns a signed certificate.  Firefox trusts the CA.  The CA verifies the authenticity of the website through the certificate.  The browser displays a lock symbol indicating that the connection is secure.

To see the chain of trust, click the lock symbol on your browser. Click more information.  Then view certificate.  The image below shows the certificate that I see when I do this from my home computer while visiting gmail.

Certificate Home

If we select the Certification Path we can see the chain of trust.

Path Home

In the example above, the browser trusts GeoTrust Global CA.  GeoTrust Global CA issues a certificate to Google Internet Authority G2.  Google Internet Authority G2 then issues a certificate to www.gmail.com.  Our browser trusts this certificate therefore a lock symbol is displayed.  This gives us a reasonable level of assurance that our connection is secure between our browser and www.gmail.com.

If I perform the same check at a corporate office location using a client supplied laptop things look a little different.

Certificate Work

In this case the issuer is not Google Internet Authority G2.  Instead it has the company name followed by BlueCoat Signing Authority.

BlueCoatSigningAuthority

The Certification path also looks different.  Instead of GeoTrust Global CA or Google Internet Authority G2 we see BlueCoat Signing Authority.

When viewing gmail over this connection a lock is still displayed in the browser indicating that everything is secure.  There are no warning messages in the browser indicating that anything might be wrong.  In fact, if I hadn’t viewed the certificate, I wouldn’t know that anything was different between my home internet connection and my work internet connection.

My web browser certainly doesn’t come from Mozilla pre-configured to trust this company’s BlueCoat Proxy Server, so what gives?

The company issued computer that I’m using is part of an Active Directory Domain.  They have also implemented Microsoft’s PKI within their domain.  This means that they have their own internal CAs which can issue certificates.

Even though Firefox does not come pre-configured from Mozilla to trust these CAs, the computer does trust them.  This is because the certificate is pushed down to the computer through the Active Directory Domain.  We can verify this by viewing the certificate store on the local computer.  To do this, open an mmc and add the Certificates Snap in.

CertificateStore-Edited-2

We can see all of the certificates that have been pushed down to the computer under TrustedRoot Certification Authorities.  The computer trusts these CAs.  The way this is done is beyond the scope of this post.  Just keep in mind, that when using a computer that is administered by someone else, that organization has a great deal of control over its configuration.

Why would they want to do this?

What value is there for this company to issue their own certificates so that their BlueCoat Proxy Server is trusted by all of their computers?  Simple.  They want to intercept all internet activity going into and out of their company.  The BlueCoat Proxy Server acts as a Man in the Middle.  When gmail.com sends a certificate in response to a user request the BlueCoat proxy server hangs on to it rather than passing it along to the client computer.  This allows the BlueCoat proxy server to intercept all data that is being sent to the user.  BlueCoat even has a feature that allows proxy administrators to view this data in real time, just the same as if they were standing over your shoulder viewing your screen.

If the BlueCoat proxy server sent the decrypted data to the user’s browser unencrypted the browser would alert the user.  Web browsers are designed to alert users to potential security issues.  Therefore, the BlueCoat Proxy Server must re-encrypt the data before sending it along to the user.  They can’t re-encrypt it using the same certificate that gmail uses so they have to use their own certificate.  Hence, the need for an internal CA.

Some may argue that companies have a right to see all traffic going into and out of their networks.  They are the ones paying for the bandwidth, after all.  Others may argue that users have an expectation of privacy while viewing websites secured with SSL.  They have been trained to believe that a lock symbol indicates security even though in this case it does not.

The point of this post is not to take a position on the situation one way or the other.  The point is to bring awareness to the situation.  When you visit a secure website, click the lock.  View the certificate.  Look to see who is certifying that the connection is secure.  If it is a commercial CA on the internet that is widely trusted by major web browsers then you have a reasonable expectation of privacy.  If it is certified by a CA within your company then be aware that the administrators who issue that certificate may be able to intercept the traffic.

Knowledge is power.  What you decide to do with it is up to you.

Bret Miller – Owner and Principal Consultant, LMR Computer Services Inc

References and Further Reading

Root Certificate Wikipedia Article: http://en.wikipedia.org/wiki/Root_certificate

Certificate Authority Wikipedia Article: http://en.wikipedia.org/wiki/Certificate_authority

Man in the Middle Wikipedia Article: http://en.wikipedia.org/wiki/Man-in-the-middle_attack

List of CAs trusted by Mozilla: https://wiki.mozilla.org/CA:IncludedCAs

Bluecoat Documentation: https://bto.bluecoat.com/webguides/proxysg/security_first_steps/Content/Solutions/SSL/Create_CA-Signed_Cert.htm

Bluecoat Documentation: https://bto.bluecoat.com/webguides/proxysg/security_first_steps/Content/Solutions/SSL/Verify_SSL_Traffic_Interception.htm

Basic Overview of SSL: https://www.instantssl.com/ssl.html

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s