Last month, Michael published his 2011 security predictions. His second prediction in his list of 10 discussed SSL Only Sites:
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,
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:
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.
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)
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.
