On 18 January, the .bank and .insurance top level domains became the first not operated by Google to enforce a new security protocol across an entire TLD.
fTLD Registry Services’ (fTLD) domains, .bank and .insurance, enforced this new type of encryption – HTTPS secure encryption via the HSTS preload list. The new generic TLDs offered by fTLD have always been required to use HTTPS encryption. The HSTS preload list will prevent non-compliant, insecure HTTP sites from loading at all. Google added both TLDs to the Chrome HSTS preload list on 18 January for a full rollout on 5 March, 2018, ensuring that all communication and transactions with .bank and .insurance domains are secured at the highest level with HTTPS encryption.
The benefit for fTLD, their registrants and customers of registrants, particularly in the finance and insurance industries where trust is of the utmost importance, is the added security. Combining secure HTTPS sites with fTLD’s verification process is intended to increase customer confidence by ensuring that communication and transactions with the site are encrypted and secure, and that the organisation is who it claims to be and not a malicious spoofed site meant to gather personal information for nefarious use.
But what is HSTS? “The HTTPS Strict Transport Security (HSTS) preload list is built in to all major browsers (Chrome, Firefox, Safari, Internet Explorer/Edge, and Opera)”, explained Google in a post on their security blog. “It consists of a list of hostnames for which browsers automatically enforce HTTPS-secured connections. For example, gmail.com is on the list, which means that the aforementioned browsers will never make insecure connections to Gmail; if the user types http://gmail.com, the browser first changes it to https://gmail.com before sending the request. This provides greater security because the browser never loads an http-to-https redirect page, which could be intercepted.
“The HSTS preload list can contain individual domains or subdomains and even top-level domains (TLDs), which are added through the HSTS website. The TLD is the last part of the domain name, e.g., .com, .net, or .org. Google operates 45 TLDs, including .google, .how, and .soy. In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our 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. Moreover, since it typically takes months between adding a domain name to the list and browser upgrades reaching a majority of users, using an already-secured TLD provides immediate protection rather than eventual protection. Adding an entire TLD to the HSTS preload list is also more efficient, as it secures all domains under that TLD without the overhead of having to include all those domains individually.”
HSTS is a step on from HTTPS. “Connections to websites are encrypted using HTTPS, which prevents Web traffic from being intercepted, altered, or misdirected in transit. [Google] have taken many actions to make the use of HTTPS more widespread, both within Google and on the larger Internet.”
Google started “defaulting to HTTPS for Gmail and starting the transition to encrypted search by default” in 2010. “In 2014, [Google] started encouraging other websites to use HTTPS by giving secure sites a ranking boost in Google Search. In 2016, [Google] became a platinum sponsor of Let’s Encrypt, a service that provides simple and free SSL certificates. Earlier this year [Google] announced that Chrome will start displaying warnings on insecure sites, and we recently introduced fully managed SSL certificates in App Engine.”
And going forward Google “would like to see TLD-wide HSTS become the security standard for new TLDs.”
