Facebook Goes HTTPS

This week, Facebook announced HTTPS support for all communication between its servers and end users' web browsers.  This is the right thing for Facebook to do in light of recent proof that session hijacking of Web 2.0 applications is both easy and increasingly common with tools like Firesheep.  While HTTPS is not yet on by default (users have to specify HTTPS in the Facebook URL), that is the stated intention.  Note that Gmail went to default HTTPS a year ago.

Both of these moves highlight an important trend – applications will increasingly use encryption for privacy and security reasons.  Meaning that enterprises seeking to identify and control which applications run on their networks (are there any that DON'T want to, given the use of applications as a threat vector?) will have an increasingly difficult time absent the ability to decrypt outbound SSL.

According to our most recent Application Usage and Risk Report, 96% of organizations have Facebook on their networks.  Many organizations have specific initiatives around Facebook, and certain employees need to safely use Facebook to get their jobs done (e.g., allow use of Facebook for marketing and public relations users, but scan for threats).  Other organizations want to enable users to employ Facebook reasonably (e.g., allow Facebook for personal use, but scan for threats and block Facebook Apps).  Still other organizations want to block Facebook.  The point here is that regardless of an organization's policy stance on Facebook, it can no longer enforce that policy without decrypting SSL.  Let's not even get into the use of things like TOR and Ultrasurf as other methods to circumvent controls…  The broad takeaway from this development: if you can't decrypt SSL, you're going to have a harder and harder time implementing meaningful enterprise network security controls.

There has been a lot of interest in next-generation firewalls recently, with a few products being introduced that bolt IPS engines onto port-based firewalls and feed them application signatures.  Matt covered some of the significant limitations of the bolt-on approach versus a firewall that classifies traffic by application here.  Another very relevant element in this discussion: the bolt-on approach can't cope with the ever-increasing use of SSL by high-risk, high-reward applications like Facebook and Gmail.