Think your SSL traffic is secure?

If you use SSL at work in ways designed to elude acceptable-use filters (e.g., WebSense) or to secure applications like telephony and file-sharing, you may want to re-think that proposition.

A series of products, among them Blue Coat's SSL Proxy, provide SSL-cracking capabilities to organizations interested in shutting down SSL violations of policy.

In effect, Blue Coat's SSL Proxy breaks any SSL traffic its been configured to intercept. How can that be so? Isn't SSL/TLS secure from man-in-the-middle (MITM) attacks?

How Blue Coat cracks SSL/TLS

I've based the first part of this analysis on BlueCoat's SSL Proxy White Paper (PDF). Later details are based upon its Deployment Guide, which spells out some of the nuances of configuration.

When a connection request is made by the browser, it passes through the Blue Coat proxy on its way to the real SSL server. The response from the destination SSL server includes a certificate. This certificate is designed to (a) irrefutably identify the server; and (b) secure the communications between client and server. To do so, the cert wraps the server's public-key, which is tied to the domain name (or, less likely, IP address) of the server.

The real server's cert, though, is intercepted by the proxy on its way back to the browser.

Before the proxy passes the certificate through, it unwraps the public key and then re-wraps it in an "emulated certificate" (I'll go ahead and call it a spoofed cert, which I think is more accurate). This spoofed cert is then returned to the client browser. The client thinks everything is on the up-and-up and -- after it verifies the spoofed cert -- it establishes the encrypted tunnel.

The tunnel, though, is now terminated at the proxy server. The proxy itself has established a second tunnel to the real destination SSL server.

The proxy can now inspect the cleartext traffic, block the traffic, or pass it on to other devices for their use (more about this later), and otherwise fiddle with it prior to sending it down the second encrypted tunnel to the real SSL server.

Modifications are required on the client

This approach, though, does require a slight modification on the client side. Namely, the server has to be "trusted" within the client's certificate chain. If a corporation runs its own CA (certificate authority), odds are that the browsers in the organization will already be configured to use an extended CA chain.

Even if the organization doesn't have its own CA, a new signing-key -- in the form of a new cert in the client-side chain -- can be added to the browser's list as "trusted." Once added, all proxying of the SSL traffic can take place without popped-up warnings or errors: the browser's SSL configuration is ostensibly "correct". The server brokering the SSL session is correct and "trusted."

The Blue Coat Systems Deployment Guide explains how this client-side operation works (PDF):

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store. The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Concerns with Cracking SSL

To be sure, one wonders about the privacy issues raised by this class of device. A commenter on the SANS list expressed just this concern a few weeks back:

...I understand the reasoning behind doing SSL interception just for content filtering, but even in a corporate, .gov, or .mil situation where the user may have explicitly or implicitly signed away all of their privacy rights, there is some expectation that SSL traffic is not going to be visible to a third party, much less cached...

In fact, the Blue Coat Deployment Guide spells out a recommended best practice that alludes to this facet of operation:

[You should] Implement HTML notification for intercepted sites... to inform end-users that their HTTPS traffic will be monitored and that they can opt-out if they do not want their traffic to be intercepted. HTML notification is also helpful if a site is accidentally intercepted.(Ed: emphasis mine )

Interestingly, of all the operations described in the manual, the Windows Update process is arguably the most secure! Presumably, this is because Microsoft doesn't allow alteration of the certificate authority chain. The FAQ in the Deployment Guide notes:

Problem: Windows Update Description: The Windows update does not work when the SSL Proxy intercepts windows updates connections. This is because the Windows update client does not trust the emulated certificate presented by the SSL Proxy. Solution: SSL connections for Windows updates should always be tunneled.

Exposure of SSL cleartext to third-parties

As far as privacy concerns, another aspect of SSL Proxy operation is interesting to contemplate. Namely, certain companies have established partnerships with SSL Proxy vendors in order to add to the suite of capabilities offered by the base proxy products. For instance, BlueCoat struck a deal with PortAuthority, presumably to permit sharing of cracked SSL/TLS traffic between the companies' devices.

I haven't investigated all the permutations of these arrangements, but one wonders the following:

• How secure is the communication channel between the products?


• How secure are the products themselves (i.e., how many vulnerabilities do the various proxies have -- and their partner products)?


• How do organizations validate the configurations to ensure that banking and other sensitive traffic remains protected on an ongoing basis?

It's not that these issues can't be addressed. But they should be food for thought for anyone implementing or operating under the constraints of these types of devices.

In any event, be aware that these products exist... and they can do what they claim if properly configured. Webmail, peer-to-peer file sharing, telephoney, etc. can all be monitored and blocked, even if tunneled through SSL/TLS.