689608 - connections established via self-signed certs should be allowed to set HSTS for their domain

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[DRC]

Firefox ignores the hsts header while pening a site with a self-signed certificate (also in this case with a wrong dns name) .

With noscript installed the header is considered and the site is fetched over https.
Also google chrome consider that header and fetch the site over https (letting the user choose what to do displaying the common red page error about the certificate).

I read the draft https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-02 
who says that the hsts header must be ignored in case of "an error" (also in case of a self-signed certificate), but then it says that if a company would deploy her ca she could both give users the ca cert or "in addition or instead, distribute to their users' browsers the end-entity certificate(s) for specific hosts.". 

This clause is somewhat equal to saying that if the user trust that certificate then that certificate has "no error" , but someone on #security on irc.mozilla said that taking into consideration the author of the draft (paypal) maybe he would intended something different, because the situation of crafted certificated must be largely avoided.

Now I'm asking myself what is the right behavior  regarding the hsts header, should this must be considered also  this has an error and the user trust that certificate through a permanent exception (like noscript and chrome do) or not, considering that firefox permits overrides?

Comment 1

[Sid Stamm [:geekboy or :sstamm]]

Our current approach is to treat anything that requires the user to add a certificate exception (self-signed, invalid, etc) as an "untrusted connection."  This helps avoid a situation where an attacker (including malicious captive portal) is able to set HSTS state for a site that doesn't want it.  I will admit that situation is a bit contrived, but it results in a DoS on the legit site.

If the user installs a custom CA certificate, any end-entity certs that chain up to that CA certificate will not require an exception and will be valid for establishing HSTS on a site.  

This bug seems to be requesting a tweak to our implementation: connections established via self-signed certs should be allowed to set HSTS for their hostname.  Do I have that right, DRC?

The spec does suggest that if a user installs an end-entity certificate in the browser and that cert is used for an HTTPS connection, HSTS should be honored.

I think there's a difference between importing a certificate and adding an exception, but I'm not sure. Can someone more familiar with NSS/PSM chime in here?

Comment 2

[DRC]

(In reply to Sid Stamm [:geekboy] from comment #1)
> This bug seems to be requesting a tweak to our implementation: connections
> established via self-signed certs should be allowed to set HSTS for their
> hostname.  Do I have that right, DRC?

Quite yes, I was asking if I misunderstood the draft cause of the different behavior of noscript/google-chrome/firefox, but I understand that must be avoided the situation where a malicious host assign an hsts for another site (this is why that site must be fully trusted in order to hsts to makes sense. I don't know here if via override or trusting the ca/leaf certificate, installing it somewhere, makes difference).

but anyway surfing on a site that I trust, without having the ca/leaf cert installed, on https (and that presents an hsts header) will be broken with this implementation, because the site is always fetched via http.
here I am referring to this:
  2.  The UA terminates, without user recourse, any secure transport
       connection attempts upon any and all secure transport errors or
       warnings, including those caused by a web application presenting
       self-signed certificates.

this is somewhat confusing. does in the latter case the host not present the hsts header at all?

Comment 3

[Sid Stamm [:geekboy or :sstamm]]

I'm not sure I fully understand your question, DRC.  The HSTS header only affects *future* connections to the host, not the current one.  This is why it is ignored when encountered via HTTP and also why it is ignored when encountered via a session where the user had to jump through hoops to connect (override warnings).

The clause (2) you present above says that, if a host has previously been identified as HSTS (it served the header over a fully trusted and secure connection) the user is not allowed to override any warnings about invalid connections for that host.  This is the part of the spec that catches MITM attacks deployed with invalid cert chains if a host is identified as HSTS host.

That reasoning plays into why Firefox doesn't honor HSTS headers encountered during HTTPS sessions involving self-signed certs: a user may connect the first time, click through to override the warning, but next time the click through won't be available (due to that clause you identified from the spec).

Comment 4

[DRC]

ok now I'm getting the whole point and thinking that noscript and google-chrome are susceptible to that type of mitm attack, is that correct?

btw, thanks for the response.

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

I am not familiar with details of how the implementations in chrome and noscript work, but those pieces of software might have different users in mind.  I believe the average Firefox user won't be interested in or understand what they're doing by accepting self-signed certificates.   HSTS is intended for exactly this audience: users who are non-technical and we hope won't be adding certificate overrides.

The more tech-savvy users who understand HTTPS, want to accept self-signed certs, and know what they're doing can install an add-on to get the HTTPS-forcing behavior they need for those hosts that have certificate warnings/errors.

Firefox should not observe HSTS headers over connections that Firefox considers "unvalidated" and that result in a warning page. Self-signed certs, while not usually malicious, are not explicitly trusted by any of the roots and cause a "warning or error" in Firefox, identifying the connection as one that cannot support HSTS.

I'm going to close this bug INVALID since this behavior is intended (especially the part in comment 0 about allowing HSTS even with a domain mismatch).