Score:19

List of top-level domains (TLDs) that require HTTPS connections, like .dev

za flag

I know the .dev top-level domain requires all sites to support only encrypted HTTPS connections, disallowing any HTTP connections.

Are there other such TLDs?

Score:22
jp flag

A direct answer to this would eventually become outdated if more top-level domains start enforcing HTTPS using HTTP Strict Transport Security (HSTS, RFC 6797). Technically this is an HSTS policy of a TLD submitted to the preloading list. It started with Google's new TLDs,

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.

and there has even been preliminary thoughts on the possibility of protecting the entire .gov in the future:

Zooming out even further: it’s technically possible to preload HSTS for an entire top-level domain (e.g. “.gov”), as Google first did with .google. As a relatively small, centrally managed top-level domain, perhaps someday .gov can get there.

To know the current situation, one must consult the Chromium HSTS Preloaded list.

The preloaded list is also available on Chromium's GitHub mirror; especially the raw version is best for curl or wget. The list is a non-standard JSON with comment lines. It is possible to analyse it with jq after removing the comments with e.g. sed.

Here, the jq gives all domain names on the preloaded list and the grep reduces it into TLDs:

cat transport_security_state_static.json \
  | sed 's/^\s*\/\/.*//' \
  | sed '/^$/d' \
  | jq -r '.entries[]|select(.include_subdomains==true)|"\(.name)"' \
  | grep -P "^\.?[a-z]*\.?$" 

To search for public suffixes instead of TLDs:

cat transport_security_state_static.json \
  | sed 's/^\s*\/\/.*//' \
  | sed '/^$/d' \
  | jq '.entries[]' \
  | jq 'select((.policy=="public-suffix") and (.include_subdomains==true))' \
  | jq -r '"\(.name)"'
cn flag
Great answer. One thing that may be worth considering in practice is whether one might want to match [public suffixes](https://publicsuffix.org/list/) also, rather than just the TLDs specifically asked about in the question.
jp flag
@HåkanLindqvist Good point. I added an example search for that, too.
Patrick Mevzek avatar
cn flag
There is also https://hstspreload.org/ to look at current list content.
Patrick Mevzek avatar
cn flag
Google clearly started with `dev` and then added all newer ones after, `app`, `new`, etc.
jp flag
@PatrickMevzek https://hstspreload.org is only useful for individual searches; it would be laborious and inefficient to lookup every TLD one at a time, while the Git repository has the exhaustive list.
jp flag
It seems faster to get the file from the GitHub mirror with `curl https://raw.githubusercontent.com/chromium/chromium/master/net/http/transport_security_state_static.json` (or `wget`).
Patrick Mevzek avatar
cn flag
Except one minor but possible important semantic difference: the HSTS preloading list is like the Public Suffix List. A shared resource used by multiple parties. You can have no idea when each party, such as a browser, does update itself with new content from this source. As such, I feel it might be a problem to look at any specific code source. I agree that the code source is "simpler" to navigate and extract data from, yet it is slightly something different potentially, that is all I wanted to outline.
Patrick Mevzek avatar
cn flag
" it would be laborious and inefficient to lookup every TLD one at a time" Yet if you are really interested just by TLDs (and not by all possible public suffixes), there are less than 2000 of them, so it wouldn't be a big loop to do.
jp flag
A loop of ~2000 completely unnecessary HTTP requests, given there's a downloadable text file easily available...
jp flag
Also, **hstspreload.org uses the same source** for its static data, anyway: `base64.b64decode(requests.get("https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json?format=TEXT").text)` in https://github.com/chromium/hstspreload.org/blob/master/scripts/update_bulk_preloaded.py
Michael Hampton avatar
cz flag
I find it unlikely that .gov will get onto the HSTS preload list in my lifetime. Government IT moves like a glacier, and you're talking about a few thousand little unconnected bureaucratic IT fiefdoms who are unlikely to have any incentive to do anything of the sort and probably not the budget either.
jp flag
That's probably true if all the individual organization must mutually agree with the new policy. On the other hand, like said, it is relatively small and centrally managed. If the policy is enforced from the top or mandated by an act, it could happen. There is already White House Office of Management and Budget memorandum [M-15-13](https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2015/m-15-13.pdf), “A Policy to Require Secure Connections across Federal Websites and Web Services” leading towards that direction.
jp flag
According to the M-15-13, "Agencies must make all existing websites and services accessible through a secure connection (HTTPS-only, with HSTS) by December 31, 2016." Enabling HSTS would be a relatively small technical step if all the sites were already available in HTTPS. "You may say I'm a dreamer. But I'm not the only one."
walnut_salami avatar
jp flag
Is it implied that "HSTS TLD = Google owned"? Are there are ones that aren't?
Score:3
ng flag

This was generated using the procedure in Esa Jokinen's answer, but it seemed like it might be useful to have a literal list, even if it does need to be updated periodically.

HSTS Preloaded TLDs

  • android
  • app
  • bank
  • boo
  • chrome
  • dad
  • day
  • dev
  • eat
  • esq
  • fly
  • foo
  • gle
  • gmail
  • google
  • hangout
  • ing
  • insurance
  • meet
  • meme
  • new
  • nexus
  • page
  • phd
  • play
  • prof
  • rsvp
  • search
  • youtube

HSTS Preloaded Public Suffixes

(this portion of the answer is likely to go out of date faster)

  • bmoattachments.org
  • cnpy.gdn
  • gentapps.com
  • now.sh
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.