Back in April 2011, I and my then colleagues at Sophos’s Naked Security wrote an open letter to Facebook, calling on the social network to take three steps to better protect their users’ security and privacy.
One of those steps was “https by default”.
In a post published last night by its engineering team, Facebook announced that it was now using “https by default for all Facebook users”.
This is great news.
Implementing HTTPS/SSL means that Facebook’s many millions of users will have their communications with the social network automatically encrypted between their browsers and the site, putting them out of reach of hackers and attackers who could otherwise sniff sensitive information from unencrypted Wi-Fi hotspots.
It’s taken Facebook a while, but I’m glad they’ve achieved it. So, well done Facebook.
If you want to double-check that you have HTTPS enabled for your Facebook sessions, visit your privacy options and you should be able to find the under the security “tab”. Here’s a handy direct link if you find it tricky to find.
You can read more from Facebook’s Engineering team on this topic, and the gradual adoption of HTTPS across the social network, in their blog post.
If you are on Facebook, and want to be kept updated with news about security and privacy risks, and tips on how to protect yourself online, join the Graham Cluley Security News Facebook page.
Been using it since the day it came out. Now I have two demands:
1. Use a separate private key for every user (like Google)
2. Don't give the NSA every private key.
I know number 2 will never be done. sigh
"HTTPS everywhere" suffers badly at the hands of the law of unintended consequences.
Graham opined "This is good news for privacy-conscious social networking users" (from the leader on the homepage to this item).
Yes, but bad news for the privacy conscious who are not security savvy enough to not require the kind of "assistance" that most have provided to them by the likes of antivirus/internet security/etc software. That is, it is bad news for about exactly the same set of people for whom it is reputedly good news. People aware of the privacy issues of non-HTTPS browsing while on open internet connections are likely also to not use, or at least not need, such security assistance, whereas those unlikely to be aware of the privacy issues will be those who need the (trivial) "protection" provided by such security software.
Checking web traffic "on the wire" is the preferred option for such security products, as that removes the multitudinous hassles and endless incompatibility issues with ever-changing APIs across changing versions of multiple web browsers. It allows for the protection of all users regardless of which web browser and other web-enabled applications they use and independent of whether those applications provide suitable plugin capabilities to allow third-party applications to "security enhance" them.
"HTTPS everywhere" breaks that. "HTTPS everywhere" pushes the developers of such "internet security" products to implement HTTPS-breaking proxies so their security software can decrypt HTTPS traffic to enable their software to keep doing what its users expect.
Of course, that means breaking the validation chain and thus removing the privacy and non-tamperability that the presence of the HTTPS connection supposedly guarantees in the first place.
Users of such security software already put a great deal of trust in the developers and providers of such software though, so presumably those users will be quite happy to have their security software providers interjecting themselves into their HTTPS traffic. If not, then these users of security software will have to choose lower levels of security protection as the cost of using HTTPS-only sites. (Yes, I know that Facebook did not announce it was going HTTPS-only, but changing to "HTTPS by default" is effectively the same thing for 99.999% of Facebook's users who "need" security software.)
As more big sites such as Facebook go the "HTTPS everywhere" route, security vendors who have resisted implementing HTTPS-breaking proxies will feel increasingly compelled to implement such functionality in their products and their users will have to choose between the true privacy promised by HTTPS or the enhanced security promised from their (purchase of) security software.