4 ms·
> 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
by throw1230 4y ago
> 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 4y agoI 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 4y ago> 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.