HSTS preloading

[jsha]

@JuergenAuer

hopto.org is a public suffix, so if you send preload, another user may add your site to the Google preload list.

Note: This doesn't have to do with being a public suffix or not. Any site that sends the preload flag on an HSTS header may be added to the Google or Mozilla preload list at any time by any person.

did you add a firewall? An open port 80 is required, as @Osiris wrote. But your site doesn’t answer connecting port 80.

Ah, this might be due to the latest version of Certbot using the http-01 challenge. It's possible that this domain name never accepted port 80 requests, but that wasn't previously an issue because Certbot would use the tls-sni-01 challenge on port 443. That might explain why nextcloudpi failed to renew recently, if it was updating its Certbot install.

@verduron, can you tell us more about what nextcloudpi uses under the hood? And when you regain access, can you share some logs of the latest renewal attempt?

[JuergenAuer]

@jsha

Any site that sends the preload flag on an HSTS header may be added to the Google or Mozilla preload list at any time by any person.

Really? Try it:

https://hstspreload.org/?domain=community.letsencrypt.org

Error: Subdomain community.letsencrypt.org is a subdomain. Please preload letsencrypt.org instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.)

[stevenzhu]

@JuergenAuer

Error: Subdomain community.letsencrypt.org is a subdomain. Please preload letsencrypt.org instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.)

That means you could only submit the domain itself to preload list... (Which always would include its subdomain or any other nested subdomains)

[jsha]

@JuergenAuer

Error: Subdomain community.letsencrypt.org is a subdomain. Please preload letsencrypt.org instead

I think this is a separate issue. To summarize:

• Only registered domains (i.e. effective TLS plus one label) may be added to the preload list.
• If such a domain sends the preload parameter, it can be added to the preload list by any person, regardless of PSL status.

But maybe what you are saying is that for subdomains of registered domains (www.example.com), they cannot be added to the preload list even if they send the preload parameter?

[JuergenAuer]

It's the context of the question.

Seeing thibmus.hopto.org my first idea: "Oh, it's a subdomain, so sending "preload" isn't a security problem.

Then I checked the domain - "oh, hopto.org is a public suffix, so thibmus.hopto.org is a domain, not a subdomain".

Then comes the problem:

@jsha

If such a domain sends the preload parameter, it can be added to the preload list by any person, regardless of PSL status.

Now I see this sometimes: Domains, starting with certificates. But there are some errors, certificate renew doesn't work. But HSTS is set with the preload directive.

HSTS + preload is a wonderful feature. But certificate renewing should work. If not, a preloaded domain is a problem.

[jsha]

I think we are in agreement there. A lot of beginning advice suggests enabling HSTS, but it’s usually too big a risk unless you have experience operating an HTTPS website for a good amount of time.

[JuergenAuer]

@jsha

A lot of beginning advice suggests enabling HSTS, but it’s usually too big a risk unless you have experience operating an HTTPS website for a good amount of time.

Yep, this is the point!

Thanks.

If someone starts new, he shouldn't add HSTS or preload.

[mnordhoff]

It also goes bad when people copy and paste includeSubdomains without knowing what it means.