Facebook Goes HTTPS

2,203 people reacted 0 2 min. read


Category: Uncategorized


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.

5 Reader Comments

  1. Its not sufficient to decrypt ssl, whats important is to be able to decrypt ssl with the minimal latency since you do not really know which streams to decrypt and which ones to not. In other words its an always on feature.

  2. Matt

    Always on SSL inspection seems like a good idea, but wouldn’t it be overkill, given that our research shows that less than 40% of the traffic is SSL? The processing power that would be required would be enormous – as would the associated platform costs passed on to the customer. We believe that a better alternative is to look across all ports, to see if the traffic is SSL, then decrypt as needed.

  3. In the digital age, seamless access to information is taken as a basic right. The question is when to encrypt or not and will there be a reduction in the perceived threat or risk? Or do we provide a secure channel for malicious activity? All security measures have a limited life cycle before there is a known workaround. With encrypted communication we can limit the scope of breach, but never can we say it is 100% secure 100% of the time.

    All we do is move the burden of delivering a clean pipe service to the edge, where someone has to look inside the SSL communication and police the traffic.

  4. @Matt

    Actually, with the right hardware, the mathematical load required by the decryption and re-encryption needed for ssl dpi can be very streamlined.

    The newer processing technologies from the last year or so are what is making it possible for services like facebook and google to handle the high ssl load in the first place. The processor load increase caused by the switch to https has finally become pretty much inconsequential. If you have the right engine, it should be no problem to handle with the relatively small loads that most corporate LANs generate.

  5. Can someone please provide details on how PAN firewalls decrypt SSL traffic on the fly?

Got something to say?