1452070 - Investigate using Windows APIs to make TLS connections and verify certificates

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Romain Testard [:RT]]

We know that a significant share of our Windows users also use anti-virus softwares on their machines. From the module ping analysis of 64 bit Windows release users::
- 14.2% have Avast dll loaded in Firefox process
- 3.8% have Kaspersky dll loaded in Firefox process
- 2.8% have ESET dll loaded in Firefox process
- 2.2% have Symantec dll loaded in Firefox process
....

We have seen several situations where Firefox users were unable to connect to websites because of poor AV software Firefox support, although it's hard for users to attribute the issue to the AV software since Chrome or Bing would work:
- Bug 1449115: (unresolved yet) Likely a Kaspersky issue where “Your connection is not secure" error message is displayed while accessing webpages. This is likely related to installing Kaspersky certificate in Firefox storage
- Bug 1403404: (unresolved yet) issue where 2 users had issues installing Firefox with the stub on Win10 and reported seeing “Your connection is not secure" error message, they were running "Trend Micro" and "Avast" antivirus
- Asa mentioned another instance where we updated the storage format and revved the name of the storage file and it may have taken the AV vendors some time to adjust (that was a few releases back and I'm still seeing reports)

In general it seems antivirus often attempt to do HTTPS inspection and our unusual set-up (when compared to Chrome and Bing) means users get “Your connection is not secure" error messages when the antivirus is improperly written. Pro-actively testing AV softwares is hard because of the wide spread of softwares, versions and confgurations and relying on AV softwares to test with Firefox has proven not to work.

What is making this situation worse is:
- telemetry is submitted over HTTPS to a Mozilla server, making it unlikely we would see these errors in our telemetry.
- users experiencing this issue cannot troubleshoot it given lack of access to SUMO (https://support.mozilla.org/en-US/kb/troubleshoot-SEC_ERROR_UNKNOWN_ISSUER)

Given the scale at which AV softwares are used by our users, this makes AV softwares a potential top driver for churn and I'd like to understand if using Windows APIs to make TLS connections and verify certificates would fix these issues and is at all possible in Firefox.

Comment 1

[Asa Dotzler [:asa]]

I spoke with dvedits about this some months ago and it sounds like we should be able to flip the pref security.enterprise_roots.enabled which if I understand it doesn't switch us to the Windows cert store but does pick up user added certs from the Windows cert store.

Comment 2

[Dana Keeler (she/her) [:keeler]]

There's a few reasons we use NSS and our own certificate verifier and trust anchors rather than delegating to the operating system. In no particular order:

* Having a diversity of TLS implementations helps the ecosystem. If Firefox didn't use NSS the ecosystem would essentially consist of SChannel and OpenSSL.
* Mozilla's Root CA program is only relevant as long as there are enough users using it. If Firefox used Microsoft's trust store, our CA program would be irrelevant. The existence of and the work we've put into Mozilla's CA program continues to have a considerable impact on improving the web PKI (which protects all users of the web), and we should not give it up lightly.

In short, I don't think this is something we want to do. In lieu of this, as Asa mentioned, we have security.enterprise_roots.enabled which should make it so Firefox "just works" with 3rd party AV intercepting proxies. We have more to do there, but at least it's available as an option. We're also working on improved messaging and doing a better job of detecting why a user's connection isn't working (see e.g. 1450967).

Comment 3

[Romain Testard [:RT]]

(In reply to David Keeler [:keeler] (use needinfo) from comment #2)
> There's a few reasons we use NSS and our own certificate verifier and trust
> anchors rather than delegating to the operating system. In no particular
> order:
> 
> * Having a diversity of TLS implementations helps the ecosystem. If Firefox
> didn't use NSS the ecosystem would essentially consist of SChannel and
> OpenSSL.
> * Mozilla's Root CA program is only relevant as long as there are enough
> users using it. If Firefox used Microsoft's trust store, our CA program
> would be irrelevant. The existence of and the work we've put into Mozilla's
> CA program continues to have a considerable impact on improving the web PKI
> (which protects all users of the web), and we should not give it up lightly.
> 
> In short, I don't think this is something we want to do. In lieu of this, as
> Asa mentioned, we have security.enterprise_roots.enabled which should make
> it so Firefox "just works" with 3rd party AV intercepting proxies. We have
> more to do there, but at least it's available as an option. 

Agreed, this would solve our problem.
Bug 1314010 is about setting security.enterprise_roots.enabled to true by default and so far it seems doing that has been blocked because we don't want new certs being trusted without user approval. I'll comment on this bug to bring the above examples to support the theory that we should default enable it if no user friendly UX for opt-in is possible.


> working on improved messaging and doing a better job of detecting why a
> user's connection isn't working (see e.g. 1450967).