Closed
Bug 141612
Opened 23 years ago
Closed 22 years ago
Misconfigured SSL web sites cause "unknown authority" messages
Categories
(Core Graveyard :: Security: UI, enhancement, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.3
People
(Reporter: susiew, Assigned: KaiE)
References
()
Details
(Keywords: topembed+, Whiteboard: [topsite] [bugscape 14663] [adt2] [ETA 09/23])
Attachments
(4 files)
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
javi
:
review+
dveditz
:
superreview+
jesup
:
approval+
|
Details | Diff | Splinter Review |
(deleted),
image/png
|
Details | |
(deleted),
image/jpeg
|
Details |
PROBLEM: Web sites that use SSL server certs issued by the Verisign trust network (onsite.verisign.com) but do not send the intermediate certificate together with the server cert. result in excessive "website certified by an unknown authority" messages. This is a *major* customer service issue not to mention making the affected sites look insecure. Because many verisign customers fail to configure their servers correctly, with the result that the intermediate is not sent, it is not realistic to evangelize all of the sites affected. REQUESTED CHANGE: To reduce incoming customer service calls, we are advocating that Mozilla's functionality be on par with IE's functionality: intermediates should be saved permanently when they're first seen. More sites linked to http://bugscape.mcom.com/show_bug.cgi?id=14168
Reporter | ||
Comment 1•23 years ago
|
||
I changed this to RFE with topembed.
Severity: major → enhancement
Keywords: topembed
Comment 2•23 years ago
|
||
->PSM. This appears to be pretty high-profile.
Assignee: mstoltz → ssaux
Component: Security: CAPS → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.3
Reporter | ||
Comment 3•23 years ago
|
||
Correct Bugscape ID for list of sites is: http://bugscape.mcom.com/show_bug.cgi?id=14663
Whiteboard: [topsite] [bugscape 14663]
Reporter | ||
Comment 4•23 years ago
|
||
On http://www.ebates.com (top 500) I click "save certificate permanently" click continue, and the dialogue comes up...it happened about 4 x before the dialogue finally went away. (I will evangelize them but this is just one more example.)
Updated•23 years ago
|
Comment 5•23 years ago
|
||
-> Kai. Change the Summary. We will never save server certs permanently unless the user requests it. What this bug wants is to save intermediate certs permanently (with no trust). Kai, this is a top embed bug. The only real solution to this is to save intermediate CA certs permanently to the security database. Currently, we only save the intermediate CAs to a temp db that disappear on shutdown. This is in agreement with the spirit of the PKI standard. IE saves the intermediate permanently, and because is does, we suffer from this problem. The real culprits of course are the sys admin of the misconfigured web site which do not include the intermediate on their server. The get away with it because of IE market share, and because many servers using the Ver. Trust Net. do configure their servers correctly and I.E is "immunized" against the problem the first time it encounters a correctly configured server.
Assignee: ssaux → kaie
Priority: -- → P2
Summary: Server certificates should be saved permanently - minimize "unknown authority" messages → Intermediate certificates should be saved permanently - minimize "unknown authority" messages
Target Milestone: --- → 2.3
Assignee | ||
Comment 6•23 years ago
|
||
I really wish webserver admins read the fine manual. On the Verisign web page where you apply for such a server cert, they clearly explain what you have to do to make it work correctly. On the other hand, somebody should evangelize Verisign, too, because they are not handling this perfectly either, IMHO. When they send back the certificate to their customers, they should include the intermediates. Admins would place that whole content in their config files and everybody would be happy. However, I agree it is too late already. Too many sites out there that already have a wrong config. I remember, when we last discussed about automatically storing certs, it was argued that user's cert database would grow too fast and we would see a slowdown. But I think what is suggested here is an acceptable approach. We would not save all certs, but only the unknown certs in the middle of chains, and never the endpoints. I assume the NSS team prefers that PSM does the automatic collection. I suggest we change the code in nsNSSCallbacks.cpp / AuthCertificateCallback, to store the intermediates in the perm db instead of calling RememberCert.
Status: NEW → ASSIGNED
Comment 7•23 years ago
|
||
agreed. This will solve our problem. All the reports for this I've EVER seen were due to the verisign trust network intermediate not being sent by the server. Saving it to the cert db permanently will bring us exactly to a par with IE.
Comment 9•23 years ago
|
||
I do not agree. Saving the intermediate certs 1) only masks the real problem, and 2) can lead to database bloat, 3) It doesn't work with readonly profiles, and in general is bad security hygene. IE is and interesting data point, but it is not exactly a shining example of how do do secure operations properly (I'm not adverse to looking at how IE does things and picking up better semantics that they support, but it must be done on a case by case basis). This is an evangelism issue, same as getting people to fix their broken HTML. Servers who have this problem are operating outside of the SSL spec. bob
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 10•23 years ago
|
||
This needs to be an open discussion. It was suggested due to a high number of customer reports. Perhaps there is another solution but it is not realistic to evangelize every site that has its certificates set up wrong. I'm reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 11•23 years ago
|
||
cc Bob Lord and Terry Hayes. Issue is: is it acceptable to store *intermediate* CA certs permanently in the database rather than the current method of storing them in the temp db for the duration of the session. Facts: There are only very few known such intermediates in widespread use, the most prominent of which is the Verisign Trust Network intermediate CA cert. As a data point, there are 14 intermediates in my MS Windows intermediate ca cert data store.
Comment 12•23 years ago
|
||
There are deployments with ton's of intermediate CA's. This would be an huge issue in DoD deployments. It will complicate multi-path and cross certification. Microsoft is already running into these problems (as I learned from the talk on the cross-certificate issues given by Microsoft at the RSA conference). Every security protocol has been carefully crafted to carry the intermediate certificates if necessary. The proposed solution *DOES NOT SOLVE THE PROBLEM*. Those sites are still inaccessible until you happen to browse to some website which is correctly configured. This solution does not solve the problem for clients running with readonly profiles. I see 2 possible solutions: 1) get the offending server sites to fix their installations. This is no different than getting sites to fix their broken HTML. These sites are broken to New IE clients which have been newly installed as well. 2) If 90% of the problems stem from a verisign intermediate root, it might be better to include that root cert with no trust flags in the built-in's module. This fixed the problem 100% for the 90% without growing our databases. The idea of silently updating our databases with intermediate CAs neither solves the solution, and introduces additional risk to current and future deployments. bob
Summary: Intermediate certificates should be saved permanently - minimize "unknown authority" messages → Misconfigured SSL web sites cause "unknown authority" messages
Comment 13•23 years ago
|
||
If it is true that there are very few intermediate CA certs in use by misconfigured servers, I'd rather have us add those intermediate CA certs to the list of built-in certs that are shipped with the product, rather than changing the product to automatically add them. They don't have to be trusted in the built-in list, they just have to be there.
Comment 14•23 years ago
|
||
This solution *DOES SOLVE THE PROBLEM*. Although it's true that if it were implemented, the client (just as IE) would be susceptible to running into the problem when accessing a misconfigured site without having *EVER VISITED A CORRECTLY CONFIGURED SITE*, the reality is that the fix makes the software self-healing, which is a great property to have. As for the proposal to add to the built-in, I disagree. This is a maintenance nightmare, it fails to address newly issued intermediates (or we always have to play catch up), it break the built-in model (No intermediates), and it is functionaly equivalent to adding them on the fly. For the DOD and cross certification, if adding them permanently would break the software, then why wouldn't we run into bad situation if a browser storing the intermediate in the temp db in a single session access several DOD sites with different intermediates? I'm very aware of the importance of cross-certification, but we're talking about have the *application* (i.e., not NSS) make this decision. At this point the application doesn't support cross-certification, because NSS doesn't, so I'm inclined to give less weight to this argument. Ultimately this is a decision that the application should make. I want the application to make the decision that it will save intermediates on the fly.
Comment 15•23 years ago
|
||
Changes to the Security database is more than just a single application decision. Future deployments traditionally roll old databases forward. Decisions made today will effect the deployments of tomorrow. The actual stated problem in this bug report is a support problem. The number of intermediate CA's that are causing this problem is, by definition, small. Any intermediate that is not deployed widely enough to provide a reasonable expectation that it will eventually wind up in your database will be broken on all browsers (including IE), and therefore not an issue. Intermediate CA's that are part of an enterprise are handled by the enterprise itself, so it the entity incurring the support cost. In effect these few intermediate's have become roots because of IE's (broken) semantics. If that has become the case, then we should admit this fact and treat those certs as such. BTW, I do not believe Microsoft intended their storing of intermediate certs to mask misconfigured servers. They stored intermediate certs for their own convinience, their storing . Even if we fix this problem, it is good security hygene to notify those people who have misconfigured servers with a standard paper on why it's important to configure their servers correctly and how they can do it. Finally IE is the only browser which does this. If it wasn't the current market leader, we wouldn't even be talking about this.
Reporter | ||
Comment 16•23 years ago
|
||
Another bank reported with this error: http://www.firstunion.com/
Assignee | ||
Comment 17•23 years ago
|
||
Looks like both points of view have very good arguments. 1.) === Do we know what Verisign thinks about this issue? Could we evangelize Verisign to do what I suggest in comment #6, to at least avoid that the list of servers with wrong certs gets larger? 2.) Could we extend the message that is currently shown to the user? Right now, we only display a very simple message, saying "there is a problem". What about the idea of displaying a much more informational message? We could say that the web server might be misconfigured. We could offer the user to have Mozilla automatically send an email message to webmaster@domain. That email message, having a prepared text, would be sent from the email account of the user. The text could contain a link to a website where we display detailed information, that would help the website administrator to understand and fix the problem. I bet, if website admins receive email from many hundred different users in a short time, they will fix their site rather soon...
Reporter | ||
Comment 18•23 years ago
|
||
Further support for comment #14: This site has the certificate authority not recognized problem. https://OWA.NAVSEA.NAVY.MIL The issuer is the US government, not Verisign. ____________________________ Re comment #17: -I agree it makes sense to see if Verisign is receptive to comment #6. I assume "evangelize" here means someone in engineering/security will work w/them. -Re. extending the pop up message - I think adding "See Help for details" would be sufficient. The Help section for "Web Site Certified by an Unknown Authority" needs to be modified with more detail on this topic (for example it says "if you're sure that the certificate is valid" without suggesting when the user can be reasonably sure a cert is legit. -->I will open a separate bug about this. -I don't like the idea of mailing to webmasters, although it's a nice "out of the box" idea. It won't be a elegant user experience if sites don't have that set up as a valid alias and they get bouncebacks.
Comment 20•23 years ago
|
||
Could we create a pref to keep intermediate certs, on by default, and allow the user to turn this off if they see fit? As we've seen throughout the drive to improve compatibility, fixes in the client code are infinitely more effective than trying to evangelize.
Assignee | ||
Comment 21•23 years ago
|
||
Should we get the ball rolling, and start by at least showing a more informative error message to the user? ====================================== Warning: Unable to verify the identity of [www.xxx.com]. The operator of machine [www.xxx.com] did not obtain an identity from a certificate authority trusted by your current [Mozilla] settings Alternatively, machine [www.xxx.com] might have a bad software configuration, and is sending an incomplete identity. In the worst case, site [www.xxx.com] might also have been hacked and no longer be under control of its owner. You should not trust information shown by the remote computer, unless you have other ways to verify the presented identity is correct. [view identity certificate] [ ] trust certificate permanently Would you like to continue anyway? [continue] [cancel] [help] ====================================== In the above suggestion, I'm changing the current wording "remember cert permanently" to "trust cert permanently".
Reporter | ||
Comment 22•23 years ago
|
||
Thanks for reviving this. First I thought I'd capture here info from Verisign on this topic: This message results when secure servers with step-up certificates, such as VeriSign's Secure Site Pro, fail to send an intermediate CA certificate along with the signed certificate. For servers to properly initiate 128-bit sessions with browsers, you must install both the intermediate CA certificate and signed certificate on your server. Installing VeriSign's intermediate CA certificate only takes a few minutes. Follow the links below to the instructions for a couple of servers commonly affected by this issue: * iPlanet 4.X: http://www.verisign.com/support/tlc/class3_install_docs/netscape/iplanet_global.htm * Netscape Enterprise 3.X: http://www.verisign.com/support/tlc/class3_install_docs/netscape/v00g.html
Comment 23•23 years ago
|
||
Kai, Regarding your proposed text in comment 21, I think a more likely scenario than the third one (e.g. machine www.xxx.com was hacked) is that you are actually connected to another machine, not [www.xxx.com], and it is trying to masquerade as [www.xxx.com] in order to obtain your confidential information.
Assignee | ||
Comment 24•23 years ago
|
||
Nelson, you are right, your wording is better. Susie made enhancement suggestions outside of Bugzilla, in order to save some cycles here. We agreed on a wording that makes sense to us, and incorporates Nelson's udpated sentence. However, Susie suggests to change "in order" to "possibly". I think we can continue to show the help button. I believe our UI is specific to Mozilla, and embedders are using their own error dialog. Here is an updated suggestion for a more informative error dialog. Nelson, Sean, could you please have another look? =============================================== Warning: Unable to verify the identity of [www.xxx.com] as a trusted site. Possible reasons for this error: - Your browser does not recognize the Certificate Authority that issued the site's certificate. - The site's certificate is incomplete due to a server misconfiguration. - You are actually connected to another site, not [www.xxx.com], that is trying to masquerade as [www.xxx.com] possibly to obtain your confidential information. Please notify the site's webmaster about this problem. [view identity certificate] [ ] trust certificate permanently (Check this box to avoid seeing this message in the future, if you trust this web site.) Click continue to enter this site's secure area. Click Cancel if you have any security concerns. [continue] [cancel] [help] ===============================================
Assignee | ||
Comment 27•22 years ago
|
||
Assignee | ||
Comment 28•22 years ago
|
||
Please have a look at the new screenshot. I created it by combining the results of our discussion and the sample AOL screenshot. Do you agree this enhanced dialog is an improvement over the message we are currently showing?
Comment 33•22 years ago
|
||
Comment on attachment 96451 [details] [diff] [review] Patch v1 r=javi
Attachment #96451 -
Flags: review+
Assignee | ||
Comment 34•22 years ago
|
||
FYI: Timeless filed a related bug / enhancement request as bug 165006. If you are interested in this bug, you might be interested in the other one, too. More comments welcome.
Status: REOPENED → ASSIGNED
Comment 35•22 years ago
|
||
Comment on attachment 96451 [details] [diff] [review] Patch v1 sr=dveditz >+newserver.reason3=- You are actually connected to another site, not %S, that is trying to masquerade as %S possibly to obtain your confidential information. Would - You are connected to a site masquerading as %S, possibly to obtain your confidential information. be any better? It doesn't repeat the site name twice, anyway.
Attachment #96451 -
Flags: superreview+
Reporter | ||
Comment 36•22 years ago
|
||
I like that general idea. How about if we translate masquerade into a phrase that even kids would know: - You are connected to a site pretending to be %S, possibly to obtain your confidential information.
Assignee | ||
Comment 37•22 years ago
|
||
Sounds fine to me, too. Unless somebody objects, I'll check in the latest wording.
Reporter | ||
Comment 38•22 years ago
|
||
I wanted to show how much more helpful the revised version is :-)
Reporter | ||
Comment 39•22 years ago
|
||
Filed bug for Help modifications regarding the updated dialogue + a link to download intermediate CAs (http://www.verisign.com/support/install/index.html) Please cc yourself on that bug if you're interested (and able). http://bugscape.mcom.com/show_bug.cgi?id=19935
Assignee | ||
Comment 40•22 years ago
|
||
Enhanced error UI checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Comment 42•22 years ago
|
||
Nominating for the 1.0 branch, as this is low risk (i.e. text changes), and enhances Gecko's security story.
Whiteboard: [topsite] [bugscape 14663] → [topsite] [bugscape 14663] [adt2] [ETA 09/23]
Comment 44•22 years ago
|
||
Seeing that this is a text change and a patch exists, I have not objection to including this in the Blackbird release.
Assignee | ||
Comment 46•22 years ago
|
||
The patch in this bug works on the 1.0 branch. We're ok with landing it, if you approve landing.
Comment 48•22 years ago
|
||
adt approval to land on the 1.0 branch. Please get a= from drivers@mozilla.org before landing and then add the fixed1.0.2 keyword.
Comment 50•22 years ago
|
||
Comment on attachment 96451 [details] [diff] [review] Patch v1 a=rjesup@wgate.com for 1.0 branch; please change mozilla1.0.2+ to fixed1.0.2 when checked in
Attachment #96451 -
Flags: approval+
Updated•22 years ago
|
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•