How does Google force HTTPS on their .app TLD?

Question

In I/O 2018 Google announced their new .app TLD and they said that it will be HTTPS only.

I thought that DNS just maps domain names to IP's.

How are they forcing HTTPS?

Answer 1

(a little offtopic here)

It is called HSTS Preloading, see https://hstspreload.org/

HSTS (HTTP Strict Transport Security) is a way for servers to reply to clients: please contact me over HTTPS only (see https://www.troyhunt.com/the-6-step-happy-path-to-https/ for examples). It enhances security but still does not solve one case: the first connection to a given server can happen over HTTP before the browser learns it should have done an HTTPS instead.

Hence come the "preloading" of HSTS.

Basically this is an hardcoded list embarked in all major browsers code (see https://caniuse.com/#feat=stricttransportsecurity for compatibility depending on browser and version, or see at bottom for links to code[1]) that says which domains/TLD are HSTS enabled, which means no HTTP connection allowed to them at all.

Note that:

1. Anyone can submit names to this list by following some requirements, see https://hstspreload.org/#submission-requirements
2. Google (as it started with Chrome but it is now spread among browsers) welcome inclusion of TLDs and not only hostnames, see end of document at https://hstspreload.org/ ("TLD Preloading")

They already did add .DEV in the past (the TLD by itself is not live yet, but Google will launch it "soon") which broke many developers setup where they used (wrongly) a .DEV domain name to name their local resources and as soon as their browsers were updated with the newer HSTS preloading list, they refused to connect to their local .DEV host without HTTPS. You can find here and elsewhere (ex: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) many horror stories of developers up in arms against that and also may people offering bad solutions for that (like disabling HSTS preloading which is a very bad idea).

Also when you buy a .APP domain name (and it will be same for .DEV), Google (as registry of .APP) made sure contractually with all registrars that they will, during checkout of a .APP domain name buy, display a prominent message saying something along the line of: ".APP is a secure TLD and websites will only work with an SSL certificate(sic); make sure to buy an SSL certificate" (SSL certificate is straight out of Google documentation and this is very sad to read out of them since it is a doubly wrong term, it should have been an "X.509 certificate" or, in order not to frighten anyone, at least a "certificate used for TLS communications", noone should use SSL anymore nowadays...).

By the way, .APP opened for the public at standard prices yesterday, May 8th.

Of course all of that is only related to web browsing. You could set any other kind of service, like email, on top of a .APP domain name, without any mandatory TLS (which of course is not a good idea nowadays but nothing will refrain you from doing that). For email, there is ongoing discussion to have basically HSTS but for MTAs, see https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

[1] see some source codes with the HSTS preloading list:

• https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
• https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc

or you can use the API at https://hstspreload.com/ to learn if a name is on the list