Which is something you probably shouldn't be doing in the first place.
Browsers aren't supposed to accept HSTS on self-signed certs so connecting to a self signed localhost shouldn't do this.
Which is something you probably shouldn't be doing in the first place.
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.
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.