Closed Bug 886100 Opened 11 years ago Closed 2 years ago

Missing "i understand the risk" since version 20

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
22 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: White-Gandalf, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 (Beta/Release)
Build ID: 20130307023931

Steps to reproduce:

Upgrade firefox from version 19 to either version 20 or version 21.

Visit a website with a server certificate that is not already in the certificate database of the browser. For example "https://bugzilla.mozilla.org".


Actual results:

The certificate error dialog "This Connection is Untrusted" comes up, with the sub line "The certificate is not trusted because the issuer certificate is not trusted" (well: the last few word may have been others char wise, but the matter "not trusted" is critical here).

This special version of error is not noted in the knowledge database so far: https://support.mozilla.org/en-US/kb/connection-untrusted-error-message?esab=a&as=aaq

(There ARE entries for "because ... certificate is unknown", "because ... no issuer chain was provided" and "because ... is self-signed", but no entry for "because ... certificate is NOT TRUSTED", OK?)

The Dialog contains no "i understand the risk" - line to enable the user to add an exception. The user would have to manually obtain the certificate for the destination site an add that manually to the certificate database. That is not acceptable for normal users.


Expected results:

There should be a link line in the error dialog containing "i understand the risk" which enables the user to add an exception with relatively little effort.
Severity: normal → major
Version: 19 Branch → 20 Branch
Can't reproduce in 20/21 using EN-GB or EN-US build. Dropping to Normal for now since I can't reproduce on Windows or Linux builds.

Which locale build are you using?
Severity: major → normal
Flags: needinfo?(White-Gandalf)
That's well possible (that the case is difficult to reproduce).

Version info: http://harryboeck.dyndns.org/verschiedenes/firefox-21-version-info.png
Flags: needinfo?(White-Gandalf)
Send me a screenshot of a page with a bad SSL cert please. Such as https://mozilla-antarctica.org:8443
Flags: needinfo?(White-Gandalf)
buggy site: http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug.png

with a fresh firefox 21 without any addon: http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug-no-plugins.png

(sorry, roundtrip v19 -> v21 -> v19 takes some time...)
Flags: needinfo?(White-Gandalf)
Hold on? BMO has an SSL issue? I'm seeing a fully valid cert

Are you using a proxy of some sort?
Proxy... With no Addons at all... I don't think so.

Test of network settings in the v21 under way...
Following results:

* No Proxy in use:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug-no-proxies.png

* first idea from a discussion in the mozilla user forum (support.mozilla.org): No private browsing in place:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug-no-private-browsing.png

* even www.mozilla.org without a valid certificate:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bugs-even-mozilla-org-without-valid-certificate.png

* to add to mystery, many other sites still valid, for example google:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-google-ok-so-far.png

...or my own server:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bugs-vanishing-url-security-icon-on-mouseover.png

* but just another bug on that occasion: If the mouse goes over the security icon in the url line: as long as the browser is "seeing" a valid certificate, the security icon vanishes (see image above), while still functioning (i can display certificate infos)
But just another idea... Since you mentioned proxy...

Could it be that a firewall at some point stays in the way?
At least, that's not completely impossible...

* Application firewall on the workstation seems ok:
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug-no-firewall-blocking.png

* What does the router say? Nothing of interest, too (those two blockings today were not in timely coincidence with the firefox21 runs):
http://harryboeck.dyndns.org/verschiedenes/firefox-20-certificate-management-bug-no-router-firewall-blocking.png
An appendix to the "firefox-20-certificate-management-bug-no-firewall-blocking.png": Those blockings marked in the screen shot ARE from scattered (and daily wandering in the numerical IP space) Microsoft update servers which do not have domain names revealing themselves as being Microsoft Servers. I boykott that policy from Microsoft.

Has nothing to do with Firefox at all.
Yes. New profile creation in progress...
OK, a new user profile has no issues with certificates.

So, the problem comes from some coincidence between the user profile environment from older versions and the new version 20+ browser code.

Is there some way to copy over all relevant data from an old user profile to a new one? I guess: yes?

I will try out the following: http://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles
Well: As it looks, that's no option (to simply copy/paste the complete profile fileset). Are there other ways of selectively copying over?
The search term "migrate" instead of "copy" doesn't seem to help either... For example:

http://blog.arcsource.com/2012/02/firefox-profile/
-> not usable to the same degree
I could probably go with this one: http://support.mozilla.org/en-US/kb/Recovering important data from an old profile

(work in progress...)
OK: Copying according to the linked article except the certificate database leads to success so far.

The keeping of two different profiles during an upgrade process seems to be a useful option, too. Resulting in a drastically shortend switch time. The two installs no more shredder the addons settings.

Summing up so far: There seems to be an issue with the old v19 certificate database. While functioning correct under the v19 browser, browsers from v20 up have issues with it.

At the moment, i remain in a transition state, since there are two more issues with that upgrade.

=============

Are you interested in finding the deeper cause of this certificate database issue, and in case: is it possible for me to do anything to help you discover it?
OK, after a while and an upgrade to V22... a bit of upgrade to this case:

At least two of the certificates in the "authorities" slot in my old cert8.db have some contents, that makes firefoxes from version 20+ make the option "i understand the risk" (1.) invisible and (2.) out of function (both of the two matters at the same time).

Proof:

* Take my old cert8db (http://harryboeck.dyndns.org/verschiedenes/firefox-20-cert8-db-error.zip)
* goto "authorities"
* delete/distrust everything from GTE Corporation upwards
* delete/distrust every "software security device"-entry from "Helenic Academy" downwards
* restart firefox
* confirm everything is working correct

So long, it looks like the new firefoxes have got some changes in the field of certificate management.

And the fact that some dialog field behavior gets influenced by some wrong certificate handling strongly encourages the assumption that both the certificate handling as well as the dialog field handling are broken.

Neither the first nor the second should happen, not even IF really some of the certificates would have been erroneous.

In the latter case, the GUI should inform the user of the erroneous state of the certificate in question, that it will be dropped from the database and then get a new instance of the certificate from the website and let the user accept that one! At least let him accept the certificate from the destination server he wants to visit!
Well: If you like, you could of course first confirm to yourselves the disfunctionality of firefox 20+ with the old cert8db before you go to restore functionality by deleting the described bunch of certificate entries...
Update: The "culprit" is the certificate

==================
GeoTrust Global CA
==================

Thus, the procedure for verification of the matter described above simplifies to deletion of only this one certificate entry in the authorities tab.

I will try to extract the difference between its "original" historical state from very old versions of firefox (maybe it resulted from the very first day i installed the first version of firefox on my computer, over 10 years ago) and the new build-in version that is replaced after deletion of the old entry...
Update: The "culprit" is not even the contents of that certificate. The contents of the two versions of the certificate presented by firefox before and after the deletion of the entry of GeoTrust Global CA is __binary identical__.

Nevertheless, BEFORE deletion of that specific entry in the cert8db, carried over from the previous versions, the erroneous behavior as discussed in full detail so long is evident.

As Well as AFTER deletion of that specific entry in the cert8db, CORRECT behavior is as well evident.

I have verified this correlation this evening about 50 times while approximating that entry as well as after that again about 10 times while playing around producing these reports.

============

Conclusion in-between:

* There MUST be some state of the historic cert8db - File (see link some entries above) that is completely well handled by firefoxes BEFORE version 20, but breaks them from Version 20 upwards.

* The way this breakage propagates through up to the user interface is an erroneous state for it selves.

Both matters should be investigated.

================

Importance is nevertheless somewhat low, because nearly 100% of the user do not pay a second of their entire live to the matter of certificates at all. Only after they got owned by the lack of their irresponsible behavior concerning security. If at all their intelligence reaches that level to even get the interrelation.

Well: It would be nice to have that preventively fixed for the future, but it doesn't break the spinning of the world for now.
Update: The one mentioned certificate

==================
GeoTrust Global CA
==================

is not at all the only one not recognized by the browser 20+, as is depicted in the hours after my last report. Just as i tried to switch to FF22 for normal day's usage, already google came up with the next nonfunctional certificate (i really had not much time to wait).

Since in the running browser (Firefox 22 in this case) the non-functional certificate handling enforces impossibility to even get the name of the nonfunctional certificate or it's parents (the dialog misses the "i understand the risk" - option, which WOULD HAVE - in case it existed - lead to the possibility to view infos about the certificate), the browser remains in a state of nonfunctionality as long as the certificate database shall be carried over from a version prior to 20.

And since it seems - at the moment - that a greater bunch of certificates (not exactly the complete certificate database, but a sufficient large part of it) is affected, i would for now again reconsider the importance of this bug to be somewhat bigger.

For me: I will keep sticking to version 19 until this is resolved or some practicable usefull export/import procedure (not that existing one, which is only able to handle one certificate at a time) is in place.

===========

Since it seems that this bug does not get any more attention, because it is "rated" as a trunk 20 bug (while in reality it is affecting EVERY version from 20 up), i change the trunk entry to the current release (22) in hope of catching the eyes of someone.
Version: 20 Branch → 22 Branch
Severity: normal → major
Just another idea...

https://bugzilla.mozilla.org/show_bug.cgi?id=800882

That one looks like showing much the same behavior in terms:

1. missing "i understand the risk"
2. coming in effect directly connected with an update

...while being different in terms of the browser version. I didn't had such trouble with version 17. Only starting with version 20.

=============

If you ask me, i would bet that something in the certificate handling of firefox is complete going wrong. As...

1. How dare you think that HSTS could possible have been designated to strip users from the ability to enforce certificate checks? Or to hinder them to enable manually controlled exceptions in case they do not trust a specific CA? It completely evades me, sorry.

2. Something in the certificate database and its handling goes nuts independently from point 1, if this behavior REALLY has something to do with those HSTS-enforcements. Because those "hidden Attributes" as mentioned in Bug 800882 obviously become operative only and solely after some upgrades of the browser. That's for sure not the wanted politic. You don't WANT to **** off the hole HSTS matter until some and any version upgrade of the browser takes place.

To Point 2: As long as i remained below version 20 (in my case) or the bug reporter of 800882 remained below his version 17, not a single site in the whole internet throughout years would have triggered that behavior.

But surprisingly at some version change - and that's REVERSABLE (!) by downgrade, only to stress that fact to get it into consideration - the matter becomes a blocking barrier.

Will such surprises have to be expected in the future?
Will nothing be done to correct that behavior?
Component: Untriaged → Security
See Also: → 800882
Just an Update to the version range:

Just now (today, 2013-08-24), even in the version 19 (which i still use up to day), the same behavior starts popping up. (Well: the exact time will have no meaning, since i do not visit the addons page on a daily basis but only on occasion.)

With mozillas own sites, of course. This time the addons-page:

http://harryboeck.dyndns.org/verschiedenes/firefox-certificate-management-bugs-now-even-with-version-19.png

At the very same moment (today, a few moments ago) my email inbox shows some added cc-entries for this bug report. Since those two actions are so closely timely correlated, it is very likely that both have a common deeper cause. It seems that others are experiencing those certificate management bugs, too. With growing numbers by time.

==============

So lets take a look in the direction of the cause...

At first glance, the certificate of "https://addons.mozilla.org" changed today or in the near past.

To get any information about the former certificate at all, as a normal user, you would have to use the certificate store dialogs from tools/options/advanced/encryption. Since from the page view in question, you don't get any information about the bebleated certificate.

But in the certificate store dialogs, you don't have any option to get to a specific certificate at all by other means than linearly and manually scanning through the complete list of all saved and default certificates. Thus, we have the next crucial bug in the certificate management: In case, there IS any erroneous behavior, you are doomed to crouch on your teeth if you are a normal user.

Well: At least the addon "certificate patrol" is capable of doing that job (sort certificate entries to speed up the finding of specific ones). You should seriously consider adding a search/sort capability to those default dialogs!

Ahhh well - and most probably there it is, the culprit: addons.mozilla.org had already have registered multiple certificates, one of them running out of service just three days ago:

VeriSignClass3PublicPrimaryCertificationAuthority-G5
-> VeriSignClass3ExtendedValidationSSLCA
--> addons.mozilla.org
valid not after 21.08.2013 01:59:59

...and...

GeoTrustGlobalCA
-> GeoTrustSSLCA
--> *.addons.mozilla.
already long time gone: valid not after 29.12.2012 14:31:14

(hmpfff: the suffix here didnt get copy/pasted and i deleted this old entry right at sight before realizing that debugging could become interesting...)

...and...

AkamaiTechnologiesInc (no more in my certdb)
-> ???
--> *.addons.mozilla.net
already long time gone: valid not after 19.10.2012 17:21:54

------------------

OK: What can i do from the viewpoint of a user?
How can the certificate management be forced to come back to function?

The experiments some times ago suggested something wrong with the handling of the PARENT (!) certificates (look at the message entry with "GeoTrust Global CA" in it!). But at the moment, it looks like an outdated individual server certificate might be the culprit...

1. I will first make a backup of the certdb... done.
2. I will subsequently test the reaction and delete the three outdated server certificates (well: only two were remaining, since i already deleted one of them)...

Since my impression at earlier experiments was that changes to the certdb become effective only after a restart of the browser, i will have to submit this report and come back in a few moments...
OK, that took some time...

No test handling of any of the certificates mentioned above (including their parents) changed anything regarding the missing "add exception" (well: i didn't really expect something from "addons.mozilla.__net__" - but just to be sure, i included it).

What i missed in the first run was an additional certificate for "addons.mozilla.org" from "Usertrust Network" - outdated too. Again: This didn't change anything.

WHAT did change the situation was the COMPLETE (!) erasure of the whole authority database. After that, the next visit of "addons.mozilla.org" delivered a dialog informing me of a new certificate from the even next new authority. (You mozilla-server-admins try to have a run at all and every different authority available out there in the world, do you? It's just fun to switch over from one to the other every year or so, does it?)

So i will take a review to the case with the old certdb version restored and this time "DigiCertHighAssuranceEVRootCA" in focus...
Yes, confirmed: Restoration of the old (from around 12:00 local time today) certdb and subsequent deletion of just the "DigiCert" authority entries did fix the situation. ...For https://addons.mozilla.org.

But with the same session - out of nowhere - the connection to just here (https://bugzilla.mozilla.org) was boykotted the same way: no more trusted certificate, and missing "exception".

Very "nice" coincidence, indeed!

Since, from the previous experiments, i already had a picture of which CA's were the beloved ones of mozilla in the recent past, i deleted all Geotrust CA entries: Voila: Even bugzilla returns to work.

But, really, folks: Is THAT the default behaviour that normal users SHALL experience?! I simply can't believe it.

Since this matter now catches even earlier versions of firefox, it really becomes annoying, do you grasp that? Especially since this issue today ignited not somewhere far away in the net, but just precisely at two mozilla sites.

I would say: Rate the severity down to nothing! And hope that the problem becomes scared of just that and fades away by itself!
A couple of things:
* If a site has requested HSTS, the user agent (the browser) must refuse to connect to the site if there are certificate errors (see http://tools.ietf.org/html/rfc6797#section-8.4 ). This means exceptions can't be added to override the errors, which is the behavior you're seeing (unfortunately the UI is unclear on this matter - see bug 800882).
* It seems you've made many modifications to your certificate database. This makes it difficult to differentiate between what would be a bug in firefox and what would happen as a result of deleting/distrusting certificates or simply having old certificates in your database.
* My recommendation is to start with a completely fresh profile and attempt to reproduce the bug. If you observe the same behavior, please provide a list of steps to reproduce. If not, the problem is with the state of your database and I would recommend replacing it with a recent one that ships with firefox.
Your statement about reaction on errors in case of HSTS is wrong.

The definition of errors and warnings in rfc6797#section-8.4 is unmistakable, and that one is disjunctive from your arbitrary labeling of usertrust cases as errors.
Usertrust is a whole world away from what is the idea behind rfc6797#section-8.4.

My recommendation is to correct this academic behavior.

Its been a long time since the last update on this issue.
I haven't seen the missing line while testing the new UI for Certificate Error pages, now called Accept the Risk and Continue.

Is this something that you've seen lately? If so, could you please add a testcase? Thank you!

Flags: needinfo?(White-Gandalf)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:serg, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(White-Gandalf) → needinfo?(sgalich)
Flags: needinfo?(sgalich)
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.