HSTS option on .dev domains

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?

3 Likes

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.

1 Like

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?

1 Like

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

3 Likes

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?

1 Like

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)

2 Likes

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.

6 Likes

Why? What value is there in overriding user choice?

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.

2 Likes

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?

1 Like

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?

2 Likes

I agree, a better UX is worth it!

For HSTS, the same value as including free TLS certs for people. So if one’s site is protected at one level with the cert, having it be properly configured for HSTS would be of additional value, both time-wise and for security.

This issue is, I believe the one of most importance regarding the security of workers.dev subdomains -