Closed Bug 1606802 Opened 3 months ago Closed 2 months ago

Security exception for preloaded HSTS certificate not working after untrusting CA

Categories

(Core :: Security: PSM, defect)

68 Branch
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: estellnb, Assigned: richard)

Details

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I have deleted all default certificates by compiling libnssckbi.so with an empty lib/ckfw/builtins/certdata.txt. This was necessary because there are many rogue certificates among these. If I visit now a site I can acknowledge individual site certificates one by one. Unfortunately this does not work for all sites. It does not work for mail.dotplex.com, for amazon.com and similar site like google.com or qwant.com.

Actual results:

I get the error SEC_ERROR_UNKNOWN_ISSUER. As far as good; I can add the required CAs with certutil. For SEC_ERROR_UNKNOWN_ISSUER it should suffice to add with -t "c,," as we do not want to trust these certification authorities. They could be rogue CAs. However if I add with "c,," I still get SEC_ERROR_UNKNOWN_ISSUER while adding with "C,," does not give that error. However adding the CA as trusted CA is worthless because then Firefox accepts all certs from this CA without warning.

Expected results:

This is a bug. SEC_ERROR_UNKNOWN_ISSUER says that the issuer is unknown and not that the issuer must be a trusted one. Please make Firefox search all issuer CAs, also untrusted ones or allow to ignore this error message by allowing to manually accept these certificates.

Component: Untriaged → Security: PSM
Product: Firefox → Core

SEC_ERROR_UNKNOWN_ISSUER is the error Firefox uses to indicate that no trusted issuer could be found, which is the situation you're describing, as far as I can tell (the algorithm can't differentiate between "the trust bits were removed from this certificate" and "there exists a path to a trusted certificate, but it requires an intermediate certificate we're not aware of").

That said, what you're describing is not a supported configuration of Firefox. Accepting each site's certificate one-by-one is not secure (how do you know a network attacker hasn't intercepted your connection and replaced the real certificates with their own?)

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → INVALID

I use DANE to acknowledge individual certificates and on a secure computer I only visit a restricted number of sites.
This is an error. Please fix.

It is a shame that Mozilla compromises the security of those who need it most! Comparing the sha256 hash and accepting user picked certificates is currently the only way to be secure with Firefox.

It should be possible to add a manual security exception for HSTS (HTTP Strict Transport Security) sites as is possible for any other site in the web. Manually acknowledged sites are most trustworthy since it is the user on his own who has acknowledged access rights. You are not forbidden to visit a site hosted via pure http either. It is scorn to the ordinary user that something which pretends to provide elevated security does actually compromise the security of users who care the most about it.

This is not an invalid report. Please reopen quickly!

Flags: needinfo?(dkeeler)

If you want to trust individual server certificates, you should be able to do so using certutil as you've described in comment 0.

Again, though, what you're describing is not a supported way to operate Firefox. We have a limited amount of engineering resources, and this is not something we're going to spend time on.

Flags: needinfo?(dkeeler)

You can add user certificates with certutil -t "P,," to the database and they will be displayed correctly as trusted server certificates. However when you try to connect to such a site you get a warning as if these certificates would not be present at all. Fortunately this is a non-fatal bug and you can accept these peer certificates manually after comparing the sha256 hash of these certs. It is different with HSTS certificates: You can currently neither add a user exception for them nor add the required CAs in untrusted mode to the database. If you do currently not have the resources to fix this bug please mark as WONTFIX, and not as resolved invalid. I would lovingly like to try to approach a fix on my own but unfortunately I do not have the resources to do so at the moment. My computers are currently under heavy attack and I have already had to wrack two operating system installations.

First off, there are no "HSTS certificates" but there is a "Strict-Transport-Security" aka "HSTS" HTTP header. What you are probably running into is section 8.4 of RFC 6797 that states:

8.4. Errors in Secure Transport Establishment

When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 12 ("User Agent Implementation Advice"))
if there are any errors, whether "warning" or "fatal" or any other
error level, with the underlying secure transport. For example, this
includes any errors found in certificate validity checking that UAs
employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
as via TLS server identity checking [RFC6125].

However, I cannot trigger the behaviour described in comment 7 using Firefox 72.0.1.

I created https://self-signed.vdberg.org/ which has a certificate signed by my untrusted Test CA. I also created https://hsts-test.vdberg.org/ which additionally sends a Strict-Transport-Security HTTP header. For both sites Firefox displays "Warning: Potential Security Risk Ahead" and after selecting "Advanced" the "Error code: SEC_ERROR_UNKNOWN_ISSUER" you mentioned. In both cases I can still select "Accept the Risk and Continue" option and Firefox will create an exception for the site.

I was able to reproduce the scenario in comment 7 after all. It has to do with preloaded HSTS certificates, see https://hstspreload.org/

For example: gmail.com is an HSTS preloaded certificate that is signed by "GlobalSign Root CA - R2".

To reproduce the issue:

  1. In about:preferences#privacy -> View Certificates -> Authorities -> GlobalSign Root CA - R2 -> Edit Trust -> Uncheck "This certificate can identify websites."
  2. Visit https://gmail.com/
  3. Firefox now displays "Did Not Connect: Potential Security Issue" and the "Advanced" section has no "Accept the Risk and Continue" option
  4. In about:preferences#privacy -> View Certificates -> Servers -> Add Exception -> Enter https://gmail.com/ as Location -> Get Certicate -> Confirm Security Exception
  5. Visit https://gmail.com/
  6. Firefox still displays "Did Not Connect: Potential Security Issue"

The bug here is that for preloaded HSTS certificates the user has to trust the CA to be able to visit the site. Only trusting the server certificate should be enough though.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: SEC_ERROR_UNKNOWN_ISSUER though all CA certs have been loaded → Unable to add exception for preloaded HSTS certificate after untrusting CA
Summary: Unable to add exception for preloaded HSTS certificate after untrusting CA → Security exception for preloaded HSTS certificate not working after untrusting CA

This bug boils down to a narrow interpretation of section 12.1 of RFC 6797. This states "the user should not be presented with a dialog giving her the option to proceed". Nowhere does the RFC state or imply that a manually added and approved server certificate should not be allowed.

I've attached a patch that allows the site to be visited in such situation. If the root CA is not trusted and no server certificate has been added and manually approved by the user RFC 6797 is respected and no "Add Exception" option is being offered.

Assignee: nobody → richard
Status: REOPENED → ASSIGNED

Currently if a server has HSTS preloading or HPKP enabled and the user
untrusts the CA the site cannot be visited. Visiting such server should
still be possible if the user manually adds an exception for the server
certificate.

Attachment #9121781 - Attachment is obsolete: true

The priority flag is not set for this bug.
:keeler, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)

The way to explicitly manually trust a server certificate when you don't trust the CA is to use certutil as described in comment 0 (as I've already said in comment 6). The certificate error exception mechanism is not the way to do what you want, and attachment 9121783 [details] removes an important security check in our implementation.

Again, removing the trust settings from the certificate authorities shipped with Firefox is not a supported mode of operation. This is not a bug in Firefox. Please do not reopen this bug.

Status: ASSIGNED → RESOLVED
Closed: 3 months ago2 months ago
Flags: needinfo?(dkeeler)
Resolution: --- → INVALID

If Google Chrome implements it the way that you can manually acknowledge HSTS certificates I ask you why Firefox can´t? You know yourself that this so called "security feature" does in deed compromise security. Please do also not mark as invalid as the originally stated bug - as you have said by your own - is still unresolved.

You need to log in before you can comment on or make changes to this bug.