1241065 - Spell out the unknown issuer on sec_error_unknown_issuer error pages

Status: RESOLVED DUPLICATE of bug 1450784

(Firefox :: Security, defect, P4)

Description

[[:philipp]]

i would ask that on the "Your Connection is not Secure" error pages for sec_error_unknown_issuer errors, once users click on the "advanced" button, the error message there spells out the particular unknown certificate issuer like:
"The certificate is not trusted because the issuer certificate *BullGuard SSL Proxy CA Organisation* is unknown."

background to this request:
user questions about sec_error_unknown_issuer certificate errors make up a good part of incoming questions on sumo constantly. those are generally caused by man-in-the-middling software, including many popular av vendors (like kaspersky, bitdefender, avast, bullguard, eset), windows features like ms family safety filters, and sometimes malware and will make the browser almost unusable for affected users...
they might run into this once they refresh firefox for example, as the injected certificate is no longer in the trust store for example.

those errors are especially hard to troubleshoot since you have to find out the kind of interference there is, before you can give targeted advice and this is only possible through attempting to add an exception rule at the moment (or even impossible on sites with hsts headers, key-pinning).

this is a sample of the pains we have to go through at the moment: https://support.mozilla.org/questions/1045536

Comment 1

[[:philipp]]

some more numbers from a sumo perspective on this:

the https://support.mozilla.org/en-US/kb/connection-untrusted-error-message article dealing with this subject until now is receiving ~50k visitors a month & its helpfulness (users voting if it solved their issue or not) is constantly trending downwards from ~40% at the beginning of 2013 to 14% last month (whereas the average helpfulness in our knowledge base is around 70% if i'm not mistaken).

so adding these numbers up and considering that only a fraction of affected users will end up at this support article, we may end up with many hundreds of thousands of users we are losing due to this issue as their firefox is pretty much rendered unusable (major sites like google, facebook, mailing or https sites in general stop working), but we are not providing an adequate description to understand and act upon to users in the error message - whereas switching to another browser does easily solve this problem for them :-(

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

This would require changes to the certErrorTrust_UnknownIssuer error string in pipnss.properties (adding a %S to be replaced by the CA name) and a corresponding change to TransportSecurityInfo.cpp:AppendErrorTextUntrusted to get the CA name and add it to the string.

Comment 3

[Justin Dolske [:Dolske]]

The flip side of this is that the more details of an untrusted certs are exposed, the more risk there is that an actual malicious MITM will trick a user, since they control that string. Consider:

"The certificate is not trusted because the issuer certificate *site.com* is unknown." (User: "Gosh, that's the site I'm connecting to! Firefox sure is stupid!")

or even

"The certificate is not trusted because the issuer certificate *is OK but you need a Firefox update from malware.com, your current safety* is unknown."

But, yes, the current steps to get at this info seem a bit painful. I'd like to believe we could find some middle ground that lets support more easily get the info from users, but avoids misinforming users as above. *strawman* Stick a ROT13 version of the issuer name in the "Advanced" error page?

Alternatively, an _ideal_ solution for this problem would be to have a special error page / content that Firefox shows, which specifically tells the user their AV/Firewall is intercepting the connection, and links to a SUMO page telling them more about how to fix the problem.

Doing that would likely require constructing a list of common mitmware CAs / cert details, so that Firefox can distinguish them from other unexpected MITMs / CA problems.

[A malicious MITM could still pretend to be "legitimate" mitmware and trigger this page, but if the recommended user action is something like "disable or reinstall your AV/Firewall", that seems like it wouldn't be helpful to an attacker.]

Comment 4

[[:philipp]]

thanks, those are valid concerns of course!

if we really were to create a list of "known/presumably legitimate" MITM attempts however, i think we shouldn't stop just at providing targeted help pages, but also offer users a more seamless and programmatic way to "opt-into" & trust that particular kind of interception while fully informing them about the consequences and maybe constantly making them aware of the ongoing MITMing by some indicator in the address bar...

Comment 5

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

This would be more of a front-end feature.

Comment 7

[Ralf Hauser]

see Bug 1334048

Comment 8

[Albert Scheiner [:alberts]]

Seeing a lot of requests blocked lately in Nightly. Would be nice to have more info.

Comment 9

[[:philipp]]

bug 1450784 addresses the same issue in firefox 66.