Facebook has been busy making a number of changes to its underlying infrastructure in order to turn on secure HTTPS browsing for all of its users by default.
The social networking site had enabled optional HTTPS connections two years ago to protect information that was being sent on less secure networks, such as at public internet cafes and airport terminals. Login details have always been sent over HTTPS, but before the option, anyone could potentially sniff the traffic sent over the network once a user's login session had been established.
Facebook has been watching how many users turn secure browsing on, and the uptake has been quite slow. Between April 2011 and the end of 2012, when it started migrating users to HTTPS by default, only around 35 percent of users opted to use the more secure option.
The relatively low adoption rates have been a bit of a mixed blessing for the company, however. In order to enable HTTPS for all of its users, it has had to make some significant changes to its back-end systems and developer policies.
When it first rolled out HTTPS, Facebook said it would slow down sessions, and that third-party applications might break.
The former latency issue is addressed in two ways. One is by Facebook's investment in physically creating or moving its infrastructure so that it is closer to the customer. The second is a cut-down version of how Facebook sets up secure connections between the user's computer and its servers.
"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," the company's London-based security infrastructure team software engineer Scott Renfro wrote on its engineering page.
These abbreviated handshakes are sometimes referred to as resumed TLS handshakes. A simplified explanation is that once a full handshake is established, a common secret unique to the session can be set up and verified, which no longer requires a complete handshake to be established on each and every session. This cuts down on the number of round trips that must be made to ensure the session is secure.
Researchers from Google further refined the technique in 2011, reducing latency by one round-trip time through a method called TLS False Start. It is not known whether this technique is being used by Facebook in its HTTPS implementation.
Incompatibility with third-party applications has been an ongoing issue for Facebook. It told developers that they had 90 days to switch to its OAuth 2.0 implementation and deliver their own apps over HTTPS. This meant that developers had to purchase SSL certificates at their own cost. Although the official switchover period was 90 days, Facebook actually gave developers 150 days to secure their applications.
But the end result is that applications that play along don't break full encryption. If applications didn't comply, they would end up serving content that could potentially be viewed or modified by an attacker, then placed alongside secure content without the user being aware.
Facebook's work on security isn't completely finished, however. In a similar move to Google, it is adopting 2048-bit RSA keys for its SSL certificates.
It is also looking at using elliptical curve cryptography, which, when combined with Diffie-Hellman key exchange, provides forward secrecy. This means that attackers will be unable to store sniffed traffic today, and break it in several years' time, when the keys used to secure it can be broken with faster computers. Facebook is again playing catch-up with Google in this regard, with the web giant already providing forward secrecy since the end of 2011.
The other announcement from Facebook today is the news that more of users' public content will be made accessible on other sites. It is introducing an embedded posts feature that will allow other sites to take public content from Facebook and post it to their own sites.
It is similar to Twitter's own feature that many sites already use to embed tweets directly in articles. Facebook has said that it is working with CNN, Huffington Post, Bleacher Report, People, and Mashable at first, but that it expects to make it more widely available soon.