Facebook & Google Persistent HTTPS: Just the beginning

The big news today was found on Facebook’s Official Blog: A Continued Commitment to Security

The new feature that I would like to point out is that of giving users the option to force persistent HTTPS when they use Facebook. (whenever possible)

Is this a good time to say that I called it?  From my Fire in the Sheep post this past October:

“…This is only going to drive more normal traffic to SSL, which means that we have much less visibility into our user’s traffic in our enterprises, which means that we will have to find other means of monitoring the traffic–whether it is our corporate proxy decrypting the SSL, or a host-based monitoring application.”

Between FireSheep in October, and Tunisia in December, (and other sundry issues in between that deal with SSL/Security), Facebook has finally decided to allow persistent HTTPS, performance issues be damned.

There is also another little jewel in the post: “We hope to offer HTTPS as a default whenever you are using Facebook sometime in the future.”

Within the last year,  Google has been going down the same path. (Default Gmail HTTPS, encrypted.google.com, etc)

This is great for the general end user’s security, especially when using public, unencrypted WiFi, but it continues to highlight the increasing need for businesses to use SSL decryption with their content filtering system to enforce and audit their user’s web traffic.  This is a very thorny issue, that brings into play a few different hot topics:

Privacy – SSL decryption on a user’s online banking session?  Can a business reliably detect when SSL decryption should not be applied?

Interoperability – How to push out the proxy’s SSL cert to end users if they are different platforms? Think EDU facilities with students.

Performance – On the fly SSL decryption –> Content Categorization –> Applicable Policies –> Completing the Request —-> All without high latency.  Add in your dynamic anti-malware scanning of content & IDP, and it can get very resource-intensive.  It can be done, but businesses will need beefier hardware to do it ($$)

Per the quote from my previous post, how are we going to do IDS/IDP as normal, everyday traffic continues to go SSL?  Most IDS/IDP are setup to receive traffic from a SPAN or Tap, which means we will not see decrypted traffic, unless it is coming directly from the SSL decryption proxy–I am not sure if there is even a product out there that will do that. (You would think there would be…)

Food for thought.

Also, I’ve been toying with the idea of using Facebook as a place to distribute commands to a botnet.  One of the earliest implementations of this was with IRC. Most recently, it was with Twitter.  But think about it.  Doing it with Facebook not only allows the traffic to blend in with normal traffic patterns on the network, but it is also encrypted, so writing a snort rule to look for keywords in the traffic stream won’t help.  And, fueled by today’s announcement, SSL Facebook connections will become the norm, and encrypted connections to Facebook will seem very innocuous….

**Edit**

Not a day after publishing this post, Mandiant’s M-Trends Report was released, in which they “observed a downloader program that used Facebook’s messaging feature for command and control…”

Interesting indeed.

Linky

-Josh