The Google-run .app TLD was always destined to draw attention and scrutiny, from the moment it fetched a then-record ICANN auction price of $25 million. Since it reached General Availability in May it has gained more than 250,000 registrations making it one of the world’s most successful TLDs.

However perhaps more interesting was Google’s choice to add the .app TLD and its widely used .google extension to the HTTP Strict Transport Security (HSTS) Top-Level Domain preload list, offering an unprecedented level of security for all domains under .google and .app.

I spoke with Ben McIlwain, Tech Lead and Senior Software Engineer at Google to learn a little more about HSTS, the benefits it offers and in particular, how this could be a significant value-add for .brand TLD operators in providing additional security to their customers.

* * *

Ryan Baker: Can you give us an overview of what HSTS actually is and why it’s important?

Ben McIlwain: On a basic level what HSTS preloading does is enforce the use of HTTPS. If applied to a whole TLD, then every domain on that TLD is required to be served securely.

Serving via HTTPS is a good first step, but it only provides optional security. Without HSTS preloading, there’s a variety of attacks that people intercepting your connection can use to downgrade it, most notably in 2009 when Moxie Marlinspike published the SSL Strip attack.

Using HSTS headers was a good first measure to improve on this, however, it’s now superseded by preloading. The HSTS header only comes into play after the first connection to a domain; if you’re connecting to a new (to you) domain and the very first connection is intercepted, then the interceptor can simply strip off that header along with any potentially present HTTPS. Preloading offers a stronger level of security because the preload list is built into the browsers themselves, and that can’t be intercepted by an attacker. So it’s always secure from the very first request.

RB: How does HSTS apply to a closed TLD such as a .brand?

BM: It’s a great fit for brand TLDs because all domains on a brand TLD are typically run by the same company, so all those domains are in that company’s control. This makes it easy to enforce the requirement to serve all sites on that TLD over HTTPS in order for them to work under HSTS, as we do with .google.

With .app we’ve also proven that TLD-wide HSTS preloading is feasible even with a large, open TLD. Obviously, it’s impractical to retrofit an already launched open TLD with thousands of domains and thus individual users, but a .brand doesn’t have that complexity. There’s a lot less risk—so there’s really no reason why you shouldn’t be doing this once you’re serving all your sites securely (and you should be!). If you haven’t launched your brand TLD yet then there’s no risk, as there are no existing possible sites to break.

And it’s worth pointing out that right now there’s still a small number of TLDs in the HSTS preload list, so anyone who gets in early can get that first-mover advantage on security and credibly say “We were on the vanguard of this next evolution in Web security.”

RB: Why is HSTS preloading at the TLD level better than doing it for individual sites?

BM: From a configuration perspective, it’s much simpler. You don’t have to worry about individually preloading sites or sending HSTS headers. You just add your TLD to the list once and all of your sites are good to go. If you can already go to your websites with https:// and they load correctly (i.e. they have valid SSL certificates), then you’re good to go for HSTS preloading.

Another benefit to preloading at a TLD level comes from the rollout process for the HSTS preload list itself. To preload an individual domain name, you enter it at hstspreload.org and it is verified and added to the list, which could take a few weeks. From there, the list is pulled by the individual browsers according to their individual rollout cycles, which typically takes several months between a change being made and being released in the next major browser version. And then there’s lag time between when a new version has been released and when users finally get around to updating their software.

To do this for every site you launch can be incredibly impractical for webmasters. But if the entire TLD has already been preloaded, then all newly-created domains on that TLD will immediately get the benefit of increased security from the first moment of creation.

For HSTS preloading as a whole, TLD-level preloading has an aggregate effect as well. There are currently a relatively small, finite number of TLDs, which is more scalable in terms of the overall size of the preload list. Keeping the list smaller saves a non-negligible amount of storage space, memory space, and CPU cycles (from checking against the list) across all the billions of desktop and mobile browser installations out there. In the future, for size reasons, the list might close to new additions of individual domain names unless they meet certain criteria, but if you add the entire TLD you wouldn’t face that problem.

And perhaps most importantly is speed. When domains are HSTS preloaded the user’s browser will always hit the https version immediately; it’ll never hit a redirect being served at the http version. That saves a round-trip to the server, which is a non-negligible speed improvement, especially for people on mobile connections.

RB: What should .brands consider before HSTS preloading?

BM: The main thing to consider is that if you have any domains on your .brand TLD that are not serving on HTTPS, those domains will stop working if you preload the TLD. So the important first step is to look at all the domains you have in use and ensure that all of them work with https://, which of course you should already be doing anyway (but HSTS is a useful forcing function).

You will thus need to have an SSL certificate for every domain on the TLD, even if that domain is just redirecting elsewhere. If you’re using a hosting platform provisioning these automatically for you, then hopefully that will already be covered (like through the use of Let’s Encrypt). The targets of the redirects will also need to be secure if they are on an HSTS-preloaded domain as well.

Once you’ve done this due diligence then the next step is simple: Add the TLD to the HSTS preload list. It will then roll out in a future version of major browsers in a couple of months. Other than the obvious check that every domain on the TLD is serving over HTTPS, there are no other “gotchas” to worry about. There’s just that one simple requirement.

RB: Do users experience any difference interacting with HSTS preloaded TLDs (such as the ‘Secure’ marker displayed for sites serving via HTTPS)?

BM: Currently there’s no visual difference between HSTS preloaded domains and other secure domains, however, there may be in the future. In the very near future, Chrome will show “Not secure” right next to the address bar for all insecure domain names (those served over http://). This is, of course, scary to see as an end user. You’ll never have that problem on an HSTS preloaded TLD because everything on there already has to be served securely. So it’s another way to avoid the poor user experience of seeing a warning due to having an insecure domain name; being insecure is no longer even an option.

* * *

It was great to speak with Ben and get his insight on HSTS and how it can apply for TLD operators. For most brands, a huge focus is placed on security to ensure a stable and trustworthy experience for consumers. HSTS preloading at the TLD level could be an opportunity for .brand operators to further strengthen that protection and get in at the ground floor of Google’s latest development.

In short, the only requirement for .brand TLDs to be successfully HSTS preloaded is ensuring all sites on the TLD are serving content securely—which is already a requirement for most major organizations.

For almost no additional effort, .brand TLDs can take advantage of HSTS preloading to provide further peace of mind for customers that engaging with their brand online is a safe and secure experience.

You can watch Ben’s presentation at this year’s Google I/O conference to hear more about .app and HSTS. If you’d like to know more about how to implement HSTS pre-loading on your .brand TLD, reach out to Neustar today.

This piece was originally published on MakeWay.World.