Closed Bug 1511049 Opened 5 years ago Closed 5 years ago

Toggling the security.enterprise_roots.enabled pref back to false leads to insecure webpage erros

Categories

(Core :: Security: PSM, defect, P2)

All
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox63 --- affected
firefox64 --- affected
firefox65 --- affected

People

(Reporter: emilghitta, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [psm-backlog])

Attachments

(3 files)

Attached image BitDefender.gif
[Affected versions]:
Firefox 65.0a1 
Firefox 64.0b14
Firefox 63.0.3 

[Affected platforms]:
Windows 10 64bit.
Windows 10 32bit.

[Preconditions]:
Install BitDefender Plus 2019.

[Steps to reproduce]:
1. Launch Firefox.
2. Access the about:config page.
3. Set the security.enterprise_roots.enabled to "true".
4. Set the security.enterprise_roots.enabled back to "false".
5. Load the https://www.twitter.com webpage.

[Expected result]:
The webpage loads successfully.

[Actual result]:
An error stating that the "connection is not secured" is displayed.

[Workaround]
1. Set the "security.enterprise_roots.enabled" pref to "true".
2. Disable the "Encrypted web scan" functionality from BitDefender.

[Note]:
For further information regarding this issue, please observe the attached screencast.
I didn't managed to reproduce this issue using other av's (Kaspersky or Avast).
Feel free to mark this issue as duplicate (if that's the case).
Here's my guess:

Initially, bitdefender finds the user's profile and manually adds its
root certificate to the NSS certificate DB and sets the trust bits.
Meanwhile, for every other program, it installs its root in the Windows
trust store. The enterprise roots pref is false, so Firefox completely
ignores the Windows trust store. Setting the pref to true makes Firefox
search the Windows trust store. It finds the bitdefender root and
imports it (again) and sets the trust bits. Setting the pref to false
again makes Firefox clear the trust bits for all imported enterprise
roots, so the bitdefender root gets untrusted (even though in a sense
there are two copies of the root, NSS de-duplicates certificates, so
trust changes to one happen to all copies). If bitdefender doesn't do
something to make sure the trust bits remain set in the user's profile
(and some av products do this), then it will remain untrusted and the
user's profile won't be able to browse https sites.

One way we could address this problem is to check if we're importing an
enterprise root that we already know of and either skip it or make a
note of its current trust settings so we can re-set it if the pref gets
turned off.
Component: Desktop → Security: PSM
Priority: -- → P2
Product: Tech Evangelism → Core
Whiteboard: [psm-backlog]
The missing piece here for me, though, is why so many people are having issues with bitdefender just not being recognized at all. I also don't really understand how bitdefender puts its cert into new profiles created after bitdefender is installed, and in that case, how *anyone* ends up with this being completely broken...

I also suffer from this problem. When updating from 64 to 65, all https sites got broken (Avast problem). So I turned off Avast HTTPS web shiled scanning. During investigation, I also enabled and then disabled security.entreprise_roots.enabled . Since then, I can't reach en.wikpedia.org at all with this pref set to false (not even any ohter language modifications/subdomains). I even tried manually uninstalling all avast root certs. It didn't help. However, I'm unable to reproduce this issue with twitter.com.

I tried the same in a clean profile in nightly:

  1. open en.wikipedia.org -> OK
  2. set security.entreprise_roots.enabled to true, reload the page -> OK
  3. set security.entreprise_roots.enabled to false, reload the page -> SEC_ERROR_UNKNOWN_ISSUER

The error page shows me this certificate was provided, which seems completely legit to me:

-----BEGIN CERTIFICATE-----
MIIIMTCCBxmgAwIBAgIMFkDF1F0uxNlMfXxqMA0GCSqGSIb3DQEBCwUAMGYxCzAJ BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g RzIwHhcNMTgxMTA4MjEyMTA0WhcNMTkxMTIyMDc1OTU5WjB5MQswCQYDVQQGEwJV UzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEj MCEGA1UEChMaV2lraW1lZGlhIEZvdW5kYXRpb24sIEluYy4xGDAWBgNVBAMMDyou d2lraXBlZGlhLm9yZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGd1rS7GauMx J15BmViShjVMjwQJNjjw+OUhnIaqE5QF/q6c/LIvVh4N3473a7J52JcfmlfCrXvD thHzaZNEneKjggWVMIIFkTAOBgNVHQ8BAf8EBAMCA4gwgaAGCCsGAQUFBwEBBIGT MIGQME0GCCsGAQUFBzAChkFodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc29yZ2FuaXphdGlvbnZhbHNoYTJnMnIxLmNydDA/BggrBgEFBQcwAYYz aHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL2dzb3JnYW5pemF0aW9udmFsc2hh MmcyMFYGA1UdIARPME0wQQYJKwYBBAGgMgEUMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMAgGBmeBDAECAjAJBgNV HRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5j b20vZ3MvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzIuY3JsMIICxQYDVR0RBIICvDCC AriCDyoud2lraXBlZGlhLm9yZ4INd2lraW1lZGlhLm9yZ4INbWVkaWF3aWtpLm9y Z4INd2lraWJvb2tzLm9yZ4IMd2lraWRhdGEub3Jnggx3aWtpbmV3cy5vcmeCDXdp a2lxdW90ZS5vcmeCDndpa2lzb3VyY2Uub3Jngg93aWtpdmVyc2l0eS5vcmeCDndp a2l2b3lhZ2Uub3Jngg53aWt0aW9uYXJ5Lm9yZ4IXd2lraW1lZGlhZm91bmRhdGlv bi5vcmeCBncud2lraYISd21mdXNlcmNvbnRlbnQub3JnghEqLm0ud2lraXBlZGlh Lm9yZ4IPKi53aWtpbWVkaWEub3JnghEqLm0ud2lraW1lZGlhLm9yZ4IWKi5wbGFu ZXQud2lraW1lZGlhLm9yZ4IPKi5tZWRpYXdpa2kub3JnghEqLm0ubWVkaWF3aWtp Lm9yZ4IPKi53aWtpYm9va3Mub3JnghEqLm0ud2lraWJvb2tzLm9yZ4IOKi53aWtp ZGF0YS5vcmeCECoubS53aWtpZGF0YS5vcmeCDioud2lraW5ld3Mub3JnghAqLm0u d2lraW5ld3Mub3Jngg8qLndpa2lxdW90ZS5vcmeCESoubS53aWtpcXVvdGUub3Jn ghAqLndpa2lzb3VyY2Uub3JnghIqLm0ud2lraXNvdXJjZS5vcmeCESoud2lraXZl cnNpdHkub3JnghMqLm0ud2lraXZlcnNpdHkub3JnghAqLndpa2l2b3lhZ2Uub3Jn ghIqLm0ud2lraXZveWFnZS5vcmeCECoud2lrdGlvbmFyeS5vcmeCEioubS53aWt0 aW9uYXJ5Lm9yZ4IZKi53aWtpbWVkaWFmb3VuZGF0aW9uLm9yZ4IUKi53bWZ1c2Vy Y29udGVudC5vcmeCDXdpa2lwZWRpYS5vcmcwHQYDVR0lBBYwFAYIKwYBBQUHAwEG CCsGAQUFBwMCMB0GA1UdDgQWBBSt4NNfC33t2i98DfZjjYpZGMJsijAfBgNVHSME GDAWgBSW3mHxvRwWKVMcwMx9O4MAQOYafDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA 8AB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABZvUzN/YAAAQD AEcwRQIgBATdvSzbd5NwGdtkmJ5SEvEPn6A8hgAsk6GSP6hzWcgCIQDKfHQNtObs /hHPfLgXsVkcnHIbjlNwmWeiukGtGHZFMgB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZ AsEAKQaNsgiaN9kTAAABZvUzN8cAAAQDAEcwRQIgYalEnXtd/fPhjq9SXPoSPRha MmeDs0IMN5o5Y6QTKfUCIQClR1uj+B56K4tGh/mws4qugG1qSD9zfvmx8roKik3H HDANBgkqhkiG9w0BAQsFAAOCAQEAUEJyg/AZo+owG5J/LIk8EIDnyOcanmfgvdjM g8KnpBvh8l3Wb4HmOudluJhIeIbCUMwzEzSGqYQQ78n4wtjLaLwaDgL4WzHOVec2 k+rbfmPT6MUCtdlz1PK5/WY9JQyQq6vy+tm3a6Wijy6M8U/TdrJubK5X03SFfRb0 pDuFdr2fnkctLRnyCb1w0XHwGXjEcGm1LY42YKwdvbj3WIqumeSEuG4MZtquW6NU RKELSil03G/hRHRAHHGx3zXes/jJcpH2GPX9eY9B+R1oHmCE2QF5Y/Bh+uNA2+2I uj/6UJAOw/Z/8+qZcnLWWnK2Dwzc34C/AUD+Wb71oUcr60+pPg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEYjCCA0qgAwIBAgILBAAAAAABMYnGRMkwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMTEwODAyMTAwMDAwWhcNMjIwODAy MTAwMDAwWjBmMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTE8MDoGA1UEAxMzR2xvYmFsU2lnbiBPcmdhbml6YXRpb24gVmFsaWRhdGlvbiBD QSAtIFNIQTI1NiAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xw5sPyOTf8xwpZ0gww5TP37ATsKYScpH1SPvAzSFdMijAi5GXAt9yYidT4vw+Jxs jFU127/ys+r741bnSkbZEyLKNtWbwajjlkOT8gy85vnm6JnIY0h4f1c2aRoZHVrR 1H3CnNR/4YASrnrqiOpX2MoKCjoSSaJiGXoNJPc367RzknsFI5sStc7rKd+kFAK5 AaXUppxDZIje+H7+4/Ue5f7co6jkZjHZTCXpGLmJWQmu6Z0cbTcPSh41ICjir9Qh iwHERa1uK2OrkmthCk0g7XO6fM7+FrXbn4Dw1ots2Qh5Sk94ZdqSvL41+bPE+SeA Tv+WUuYCIOEHc+ldK72y8QIDAQABo4IBKTCCASUwDgYDVR0PAQH/BAQDAgEGMBIG A1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJbeYfG9HBYpUxzAzH07gwBA5hp8 MEcGA1UdIARAMD4wPAYEVR0gADA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8ELzAtMCugKaAnhiVodHRw Oi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMD4GCCsGAQUFBwEBBDIw MDAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsF AAOCAQEAugYpwLQZjCERwJQRnrs91NVDQPafuyULI2i1Gvf6VGTMKxP5IfBEreHo FVjb7v3bok3MGI8Nmm3DawGhMfCNvABAzDlfh2FRbfSV6uoVNT5AhcBi1aE0/niq qLJaOfM3Qfuc6D5xSlvr+GlYoeDGk3fpumeS62VYkHBzQn2v9CMmeReq+qS7meVE b2WB58rrVcj0ticRIXSUvGu3dGIpxM2uR/LmQlt4hgVhy5CqeYnfBH6xJnBLjUAf hHvA+wfmyLdOkfQ1A+3o60EQF0m0YsinLPLhTI8DLPMWN11n8aQ5eUmjwF3MVfkh gA/7zuIpalhQ6abX6xwyNrVip8H65g==
-----END CERTIFICATE-----

Emil, can you try this again with a recent nightly? I'm hoping bug 1514118 will have addressed this.

Flags: needinfo?(emil.ghitta)

Hi Dana,

I have retested this issue using Firefox 67.0a1 (BuildId:20190205215922) and here are my findings:

  1. Launched Firefox with a clean profile (security.enterprise_roots.enabled pref is set to default "false").
  2. Accessed the https://www.twitter.com webpage -> The "connection is not secured" message is displayed.

It seems that, now, I don't have to toggle the pref in order to trigger the "connection is not secured" message.

Is this behavior expected?

Flags: needinfo?(emil.ghitta) → needinfo?(dkeeler)

Hmmm - seems like bitdefender is having the same problem avast was? That is, if I'm understanding you correctly, if you have bitdefender installed and configured to intercept https traffic, it isn't able to add its root to a new Firefox profile?

Flags: needinfo?(dkeeler)

Yes, that is correct, this is reproducible while having the "Encrypted web scan" functionality enabled. The behavior, is different from comment 0 since the "connection is not secured" message doesn't need the pref toggle in order to be triggered now.

Ok - thanks. I guess since the original behavior has changed, I'll close this as "worksforme" unless/until we come across another AV product that we can use to see if bug 1514118 fixed it.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME

Or actually, Martin - can you reproduce the original behavior with a recent version of Nightly?

Flags: needinfo?(peci1)

Updated nightly today, and it's still the same. With enterprise_roots disabled, I still get SEC_ERROR_UNKNOWN_ISSUER for en.wikipedia.org (using together with Avast).

But following bug 1514118, I tried deleting cert9.db in the Nightly profile and that helped - I can't reproduce the behavior anymore. I'll attach the copies of the old (faulty) and new (working) certdb in case it helps.

Flags: needinfo?(peci1)
Attached file cert9.db.old.db

Certdb which has problems verifying certificates.

Attached file cert9.db.new.db

A working certdb.

Thanks. From what I can tell, the only differences between those DBs are some cached intermediates from the public PKI that wouldn't be causing this issue. I think I'd really need to look at the before/after key4.db if you're comfortable sending those to me (they'll contain any private keys you've imported as well as the key that protects your saved logins, if you use that feature).

Flags: needinfo?(peci1)

I played around, deleted key4.db completely from nightly profile, did a few tests, and the file is still the same. It only contains one row for the password, and no rows in nss_private table. The thing that actually makes difference is really the cert9.db file. If you delete key4.db and use cert9.db.old.db, the certificate problem is there for me.

Flags: needinfo?(peci1)

Looking more closely at those DBs, none of the trust bits for any of those certificates are set, so this would never have worked without some extra magic, presumably from avast, which is now broken (bug 1523701). I'll keep this WFM for now unless/until we can find an av product with TLS interception that actually works with Firefox.

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

Attachment

General

Created:
Updated:
Size: