Facebook changes the logic of their TLS policy (partly due to our research), by implementing a ‘two-way’ HSTS

Facebook and privacy. The recent scandal from the social network within the last few weeks does not exactly make it the best example in regards of privacy or secure connections in general. Yet, this is not the issue now. It is certain that it has been the first website (or rather, ‘platform’) to take a very interesting and innovative step in the TLS renewal policy, which the internet has seen within the last few years. Which involves the reinforcement of the TLS concept in general on all fronts: “TLS Everywhere”, free and accessible certificates, HSTS, Certificate pinning, Certificate Transparency, in order to set aside the old protocols… This is a deep revision of the ecosystem in which Facebook (and Instagram) unite together with a more than interesting proposal.

You already know what HSTS is all about… the server sends a header to the browser in order to remember that the redirection of the HTTP and HTTPS must be done ‘locally’ (through a redirect type 307), omitting the danger from a network abduction. The web which provides this header, should obviously, be available for HTTPS, and guarantees a minimum good practice with the authentication and encryption which TLS provides. So far, so good, we have talked about this issue a few times, but what if we turn the tables? This is what they thought from Facebook; therefore, they ended up with a more than interesting concept in order to improve overall security, which could be imitated by other platforms.

HSTS has some gaps
In its official security blog, Facebook announced a security update a few weeks ago from the Facebook links. So what did it consist of? In Jon Millican’s post (an engineer from Facebook’s data privacy team) he introduced the HSTS concept and following on from this, he announced a series of known HSTS weaknesses (they come as standard with the mechanism, practically), which they were going to try and cover up with this new approximation, which we can see here:

Not all of the browsers support HSTS: although it is certain that the large majority of them do. It still is not a very strong argument, but it has some standing.
The Preload is not so dynamic: of course, the preload is there to cover this ‘TOFU’ (Trust On First Use) gap which is the Achilles’ heel of HSTS. This first connection with a site, which is carried out in clear text, because they still have not sent the first HSTS header. This ‘preload’ list is embedded in the browsers, and it is certain that it will not result as dynamic as it should be. It is managed by Google, but many people use it and it is updated within the browser versions.
Not all of the browsers implement HSTS how they should. Here they reference our research which was presented in the Europe Black Hat 2017, which demonstrated that Chrome, Firefox and Internet Explorer manage HSTS and HPKP in a questionable manner and also which assumes a problem which they try to resolve with a proposal.

Facebook mentions our research as part of their argument to implement this improvement

With these arguments at hand, they proposed a solution from their side. What if they are the ones in the almighty position, who add the “S” to any HTTPS links to other sites on Facebook and Instagram?

HSTS… in both directions.

Many people ‘live’ within these webs, and when they visit something, it goes from there and towards another bugged domain in the links which Facebook ‘accommodates’. Their precise idea is that Facebook adds ‘S’ to the protocol, even if the user who wrote it and is linked to it, did not do so. Thus, what they have decided is the following:

In order for all of the domains presented in Facebook and Instagram to be ‘bugged’ by a user, and furthermore found in the official Google ‘preload’ list, they will add an ‘S’ so that it can be browsed in a safe way. Thus, they cover up potential users with a deactualized list or they use a browser which does not support it.
They will “crawl” the web in general by themselves in search of sites which provide HSTS. If they are sure that they can be trusted (we do not know how), they will add more and more domains each time to their list, to add them from their own servers, the “S” and those users who click on it do not depend on their browser to benefit from a HSTS from the Facebook platform.

In summary, a reverse HSTS which compliments potential mechanism gaps, should maybe imitate others by their simplicity in relation to their potential advantages. To work from the point of view of a platform purely in the server, as a result of something maybe intrusive but useful in the context of Facebook and Instagram, due to their diverse user profiles and their popularity. This laudable initiative was tarnished shortly after its announcement by the Cambridge Analytics scandal.

HSTS… for everyone

In regards to filling the gaps that HSTS could leave, let’s not forget that Google has already taken a very interesting step in this direction. In addition to everything we already know, Google is also a top-level domain registrar… as for example.gle, .prod, .docs, .cal, .soy, .how, .chrome, .ads, .mov, .youtube, .channel, .nexus, .goog, .boo, .dad, .drive, .hangout, .new, .eat, .app, .moto, .ing, .meme, .here and so on up to 45. In October, they announced that they will upload the preload list by default to anyone who registers a domain with them. This means in practice that it forces them to implement TLS from the outset since Chrome will access them through port 443 whether they want to or not.

To conclude, we should not forget that this year Google also wants to flag up straight away anything via HTTP as “not secure” (for now it has the words “not secure” in the address bar, but the red cross will also be added in Chrome). Whereby the message would almost cease to exist for the unencrypted traffic; yet it is also an opportunity for certificate and CA creators…

In the end, whichever HTTP link will be marked as not secure

New PinPatrol versions

Of course, speaking of HSTS, we have new PinPatrol versions for Chrome and Firefox; where you can control the HSTS and HPKP entries better from the browsers, also with usability and compatibility improvements.