HSTS option on .dev domains


#1

I just bought a .dev domain and added it to my Cloudflare account. As you may know, the entire .dev gTLD is on the HSTS preload list. This is fine as Cloudflare’s universal SSL certificate covers my domain and I use the origin certificates for full (strict) encryption. However, further down on the crypto page, there is the option for the HSTS headers. Now, for other domains, this is fine however for domains whose gTLD’s are NOT on the preload list, however for those which are, isn’t this option a bit…irrelevant? No matter what setting I choose, even if I leave it off, my site is still required to have a valid certificate at all times. My suggestion is that for domains with gTLD’s that are on the preload list, simply hide that option from the UI, or lock it on and give an explanation why. The preload list is freely available to all so it wouldn’t be hard to keep track of these, it’s even in JSON format so you could even do it programatically! What are your thoughts?


#2

I agree with this, the only issue is old devices may not have an updated preload list, since some devices bundle the preload list with OS version upgrades, which not everyone updates to. Based on the git blame, new TLDs like .youtube, .new and .play were only added to preload in June 2018. This will fix itself over time, so I still think removing the hsts UI is a good idea.


#3

Also consider that there are clients which respect HSTS, but don’t use a preload list.

Given that there is no harm in adding HSTS, why bother suppressing it in the UI?


#4

Maybe proactive HSTS on Cloudflare’s part would be appropriate here then, sending the HSTS+includeSubdomains header no matter what.


#5

Yes, perhaps if a domain is on the preload list, crank the HSTS settings to the Mac and hide it in the UI so the user can’t turn them off?


#6

Maybe don’t hide it, but instead lock all the settings at max (except for X‑Content‑Type‑Options: nosniff, which is for some reason configured in the HSTS settings)


#7

I’d vote for displaying it locked in the ON position. You sure don’t want someone accidentally turning it off. HTTP/2 and IPv6 are already locked in the ON position in other parts of the dashboard.


#8

Why? What value is there in overriding user choice?


#9

HSTS would always be “on” since you can’t disable HSTS preload on the dev TLD anyways. Adding the header automatically would only increase security for devices that don’t have a preload list, so I don’t see why people should be able to turn it off.


#10

The user doesn’t have any choice, that’s the point of the preload list. The client can’t bypass the security warning and the dev can’t turn HSTS off. The TLD is designed to be ‘secure’, i.e. HTTPS only.

Therefore, if the Cloudflare user doesn’t get any choice (really), why offer them the option in the UI?


#11

The question isn’t why offer it, it’s why remove it. The code already exists to offer it, what value is there in adding additional code to the UI (and API?) to unnecessarily increase the size of every HTTPS request?