What's So Hard About SSL?

As the proxy administrator, it's possible you haven't thought about SSL at all, or maybe opposite is true, and it keeps you up at night trying to figure out how to deal with SSL encrypted web traffic. Either way it's definitely something that you should be worrying about, whether it's a reverse proxy, or a forward proxy that you have implemented.

The reverse proxy scenario is of course easier in that you're protecting a known set of websites. If some of them happen to be SSL encrypted your proxy should easily have a method to allow you to install SSL certificates for those websites, and give protected access to those trying to reach internal websites.

The forward proxy scenario is the more complicated one, and probably the one keeping you up at night. When you use a forward proxy to protect your end-users from threats they may be exposed to from external websites, it's easy to check downloads that come across the proxy in the clear and check the URL's and scan the content for viruses and malware.

The hard part is when your users are browsing encrypted sites. If your proxy is bypassing or tunneling encrypted sessions, then any malware that's hosted on those encrypted sites makes it to your network without any URL blocking or virus and malware scanning. The reverse proxy scenario discussed above where you load up the website's SSL certificate is unmanageable for a forward proxy, as the scope of possible websites is enormous (and no proxies would be able to support that many SSL certificates).

There are a couple of possible answers to this possible dilemma. The first obvious one is to block access to all SSL encrypted sites. Obviously this doesn't work for everyone, especially those organizations that are using SaaS (Software as a Service) sites like salesforce.com, which depend on SSL for security. The next possibility is to just block SSL to well known categories that you don't want on your network to begin with (possibly banking and shopping). This still leaves the question about SSL to the remaining sites. Here's where having a fully featured proxy is important. Any proxy worth its salt today will have the ability to intercept SSL traffic and inspect the contents of the encrypted session. How is that done? Typically the proxy will create its own SSL certificate that's signed by the proxy as opposed the CA (certifying authority). This means of course you'll have to have your end-users trust the proxy, or pre-install that trust on systems as you stage them for end-users (otherwise end-users will get pop-ups warning them of insecure SSL sites). This allows the proxy to inspect SSL content by interception the session, and applying policies like URL blocking and virus and malware scanning, and DLP (data leakage protection) inspection as well.

There is a problem here and that is related to privacy. While intercepting SSL encrypted sessions for SaaS sessions that are company or enterprise related is fine, there's a slightly touchy subject if you intercept a user's personal banking session which has used the user's PIN or other passwords. If you do decide to intercept SSL, it's a good idea to block personal use categories like banking or shopping (to prevent capturing personal data), or at least put up an acceptable use policy page that explains that SSL sessions are intercepted, and private transactions should not be done over the corporate/enterprise network (so any access an end-user does is at their own risk). Most proxies are capable of setting up a click through page that explains acceptable use each session an end-user has to access the internet.

There's of course one other possible scenario related to proxies and SSL, and that's when your proxy is also your WAN Optimization device. We'll tackle that one in a future blog post.