Closed Bug 1704843 (CVE-2021-29974) Opened 3 years ago Closed 3 years ago

HSTS includeSubDomains not properly enforced


(Core :: Security: PSM, defect)

Firefox 87



90 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- verified


(Reporter: pege, Assigned: timhuang)



(Keywords: sec-moderate, Whiteboard: [post-critsmash-triage][adv-main90+])


(3 files)

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

Steps to reproduce:

  1. Go to

As part of the response, Firefox is informed about a HSTS policy that includes subdomains:

Strict-Transport-Security: max-age=43200;includeSubDomains

  1. Visit

As result of the HSTS policy received early, the request is made using https but a "Accept the Risk and Continue" is still shown.

Also, clicking on SSL_ERROR_BAD_CERT_DOMAIN reveals that Firefox doesn't think there is a HSTS policy in effect:

Unable to communicate securely with peer: requested domain name does not match the server’s certificate.

HTTP Strict Transport Security: false
HTTP Public Key Pinning: false

Actual results:

"Accept the Risk and Continue" button is shown.

Expected results:

As intended by the Strict-Transport-Security header, there should be no way to add an exception. I also checked Firefox 78 ESR and there the behavior was still correct.

I'm not entirely sure which component this should go in, but hopefully this is closer to the right one.

Group: firefox-core-security → crypto-core-security
Component: Untriaged → Security: PSM
Product: Firefox → Core

:baku, I don't think network partitioning is behaving correctly with respect to HSTS. Can you have a look?

Blocks: 1635828
Flags: needinfo?(amarchesini)

It looks like we're partially performing HSTS -- I do get from http: -> https, it's just carrying over the "no exceptions allowed" part.

I had a look at how Firefox for Android (87 and nightly) handles this. Turns out there an "Accept the Risk and Continue" button is shown even for domains on the HSTS Preload list. For instance, you can go to, which doesn't have a valid certificate for that name, and you'll get upgraded to https but you'll still see that Continue button.

I've tested this with Network Partitioning disabled, and the issue is still there.

And subdomains will use the same partitionKey because we are using eTLD+1 as the key. So, theoretically, the HSTS cache is not partitioned between and

Flags: needinfo?(amarchesini)

:timhuang, are you sure about this not being caused by network partitioning? When I flip the privacy.partition.network_state preference to false, the issue disappears for me and I'm told again I can't visit the page because of the HSTS policy. After flipping the switch, you have to make sure you visit again first to pick up the HSTS information and then head to

Flags: needinfo?(tihuang)

Ah, I see, there will still be an error page but cannot do "Accept the Risk and Continue" there. Sorry that I didn't understand the issue correctly. I will dig into this. Thanks.

Flags: needinfo?(tihuang)
Assignee: nobody → tihuang
Ever confirmed: true

The root cause is that we use the OAs without the partitionKey to check the HSTS state when loading the cert error page. So, the error page will have a wrong state about HSTS. However, it doesn't affect HSTS in the network layer, just only the error page.

Part 1: Use the OAs with the partitionKey to get HSTS state in nsDocShell. r=ckerschb
Part 2: Add a test to verify HSTS parameter includeSubDomains works correctly when network partitioning is enabled. r=ckerschb

Group: crypto-core-security → core-security-release
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
Flags: qe-verify+
Whiteboard: [post-critsmash-triage]

This issue is Verified as fixed in our latest Nightly build 90.0a1 (2021-05-24) On Windows, Mac and Ubuntu.

Flags: qe-verify+
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main90+]
Attached file advisory.txt
Alias: CVE-2021-29974
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.