Closed Bug 141612 Opened 22 years ago Closed 22 years ago

Misconfigured SSL web sites cause "unknown authority" messages

Categories

(Core Graveyard :: Security: UI, enhancement, P2)

1.0 Branch
x86
All
enhancement

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)

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
I changed this to RFE with topembed. 
Severity: major → enhancement
Keywords: topembed
->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
Correct Bugscape ID for list of sites is:
http://bugscape.mcom.com/show_bug.cgi?id=14663
Whiteboard: [topsite] [bugscape 14663]
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.)
Keywords: topembedtopembed+
-> 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
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
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.
Topembed folks. When do you need this?
is adding [adt2 RTM] sufficient?
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: 22 years ago
Resolution: --- → INVALID
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 → ---
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.

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
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.
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.
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.
Another bank reported with this error: http://www.firstunion.com/
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...
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. 
nominating for rtm.
Keywords: nsbeta1
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.  
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".
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
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.

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]
===============================================
Here's a screenshot of AOL's message, as food for thought.
Attached patch Patch v1Splinter Review
This patch implements a talkative dialog.
Attached image Patch v1 Screen Shot
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?
Looks good to me!
Javi, can you please review?
*** Bug 164946 has been marked as a duplicate of this bug. ***
Comment on attachment 96451 [details] [diff] [review]
Patch v1

r=javi
Attachment #96451 - Flags: review+
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 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+
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.

Sounds fine to me, too. Unless somebody objects, I'll check in the latest wording.
I wanted to show how much more helpful the revised version is :-)
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
Enhanced error UI checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
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]
Evelyn - what do you think?
Seeing that this is a text change and a patch exists, I have not objection to
including this in the Blackbird release.
[from adt] e-mail sent to Kai for more information
The patch in this bug works on the 1.0 branch.
We're ok with landing it, if you approve landing.
*** Bug 168637 has been marked as a duplicate of this bug. ***
Keywords: approval
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.
Keywords: adt1.0.2adt1.0.2+
*** Bug 171607 has been marked as a duplicate of this bug. ***
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+
Checked in to the 1.0 branch.
Verified on 10/4 branch.
*** Bug 174654 has been marked as a duplicate of this bug. ***
*** Bug 245609 has been marked as a duplicate of this bug. ***
Product: PSM → Core
*** Bug 297952 has been marked as a duplicate of this bug. ***
Version: psm2.3 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: