Facebook And The HTTPS/Security Paradox

Last month, Michael published his 2011 security predictions. His second prediction in his list of 10 discussed SSL Only Sites:

In 2011, expect a handful of major vendors to finally tackle this challenge head on and deploy SSL only websites.

Facebook recently announced on their blog that users will have the ability to have all of their transactions encrypted via HTTPS. This is a step in the right direction for protecting your account and your privacy - particularly when using public wifi. I have already blogged about session-id stealing from HTTP transactions (sidejacking), which was further publicized with the release of FireSheep and BlackSheep. Unfortunately, on Facebook, usage of HTTPS is not enabled by default - users still have to enable this setting within their Account Settings page.


There have been a number of security concerns and issues with Facebook- for example,

• Koobface / malicious "videos" advertised and spread

• Rogue Facebook Applications - here is a recent rogue "photo" app that I saw with relatively poor A/V detection (11/43):

The bad guys are abusing popular web sites/services that users trust. As these sites move to SSL-only versions, while private information may be better protected, any embedded malicious content will be encrypted and potentially invisible from your enterprise's IDS/IPS. This is the security paradox that I speak of: moving to HTTPS for all transactions protects against sidejacking and protects user's privacy, but this also prevents inspection of network transactions for malicious content ... this is potentially a very scary "blindspot" within enterprise environments. This type of "blindspot" exists in other services as well, e.g., Gmail.

However, all is not lost- there are several available security avenues for security-conscience organizations that allow Facebook within their environment:

• Host-based protections:
  • Facebook security apps
  • Client anti-virus
  • Browser plug-ins
• SSL-inspection engines:
  • SSL-proxy with content inspection (appliance or SaaS-based)

The difficulties with host-based protections include manageability and information feedback (logs). SSL-inspection engines on the other hand, can be easier to manage and provide centralized, aggregated logs (this is particularly true of the SaaS-based models). SSL-inspection does however require the ability to temporarily break "end-to-end" encryption which necessitates trusting the proxy and web server certificate validation process. This often causes confusion for management when making the decision on whether to inspect SSL transactions on the network or not.

SSL-inspection engines work by establishing an SSL encrypted session between the web client and proxy, which separately creates a second SSL session between the proxy and the web server. The proxy makes the actual requests to the web server, handles/inspects the received content, and forwards it to the client. In this model the client must trust the certificates from the proxy, and it is important for the proxy to handle certificate verification of the web server.

Zscaler provides SSL-inspection as part of its solution.

Our customers also have the ability to set policy to block transactions to all/or certain social networking sites. Currently, about 16.26% of our customers had transactions that were blocked due to a social networking policy rule.

As Facebook and other popular web services move to SSL-only, enterprises will have a dilemma: (1) accept the risks and rely on host-based protections alone for this content, (2) incorporate SSL-inspection technologies, or (3) incorporate policy enforcement for the sites in question.