Facebook initially introduced full-time HTTPS (secure HTTP) as an option in January 2011.
Before that, the site protected your password during login using HTTPS, but left the rest of your session unencrypted.
The change came about because, back in October 2010, a Firefox plugin called Firesheep was released as a proof of concept that sniffing an unencrypted session after login was all an attacker needed to hijack your account.
This made Facebook’s new option welcome, but being opt-in meant it really didn’t go far enough.
So, in an open letter in April 2011, Naked Security asked Facebook to improve privacy and safety by turning on HTTPS for everything.
In November 2012, Facebook finally did move to make secure browsing a default, at least for users in North America.
And on Wednesday, Facebook announced that it is now using HTTPS by default for all users, so the rest of the world has finally caught up. (Well, almost. Some mobile phones and carriers don’t fully support HTTPS.)
Why did it take so long?
Because it involved a lot of moving parts, explains Facebook software engineer Scott Renfro.
Namely, it involved getting third-party application developers to upgrade, getting web-browser cookies to be compliant, controlling referrer headers, and migrating users to HTTPS without disrupting “in-flight” sessions, i.e. upgrading people while they’re actually using the site.
Performance has also been a huge challenge, Renfro says, given the extra hoops browsers have to jump through with HTTPS:
In addition to the network round trips necessary for your browser to talk to Facebook servers, https adds additional round trips for the handshake to set up the connection. A full handshake requires two additional round trips, while an abbreviated handshake requires just one additional round trip. An abbreviated handshake can only follow a successful full handshake.
Here’s an example from Renfro of how that extra latency can make users with already-slow connections suffer yet more, and how Facebook has eased the pain:
If you're in Vancouver, where a round trip to Facebook's Prineville, Oregon, data center takes 20ms, then the full handshake only adds about 40ms, which probably isn't noticeable. However, if you're in Jakarta, where a round trip takes 300ms, a full handshake can add 600ms. When combined with an already slow connection, this additional latency on every request could be very noticeable and frustrating. Thankfully, we've been able to avoid this extra latency in most cases by upgrading our infrastructure and using abbreviated handshakes.
Facebook’s work on secure browsing is most certainly not done, mind you: the company says it’s still working with mobile phone vendors to make it happen there.
Renfro calls HTTPS by default a “dream come true” — a goal that the company’s network, security, traffic, and security infrastructure teams have been working on for years.
When Facebook first rolled out HTTPS by default, Naked Security was stuck with a heap of “Dislike” t-shirts that didn’t seem appropriate anymore, so the team gave them away to readers.
Sorry, I don’t know of any plans to print up “Like” t-shirts over the news that HTTPS by default is finally, for the most part, a dream come true.
But, Facebook engineers, here are two big, virtual thumbs-up for the work you’ve done. Let’s hope it works out well for the mobile outliers, as well.