[throw1230]

> Browsers aren't supposed to accept HSTS on self-signed certs so connecting to a self signed localhost shouldn't do this.

There's nothing against self signed certificates working with HSTS at all. It's perfectly fine for browsers to accept HSTS regardless of who signed it.

[remram]

I think the point is that if you add a temporary exception to accept the unverified certificate, you shouldn't be left with a permanent requirement that localhost have a certificate in the future because of the HSTS header you got during that time.

[aaronmdjones]

> There's nothing against self signed certificates working with HSTS at all.

Actually, there is.

Section 8.1 of RFC 6797 opens with:

"If an HTTP response, received over a secure transport, includes an STS header field, conforming to the grammar specified in Section 6.1, and there are no underlying secure transport errors or warnings (see Section 8.4), [...]"

Section 8.4 then goes on to define "errors or warnings" as including any errors caused by UA certificate validity checks.

Additionally, section 14.3 opens with:

"The user agent processing model defined in Section 8 stipulates that a host is initially noted as a Known HSTS Host, or that updates are made to a Known HSTS Host's cached information, only if the UA receives the STS header field over a secure transport connection having no underlying secure transport errors or warnings."

(and then goes on to provide the rationale for this decision)

> It's perfectly fine for browsers to accept HSTS regardless of who signed it.

No, it isn't. This enables active attackers to cause a permanent denial of service even when you subsequently move out of their reach. That's the rationale.