Google this week announced the addition of more of its top-level domains (TLDs) to the HTTPS Strict Transport Security (HSTS) preload list.
Built into all major Web browsers, including Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera, the HSTS preload list consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections, thus ensuring the safety of their users.
Because of the HSTS preload list, browsers will avoid making insecure connections to the sites included in it, even if the user doesn’t type HTTPS when trying to connect to a domain. Because of this set, the browser never loads an http-to-https redirect page, which could be intercepted.
The HSTS preload list, which is maintained by the Internet giant itself, can contain individual domains or subdomains, along with TLDs, which can be added through the HSTS website.
Google, which is an avid HTTPS promoter, added the .google TLD to the list in 2015 and is now rolling out HSTS for a larger number of TLDs, starting with .foo and .dev.
“The use of TLD-level HSTS allows such namespaces to be secure by default. Registrants receive guaranteed protection for themselves and their users simply by choosing a secure TLD for their website and configuring an SSL certificate, without having to add individual domains or subdomains to the HSTS preload list,” Ben McIlwain, Google Registry, notes in a blog post.
McIlwain also explains that it usually takes months before a domain name added to the list will reach the majority of users via a browser upgrade. Thus, using an already-secured TLD ensures that users benefit from immediate protection.
Adding an entire TLD to the HSTS preload list also provides increased efficiency, because all domains under that TLD are secured and adding them individually isn’t required, McIlwain says.
Considering the number of websites that use HSTS at the moment, Google’s move is certainly welcomed. Only 4.8% of all the websites use the HSTS mechanism, which ensures users that connect to them only via secure connections. This percentage has remained almost the same for a long time, although HSTS was implemented over four years ago.
In March last year, Netcraft’s Paul Mutton explained that the 95% of web servers that lack HSTS remain vulnerable to trivial connection hijacking, thus exposing users to phishing, pharming, and man-in-the-middle (MiTM) attacks.
In October 2015, David Holmes, an evangelist for F5 Networks, pointed out in a SecurityWeek column that HSTS was meant to resolve a vulnerability when a site accepts both unencrypted (HTTP) and encrypted (HTTPS) requests. The incorrect implementation of HSTS could allow an attacker to prevent the browser from receiving HTTPS redirects, he said.
Related: HTTPS Security Weakened by AV Products, Middleboxes: Study
Tags: