Closed Bug 327181 (https-error-pages) Opened 18 years ago Closed 17 years ago

Improve error reporting for invalid-certificate errors (error page for https, or combined dialog)

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta1

People

(Reporter: hecker, Assigned: KaiE)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: uiwanted, Whiteboard: [sg:want] parity-ie)

Attachments

(9 files, 7 obsolete files)

Draft error message - basic
13.81 KB, image/png
Details
Detailed information on what failed
33.42 KB, image/png
beltzner
: ui-review-
Details
Napkin Drawing: Wizard to define cert exception
24.92 KB, image/png
Details
code that illustrates how to obtain ssl status from a broken connection
4.40 KB, patch
Details | Diff | Splinter Review
Changes outside of PSM based on Patch v5
52.31 KB, patch
mconnor
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
Screen Shot for Patch v5
32.72 KB, image/png
Details
Patch v7
220.34 KB, patch
rrelyea
: review+
Details | Diff | Splinter Review
Patch as checked in
221.39 KB, patch
Details | Diff | Splinter Review
fix IDL comment [checked in]
986 bytes, patch
rrelyea
: review+
beltzner
: approval1.9+
Details | Diff | Splinter Review 
I propose eliminating or at least minimizing SSL/TLS-related error messages and
warning dialogs in the Firefox UI, particularly in cases where such messages and warnings are arguably not warranted based on the security risk relative to not using SSL/TLS at all. I also suggest modifying the Firefox UI to discourage typical users from modifying the default list of "trusted" CAs and certificates by adding new site or CA certs as warning dialogs pop up.

The overall effect of this proposal would be to present an http-like UI (possibly with an additional information bar message) for sites presenting invalid certificates, instead of using the standard SSL UI (padlock, etc.).

This proposal is based on my n.p.m.crypto posting of March 11, 2005, titled "Strawman proposal for SSL UI changes". Note that (unlike the above-referenced post) this proposal is independent of any UI changes proposed for hypothetical future "extended validation" or "high assurance" certificates. It assumes the use of current "legacy" certificates, and no change to the underlying NSS mechanisms for validating certificates.

Here's the basic proposal:

* Retain the current Firefox UI when SSL/TLS is not used:

  - location bar background is white, with no padlock
  - no padlock or other SSL/TLS-related indicator in status bar
  - site domain name is *not* displayed in the status bar

* Retain the current "normal case" SSL/TLS Firefox UI:

  - location bar background is yellow, with padlock
  - display locked padlock in status bar
  - site domain name from certificate is displayed in status bar

Add the following new SSL/TLS UI cases, for which we do *not* use the traditional "padlock" indicator in any form:

* SSL/TLS connection involving a self-signed certificate or a certificate from an unknown CA:

  - location bar background is white, with no padlock
  - display informational message of some sort (as for blocked popups)
  - display exclamation point in status bar (as for blocked popups)
  - site domain name from cert is *not* displayed in the status bar

* SSL/TLS connection involving a certificate from a known CA where the domain name in the certificate does not match the domain name requested:

  - (optional) display warning dialog describing the potential security risk, and giving the user the option of proceeding or cancelling; if the user chooses to proceed, display the following:
  - location bar background is white, with no padlock
  - display informational message of some sort (as for blocked popups)
  - display "X" mark in status bar (instead of padlock)
  - site domain name from cert is displayed in the status bar

Some follow-on comments:

* "Known CAs" are CAs for which we have a stored certificate with the SSL "trust bit" set on. Any other case (cert not stored or trust bit not set) is treated as an unknown CA. (I try to avoid the term "trusted CA" because of ambiguity over what "trust" actually means.)

* The site domain name should be displayed in the status bar only when we have some reason to assume that it is valid. Hence it should *not* be displayed for self-signed certs and certs from unknown CAs, but *should* always be displayed for certs from known CAs.

* In the case of a self-signed cert or cert from an unknown CA, Firefox should *not* offer users the opportunity to accept the certificate or the certificate's issuing CA as "trusted", at least not from the immediately visible UI.

If an informational message is displayed in this case, then perhaps its dropdown menu could contain an option to not display the informational message in the future for self-signed certs or unknown CAs (similar to the option for blocked popups); in this case the UI indicators would remain the same, except possibly for a question mark replacing the "exclamation mark in circle" accompanying the original informational message.

(The other alternative would be to display no status indicator at all once the informational message had been dismissed; in effect this would treat sites with self-signed certs or certs from unknown CAs as similar in all respects to non-SSL sites.)

The informational message's dropdown menu could also contain a menu item "Edit Certificate Options..." or "Edit SSL Security Options..." (similar to the "Edit Popup Blocker Options..." item on the "blocked popup" informational message), and the resulting dialog box could contain options to accept the site's certificate or a new CA certificate. Future visits to the site would then display the pad lock as for other SSL/TLS connections.

* In the case of a cert from a known CA but with an non-matching domain name, if a warning dialog is to be display, then the warning dialog should be displayed at least once per browser session, without the possibility of turning it off permanently for that site. If an informational message is displayed in this case, then perhaps its dropdown menu can contain an option to not display the
informational message in the future for not matching domain names (similar to the option for self-signed certs or unknown CAs); in this case the UI indicators would remain the same, except for an "X" mark replacing the "exclamation mark in circle" accompanying the original informational message.

(I don't think it makes sense to not display a status bar indicator at all after dismissing the information message, and to treat this case the same as a non-SSL site. There really is something wrong with the site -- it's either misconfigured or is using a stolen key and cert -- and the UI should reflect that.)

* The only way to add new CAs or server certs or to change the default "trust bits" should be through the Firefox preferences UI or (perhaps) through a detailed certificate dialog reached by selecting an item from the dropdown menu associated with an informational message (if used). (This latter option would be similar to the "Edit Popup Blocker Options" menu item displayed for the blocked popups informational message.)
We should do this for FF2, imho.
Component: General → Security: PSM
Product: Firefox → Core
>The overall effect of this proposal would be to present an http-like UI
>(possibly with an additional information bar message) for sites presenting
>invalid certificates, instead of using the standard SSL UI (padlock, etc.).

I don't think more SSL modes are going to help in this situation as much as stopping bad SSL connections dead would. 

My counter proposal is: If any aspect of the SSL setup fails (server chains to unknown or untrusted issuer, expired cert, cert-name mismatch, etc.) do not show anything in the referenced page.  Instead, show an error page which says what the problem is to help the user understand. Also, show some technical information to help a site administrator understand what's going on.
I think we need mock-ups, .gif attachments that show the proposed idea.  
Otherwise, we each have our own image in our heads, and are agreeing or
disagreeing to different things.  

Frank, you seem to have proposed about 6 or 7 new scenarios/proposals.
Would you be willing to make mockups of them??  

Bob, I like your idea a lot.  Can you make an example substitute page?
Here is a proposed UI screen that users would see when they encounter an SSL web page that fails to complete without incident. Users can get more information by clicking on the "Show details" button.
When the user clicks on "Show details", s/he will see more information. This information should be useful enough to a web-site admin to be able to diagnose the problem.
Bob: looks OK, although we may need to simplify the language a little. One clarification: you have two "suggested remedies". Are those for the phishing case? That is to say, if I type in "http://www.citibank.com" directly, and there are still certificate problems, I'll still get this screen rather than see the site, right?

Gerv
Comment on attachment 212595 [details]
Detailed information on what failed

fwiw, i don't think we should show all the tests that passed. When I look at that list I get the feeling that "this site can't be all that bad, it has a valid key and all that other stuff"
IMO, given the number of sites with https warnings (especially in intranets?), there should be a "connect insecurely" button.  And maybe also a way for users to manage a whitelist of "It's ok if a certificate issued for hostname FOO is used for hostname BAR", since that's the most common issue I encounter.
Jonas writes:
>fwiw, i don't think we should show all the tests that passed. When I look at
>that list I get the feeling that "this site can't be all that bad, it has a
>valid key and all that other stuff"

I agree that most people won't need to see the entire list, and won't understand what it means.  I was hoping to make it simpler for the IS administrators and help desk techs understand what was going on.  They will need to react differently to an error generated by their use of a cert that does not chain to a trusted issuer vs. an OCSP problem.

I was also proposing that there'd be no way to "continue anyway", so even those people who think "6 out of 7 is still pretty secure" would not be able to shoot themselves in the foot.

Of course, there would probably be an about:config switch for the IS team to test using self-signed certs during prototyping phases.


(In reply to comment #8)
> IMO, given the number of sites with https warnings (especially in intranets?),
> there should be a "connect insecurely" button.  

Intranets are indeed some of the biggest offenders in that they often use self-signed roots.  In many cases, they use SSL on such a small number of machines that it's hard to understand why they don't just buy certificates.  This scheme might help nudge them towards buying certifcates that chain to a well-known CA.  If we needed to provide tools to make it simpler to deploy self-signed roots, we could arrage for that.

> And maybe also a way for users
> to manage a whitelist of "It's ok if a certificate issued for hostname FOO is
> used for hostname BAR", since that's the most common issue I encounter.

I'd like to hear more about these types of problems in the wild.  Do  you see these on intranets, or on the public internet? 

The error page display is a good idea for web browsers.

What UI do you propose for SSL applications that do not use a web page display?
E.g. using SSL/TLS to connect to mail servers in Thunderbird?
Or using LDAP+SSL for directory queries?

-> default assignee/QA for component
Assignee: nobody → kengert
QA Contact: general
-> nobody@mozilla.org because I currently do not plan to work on this short term
Assignee: kengert → nobody
Flags: blocking1.9?
Whiteboard: [sg:want]
Alias: http-error-pages
Attachment #212595 - Flags: ui-review?(beltzner)
This bug report contains two proposals that seem like polar opposites to me:

A) Eliminate most SSL error dialogs, and instead just omit the lock icon and other security indicators.

B) Eliminate most SSL error dialogs, and instead display an error page.

Even more confusing is that the summary refers to A while the alias refers to B.

I think A is a bad idea for three reasons.  First, it breaks the "I loaded Paypal from a bookmark, so I don't have to go through the horribly complicated process of confirming that I'm on the right site" trick.  Second, it means I have to re-check that I'm on the correct site every time I click a link, and maybe I can't even be sure that https-to-https form posts are safe.  Third, it threatens to confuse cookies, password manager, Greasemonkey, and even the JavaScript same-origin policy into equating the "real" https://www.paypal.com/ with anyone who wants can MITM it.

I am in favor of B.
Jesse: I think what might be being suggested is somewhere between the two. 

For example, one might do A) for self-signed certs. If people are using self-signed certs to achieve privacy against known sites, one could argue it's reasonable for people not to be bombarded by warnings. After all, if we are going to allow self-signed certs, we must agree they have a valid use case.

One might also do A, at least for a short time, for expired or for about-to-expire certificates. This shows something's wrong without blocking access entirely.

On the other hand, one might do B) for site name mismatches (or perhaps some site name mismatches, depending on what the effective TLD service says about the two domains in question). 

I think we need to make a list of possible error conditions and work out what to do in each.

Gerv

(In reply to comment #14)
> Even more confusing is that the summary refers to A while the alias refers to
> B.

The alias was set by Nelson, the summary by Frank. The alias reflects more recent thinking from the NSS team how they'd like to handle most problems, it would be great if Kai could link to his slides on the topic. The proposal was a lot more B than A.

Taking the liberty of changing the alias -- we already have "http" error pages, this bug is about "https".
Alias: http-error-pages → https-error-pages
To add to the comments above: I originally filed this bug in an attempt to spark some serious discussion about what to do regarding HTTPS-related error and warning dialogs, by making a "devils advocate"-style proposal implement some sort of alternate solution. If there's a consensus among the Firefox UI folks and the NSS team as to the right way to approach this then that's what we should do. My major concern was and is that the status quo is not sustainable.
Internet Explorer 7 uses error pages for mismatched hostnames.  I haven't tested what it does for other errors that Firefox currently uses dialogs for.
Whiteboard: [sg:want] → [sg:want] parity-ie
Uh, let me clarify it for me: do you imply that FireFox WILL NOT BE ABLE to display such pages AT ALL? 

I don't know about your environment, but in my country (or region, as it may cover  large parts of Europe) 80% of the sites use self-signed certs, or certs with different names. (They care about encrypted content, not identity protection. It is a philosophical debate why you disagree with this, or should _firefox_ try to force them to pay money for something they do not want to pay for.) 

If FF cannot display these sites users have to use a different browser. It would be a very bad change. (Actually, lots of people changed to FF and Opera just because of the mentioned behaviour of IE.)

I am completely against the idea of making FF unable to display an otherwise working page. Even if it needs a hidden switch somewhere it would be a bad idea, since this problem would bite Joe User as well, and he is completely unable to do anything about it, not to mention he does not understand the problem at all.

(It's good that this one was mentioned in Bug 363345 which was just about that: simplifying session restore to lots of such "real-world" sites.)
Blocks: 363345
QA Contact: psm
Comment on attachment 212595 [details]
Detailed information on what failed

Beltzner's self-request for ui-review is now 6 months old.
Johnathan, would you do a UI review?
Attachment #212595 - Flags: review?(johnath)
In conversations last week with the NSS team, this bug was mentioned as an important one for FF3, and I agree.  It's P1 in the Firefox PRD as SPI-001g (http://wiki.mozilla.org/Firefox3/Product_Requirements_Document).  

Also discussed in the call was Kai's matrix of SSL error conditions against desired behaviour.  As some commenters have noted above, there are cases where we need these errors to be non-terminal, allowing users to override a poor/broken SSL situation if they see fit to do so.  At the end of the day, we WILL trade security against usability in cases where it's inappropriate for us to prevent the user from accomplishing their task, but Kai's matrix will likely be helpful in determining which cases are which.  

It looks to me like we can do most of what we need, implementation wise, either by extending the netError.xhtml page to add support for things like a "More details" button, or by simply cloning that page into a custom-purpose sslError.xhtml that is more suited to our particular information display requirements.  It's not immediately clear to me where that page should live in the tree.

From a cursory look at the NSS side of things, it looks like nsNSSDialogs.cpp, or nsNSSDialogHelper.cpp,

http://mxr.mozilla.org/mozilla/source/security/manager/pki/src/nsNSSDialogs.cpp
http://mxr.mozilla.org/mozilla/source/security/manager/pki/src/nsNSSDialogHelper.cpp

and possibly others, would need to be modified so that instead of directly openDialog'ng, they make some determination about whether they are in a browser capable of displaying error pages (vs. a client like thunderbird) and then either display the existing dialogs or redirect to the error page, as appropriate.  I have no experience with the NSS side of things though, so I hope someone else can comment on what's required from that side of things.

If we can come to quick agreement on the candidate errors for this treatment, and (dare I say it) on the error page text, I think the code involved should be fairly straightforward, assuming I have understood the NSS situation correctly.
IMO, The issue is not: "Do we (or do we not) provide any way for users to 
choose to honor a certificate that cannot be traced to a trusted source?".
The issue is: "Do we allow them to do it in a reactionary way, at the 
moment the error is detected (in which case studies show they will ALWAYS
choose to override errors), or do we make them do it in some DELIBERATE 
way, that requires some non-trivial amount of effort (such as going into 
prefs and entering relevant information by hand)?"

Once we have solved the problem of users always overriding all errors, by
making it non-trivial to do so, then there is probably no need to differentiate
errors that we deem to be overridable from those that we deem are not.  IMO,
that is the real point of the UI proposed in comment 4 above.

The errors that present the greatest threat, and hence are in greatest need 
of not being trivially overriden, are the ones that mean that the cert offers 
the user no legitiate assurances WHATSOEVER that its contents are true.  
These errors are precisely those that will occur in an active attack.
If we do not protect against those, then our https really offers users no 
protection AT ALL against fraud (phishing or MITM attacks).

Those errors include:
- certs that have been revoked by the issuer
  (This is the most serious category of all.  These are certs that the 
   legitimate subject has reported to the issuer as compromised.  For these,
   we have positive knowledge that the cert must not be honored, rather than
   merely lacking the knowledge that it should be honored.)
- certs that cannot be proven to be issued by a known and trusted issuer
  (of which we current recognize two subcases:
    a) cert issued by an unknown issuer
    b) cert issued by a known but untrusted issuer)
- certs that were not issued to the server that we are trying to contact
  (includes non-SSL certs and certs with host name mismatches. An attacker
   can do MITM with a real cert from a trusted CA, IFF we let the user 
   ignore the fact that the cert is NOT for the intended server.) 

Expired certs are a gray area.  There are several issues with them.

Today, expiration is the FIRST thing we detect.  So, when we report that 
a cert has expired, we have NOT yet checked that it was issued by a known 
and trusted issuer, or that it was issued for the server we are trying to 
reach.  That is why, today, when the user chooses to override expiration, 
we go back and check it again for valid issuance and cert name matches.  
One of the changes implied in the https error page mock up previously 
attached to this bug is that all that checking will be done before any 
error is presented to the user, so that the user sees at most ONE error page/dialog.   

When we have done ALL the checks (not just expiration) and have found that 
the ONLY problem with the cert is the expiration date (but the issuer is 
trusted, and host name matches), then the good news is that we know that 
the cert WAS valid (at one time in the past).  The bad news is that we 
don't know if it was revoked before it expired.  CAs are permitted to 
remove all revocation information about a certificate (whether it was 
revoked or not) as soon as it expires.  The whole point of expiration is 
to mitigate the size of the CA's revoked certs list (CRL, which some users 
download), and the bound the amount of time that the CA must keep track of 
the cert's status.

So after a cert expires we CANNOT learn, retroactively, if it was revoked 
before it expired, or not.  A CRL simply will not tell us.  If we are using 
OCSP, and we ask the CA via OCSP if the cert was revoked, the OCSP responder 
will tell us that the OCSP request is invalid because the cert is expired, 
and since that is a negative OCSP response, we will treat the cert as revoked.
This means that, when OCSP is in use, an expired cert will be treated as a 
revoked cert.  

The errors I just described above are exactly the ones that will occur during
a real attack.  They are also the most common certificate errors.  The most 
common cause of these errors is server admins deliberately choosing to use 
unverifiable certs, and expecting users to accept them as legitimate.

Showing the certificate contents to the user, and asking the user to decide
on the cert's validity based on the contents, is like showing the user the
contents from a phishing server's web site, and asking the user to decide if 
the site is legit based on the tontents.  Either way, an attacker is going 
to make sure that the contents are as identical to the desired/expected 
contents as possible, and this will satisfy most users that the contents are 
legitimate, which is PRECISELY the basis of phishing.  Users' inability to 
distinguish legitimate contents from fake *IS* the security problem we are
fighting.  

I suggest that the next step to be taken for this bug is to design the UI
(probably in prefs) by which a user will be able to choose, DELIBERATELY,
(after giving it some thought), to override errors for a particular cert 
or site.
Nelson: I agree that every cert covered by your three bullet points, with the exception of certs issued by an unknown issuer, should be a hard stop.

In the case of certs issued by an unknown issuer or self-signed, I suggest that we adopt the "HTTP UI" approach advocated by Frank. So we present none of the usual security indicators which might confuse people into thinking that there was some confirmed identity. People who use self-signed certs should be happy with that - because it's a true reflection of reality.

You also make some excellent points about dealing with expired certificates. I think the right answer may involve some combination of the following ideas:

- A system, either built into the browser or an extension, which warns people when the certificate on the site they are accessing (or perhaps just for a whitelist of sites) is about to expire. Web developers can use this as a backstop check.

- Once a cert has expired, changing to HTTP-style UI for (say) a week (with a security info-bar) before cutting off access completely. This is a slightly gentler landing than an immediate hard stop.

- Asking CAs to keep expired certs in CRLs and OCSP for at least a month after expiry (to make the previous bullet's idea safer)

Gerv

> In the case of certs issued by an unknown issuer or self-signed, I suggest
> that we adopt the "HTTP UI" approach advocated by Frank.

I think that's a bad idea.  When MITM attackers do that, your https bookmarks will still work, and there will be almost no indication that something is wrong.  Also, your cookies (whether they're https-only or not) will probably be sent to the MITM attacker before you've even looked at the UI.
The problem I have with Frank's proposal is that it relies on users 
NOTICING the ABSENCE of positive UI to detect any problem at all.  
Users just don't notice absent UI, especially when they've seen it so
many times that they take it for granted.  

After you've gone to your bank's web site hundreds of times, do you 
actually look to see if the lock icon is locked on every visit?  
If not, then with Frank's proposal, an attacker could MITM you with
a simple self-signed cert, and you might never notice, or not until
it's too late.  
Jesse makes a good point. We don't and can't remember all the SSL sites the user has ever visited, so when we encounter a self-signed cert, we can't tell whether this is a site the user has visited before with a proper cert. People using self-signed certs will want cookies to work, so if we did this we couldn't just refuse to send cookies. Hmm. We could treat the connection as non-HTTPS for cookies as well as UI purposes. But that doesn't solve the bookmark issue. 

If I'm not mistaken, that kills the "HTTP UI for self-signed" idea :-((

So where do we go? How do we deal with self-signed certificates in a way which lets people use them if they choose, but doesn't expose users to risk? Do we just go with an in-page version of the current dialog, with better wording but the same options?

And we need to do something about the "saying you trust it means you trust it for all of its altnames as well" problem too...

Nelson: with Larry the Passport guy, it's not completely "absence of UI" - you'll get something like a grey Larry rather than a blue, active Larry with a dropdown of identity information. This is better than something just being missing.

Gerv

Nelson, if someone's going to MITM you, and http-style UI isn't going to be a sufficient warning, why use https at all?  Just use http and you're done, with the current UI.  I don't know whether an https->http redirect with a revoked cert is doable, but...

As for the bookmark (and maybe history) case, I don't know how much of a pain this would be to do from browser code, but here's a thought:

We have the ability to add arbitrary data to bookmark/history items via the annotations service.  We can store information about the cert in use (i.e. fingerprint and the degree of validation involved (i.e. EV vs. DV vs. self-signed/unknown).  We can figure out how to check this data early in the connection and take appropriate action as follows:

All data matches: Continue with connection
Cert has changed, but is equally trusted or better (i.e. DV -> EV upgrade for your bank): Continue with connection
Cert has changed, EV -> DV: Provide mildly scary UI, allow click-through
Cert has changed, EV/DV -> self-signed: Provide very scary UI, block all click-through
Aside:  Given that real DV SSL server certs from a real CA (known to mozilla 
products) are now reportedly available FOR FREE, it seems like mozilla is
proposing to go to A LOT OF WORK, just so users can continue to 
- avoid getting real certs, and 
- continue to use certs that are incorrectly made (e.g. wrong host names in 
the certs, expired, cert extensions that say "invalid for SSL server use").  

If users can get competently made valid SSL server certs for free, why 
shouldn't they?  
Why should Mozilla pay a huge development price for their reluctance? 

I'll reply to comment 29 in the next comment.
In reply to Mike's comment 29:
Mike, let me ask you to flesh out your proposal some more.  Your table 
describes 4 possible events that could occur on a SECOND (or subsequent) 
visit to an https site that has previously been visited.  I ask you to 
fill it in more, with information about:

1) what happens on the FIRST visit to a previously unvisited https server, 
   when its cert is a:
a) valid EV cert
b) valid DV cert
c) cert from an unknown issuer, but would be otherwise valid IF it had come
   from a trusted issuer
d) cert from an issuer known to the user, but not marked trusted by the user.
   That is, an untrusted issuer (different (worse?) than unknown issuer).
e) cert that appears to have been issued by a trusted issuer, (signature 
   verifies) but has other things that make it invalid on its face, such as:
   e1) expired
   e2) host name mismatch
   e3) contains extensons that say "this cert may NOT be used for SSL servers"
       (e.g. email-only certs)
f) cert from an unknown issuer and has any of the problems listed above
g) cert from an untrusted issuer and has any of the problems listed above

2) What happens on the second (or subsequent) visit, when the cert has changed, 
   and the new cert has any of the problems listed above.
Note that expired certs aren't merely "too old".  They're certs for which 
revocation information is no longer available from the issuer.  They could
have been compromised (private key stolen) and we'd have no way to find out.

Here are some additions to my list (above) of events for which we must decide
behavior:

1h) cert from a trusted issuer that the issuer claims has been revoked.

(Consider the original 4 events to be 2a-2d, and my previous question as 2e)
2f) on a second visit, cert is same as before, but now is revoked.
2g) on a second visit, cert has changed, and new cert is revoked.
BTW, NSS's cert database seems like the obvious place to store certs and information about what sites they've been used with in the past.  It would
be a bunch of work to add it to NSS, and Mozilla might be able to help NSS
with the labor to add such a feature to NSS.  IMO, that's the right way to
go, rather than adding YET ANOTHER cert database to the browser.  I wonder
if Bob Relyea agrees with my view. :-)
> real DV SSL server certs from a real CA (known to mozilla 
> products) are now reportedly available FOR FREE

Actually having your server support https is not free on all web hosts.  For example, DreamHost only supports https if you have a unique IP address, and charges $4/mo for unique IP addresses.  I've been trying to convince them to add support for TLS SNI for a while.

That said, I'd prefer requiring SSL to solutions that tie extension updates to specific certificates.
(In reply to comment #28)
> If I'm not mistaken, that kills the "HTTP UI for self-signed" idea :-((
> 
> So where do we go? How do we deal with self-signed certificates in a way which
> lets people use them if they choose, but doesn't expose users to risk? Do we
> just go with an in-page version of the current dialog, with better wording but
> the same options?

I originally put forth this proposal in large part as a strawman to get people thinking about this issue and discussing possible ways to handle it. I am coming around to the opinion that acceptance of self-signed certificates and display of the associated content should be conditioned on some positive action on the part of users, and that that action should not take the form of a modal dialog or even an in-page dialog.

To my mind in a production context (i.e., leaving testing aside) there are two (sort of) legitimate use cases for self-signed certs. The first is for people who want to offer an SSL-enabled site to the world, and can't afford an SSL certificate. The second is for people who want to offer an SSL-enabled site to a private group of people (e.g., for intranet use, or for a closed group on the Internet), and who for whatever reason don't want to participate in a public CA scheme.

Regarding the first use case, I think the financial argument is no longer compelling, now that there's at least one commercial CA offering free SSL certs, and perhaps one or more nonprofit CAs doing the same in future. (Incidentally, IMO it's irrelevant whether those free SSL certs are recognized by IE, Safari, Opera, KDE, etc., or not. In any case there are going to be browsers that throw errors on self-signed certs; that's not a problem we can fix, no matter what we do in our own UI.)

As to the second use case, for a private group (e.g., within a corporation, and among a set of friends on the public Internet) the site operator presumably knows who's in the group and can provide them instructions on how to configure their browsers or other applications (e.g., a mail client using IMAPS or SMTP over TLS) to properly connect to the site without errors. Thus IMO it's acceptable to require an initial configuration step before connecting to the site for the first time. Our concern should simply be that the method to do this is straightforward and clear to the user in terms of what is happening.

For example, one possibility would be to avoid the need to explicitly load the self-signed cert, either by navigating to the page or by explicitly importing it. Instead there could be an option in preferences to whitelist certain sites or domains (e.g., *.acme.com for Acme employees) in terms of allowing self-signed certs.

This doesn't address the "Internet cafe" problem, where a member of the private group wants to access the site from a public Internet terminal. My response to this scenario is that you're now in the first use case, where you want every possible Internet user to be able to access the site. So go get a free cert from a public CA. (Another response is that people concerned enough about security to set up a private SSL-enabled site might want to think twice about accessing that site from a public PC.)
Having written the above, I realize that domain whitelists probably aren't a good idea in this case given the potential for DNS spoofing. (Memo: Don't comment on bugs when you're sleepy.) So I'll go back to the idea of explicitly accepting self-signed SSL certs on a case-by-case basis, a la the SSH model, but doing so in a way that is far less prone to users doing the wrong thing than the current UI.

Mike: storing certificate information relating to links might be useful (both for this and for getting the info out later if fraud occurs), but we can't rely on it because people have to be allowed to clear out those data sources, and we can't start issuing security warnings if they do.

Also, what about:
Cert has changed (DV -> DV or EV -> EV; i.e. cert renewed)? That's a much more common case.

I think Frank's analysis of the use for self-signed certs is a good one, although I would add category 3): people who have an ideological attachment to a particular model for certificate issuance, and want to use a certificate from that issuer. ;-)

Requiring each site to go through a configuration step to download (over trusted HTTPS? ;-) a copy of the self-signed certificate and add it to the store (the "Web Sites" tab in the Firefox certificate manager?) before a connection is allowed seems like a sensible approach. Although it's a chunk of work.

The question is, do we provide a path from the "You can't connect - unknown issuer" error page to the certificate, or do we make them go out of band? If the former, there's a risk that users can be fooled into "clicking through", even though it would require quite a few clicks. But the latter is less convenient.

Gerv

(In reply to comment #37)

> Also, what about:
> Cert has changed (DV -> DV or EV -> EV; i.e. cert renewed)? 
> That's a much more common case.

I thought Mike's proposal in comment 29 covered that case.  It said:

>> Cert has changed, but is equally trusted or better (i.e. DV -> EV upgrade 
>> for your bank): Continue with connection

The key part there being "equally trusted", so it covers DV=>DV and EV->EV

> Requiring each site to go through a configuration step to download (over
> trusted HTTPS? ;-) a copy of the self-signed certificate and add it to the
> store (the "Web Sites" tab in the Firefox certificate manager?) before a
> connection is allowed seems like a sensible approach. Although it's a 
> chunk of work.

Being a "chunk of work" is a necessary part of the solution to the "users 
always override every error without thinking" problem.  Also, if it encourages
people to stop using self-signed certs, that's not a bad thing.

> The question is, do we provide a path from the "You can't connect - unknown
> issuer" error page to the certificate, or do we make them go out of band? If
> the former, there's a risk that users can be fooled into "clicking through",

Absolutely.  We've all seen web pages with step-by-step screen shots for how
to override errors.  I think that at least one of the windows/dialogs through 
which the user must pass to do this configuration should say something like:

"You're overriding a serious security warning!  If you're following 
instructions from a web site to do this, ask yourself this question:
If this web site is legitimate, why is it necessary for me to defeat 
my browser's security to make it work?"

> even though it would require quite a few clicks. But the latter is less
> convenient.

Precisely!  Making it inconvenient is a necessary part of the solution.
But remember that it should occur only once per server.
(In reply to comment #37)
> The question is, do we provide a path from the "You can't connect - unknown
> issuer" error page to the certificate, or do we make them go out of band?

I think the message from user studies (e.g., as discussed in Peter Gutmann's "security usability fundamentals" draft) is pretty clear: with any direct path many if not most users will likely just click on through with minimal thought, in order to accomplish the original task (viewing the web page or application). Forcing a break in this sequence (by requiring the user to go through an out-of-band configuration process) I think would be preferable from a security perspective, and I think is not overly onerous for the use case I think is most important (private group access to an SSL-protected site or set of sites), since it would typically be a one-time operation.
(In reply to comment #38)
> We've all seen web pages with step-by-step screen shots for how
> to override errors.

This is true. Even in the case of pre-configuration of a self-signed cert for access to a private site, the site's administrator's are typically going to send out emails for 

> I think that at least one of the windows/dialogs through 
> which the user must pass to do this configuration should say something like:
> 
> "You're overriding a serious security warning!  If you're following 
> instructions from a web site to do this, ask yourself this question:
> If this web site is legitimate, why is it necessary for me to defeat 
> my browser's security to make it work?"

I think Peter Gutmann's doc (referenced above) has useful advice on how to phrase such dialogs. Three key points from his discussion are 1) speak in the user's language, not technical jargon; 2) warn users of actual real-world consequences; and 3) indicate what most users would do (social validation). A (very off the cuff) example would be:

"You are about to override Firefox and force it to treat this as a legitimate site even though it may not be. Most people would not do this, and banks, online stores, or other public sites would not ask you to do this. If this is indeed a fake server then any information that you provide to it may be misused by criminals, for example to steal money from your bank account or fraudulently apply for credit cards in your name. Do you want to go ahead and treat it as legitimate anyway?"
Ooh, I like Frank's proposed text from comment 40, a lot.
So I think we're all trending towards a solution here, but in the interests of... trending quicker, I'm going to try to nail down the concrete questions necessary to get this change in.

1) Which warnings/errors do we want to migrate to error pages?  Frank identified:
- Self-signed certs
- Domain mismatch

Nelson, in comment 24, added
- Signed certs from a non-trusted CA
- Expired certs
- Revoked certs

I don't want scope-creep to kill this bug, so it is with some trepidation that I ask if that's a good list.  Is that a good list?  I assert that fixing those cases would already be a huge step forward, and maybe even that outside of that list, we open separate bugs of the "do error X like you do with the other ones."

2) Trusted list.  I think there is no good way to get around the requirement for an override list.  I don't think it needs to be easy to find.  I think probably it is an extra pane in either the certificates management UI (if we tie it to certs) or off the root PSM pref-pane (Advanced->Encryption in firefox) if we tie it to domain.

3) What code needs to be built?  I'm thinking we need an error page implemented, strings developed, and hooks in nsNSSDialogHelper or other, to invoke the error page when in a client that supports it?  I can happily put together the error page and strings for comment, I'm less confident about the best way to approach the NSS changes.


Johnathan wrote:

> 2) Trusted list.  I think there is no good way to get around the requirement
> for an override list.  I don't think it needs to be easy to find.  I think
> probably it is an extra pane in either the certificates management UI (if we
> tie it to certs) 

Note that there already is a cert manager tab for server certs that the user
has chosen to mark trusted.  These are the certs for which the user selects
"Accept this certificate permanently" or "Accept this certificate temporarily 
for this session" (within the same session).  This tab is the "Web Sites"
tab in cert manager.

> or off the root PSM pref-pane (Advanced->Encryption in firefox) if we tie 
> it to domain.

I think there's consensus that we do want to tie it to the domain name.  
But I'd suggest that the "web sites" tab is the right tab to display it 
in either case.

About the list of cert errors:  I think the 5 cases are:
- cert from an unknown issuer (includes self signed)
- cert from a known-but-untrusted issuer
- cert revoked by its issuer
- expired cert (issuer won't say if it's revoked or not)
- host name mismatch

I think those are all the major cases where we simply have no assurance
that the identity stated in the cert is truthful, or the right one, or
where we have positive assurance that it is NOT (e.g. revoked, mismatch).  
It'd be nice for some other NSS team member to confirm that.
Re. 1):

- cert from an unknown issuer (includes self signed)
- host name mismatch

I agree these should provoke a block, with no "go on anyway" override, but which can be worked around using a mechanism like we have discussed, e.g. the one I propose below.

- cert from a known-but-untrusted issuer
- expired cert (issuer won't say if it's revoked or not)
- cert revoked by its issuer
I'd say that in these cases, we should have the same block, but with the difference that we should not permit the cert to be trusted at all. That is, even if a cert has been added to the internal list, we should still do revocation and expiry checks on it, and check against the user's list of specifically untrusted issuers (ones where they have manually changed some bits). In practice, this would mean that they could add the cert to the list if they liked, but they'd still get the hard stop page instead of the site.

Re. 2): Nelson is right: the trusted list already exists. We just need to provide appropriate UI for adding to it. How do certs get there now? You visit a site using it and click "Trust this" on the dialog?

Perhaps the mechanism should be similar to the one for adding new roots. The user visits a URL which downloads the cert itself, and they are then presented with a dialog with some text like Franks (but hopefully shorter :-) and a "countdown timer" on the Accept button to make sure they read it and can't accidentally accept it.

Gerv

Having had a closer look at the Web Sites section of cert manager, I agree it's the obvious place to put it.  Right now, unless I'm mistaken, importing a cert into this list (outside of the existing dialogs which do it for you, as noted) is to click the import button, but this launches a file browser; it's only for local imports.  

I think asking them to download the cert and then add it via local import is a little too onerous.  If I remember correctly, though, Kai was looking at extending the functionality around certificate imports in here to allow you to point directly at a url to import the cert.  

If we end up with a solution where we error page on, e.g., a self signed cert, and the error page says "We can't trust this.  $FRANK_TEXT. If you have reason to know better than we do, click this button to open the cert manager, and add the cert to your trusted list, but we're not going to one-click that whole process for you." and if, once they get to that page, they click a button, point at a url, and go, then I think we have a solution that is appropriately onerous, and makes use of our existing resources in a sensible way.

kaie - can you comment on the work I mention?  This would be some of what we discussed back in March, when we met in Mountain View, but I confess I am foggy.

Sorry Johnathan, but "... click this button to open the cert manager, and add
the cert to your trusted list" just means that users will "click through" 
with two clicks instead of one.   It's still WAY WAY too easy, and doesn't
require any thought or any deliberation.  The whole point is to require thought.
So, make them figure out and remember how to go into cert manager and do the 
work there.  
If I understand correctly, we have reached an agreement that we will NOT do "use http-style UI for bad https".

I propose the bug subject should be changed.

We could continue the work in one of the other bugs that have been filed around this topic, and who have requests that are more closely related to the latest plans. But I'm ok to be flexible here.

I will write another comment for the questions you asked me to answer.

In comment 42 you ask, what errors should be converted to error pages?
All of them.

What special error dialogs do currently exist?

a) expired

b) domain mismatch

c) untrusted


There is no special dialog for "revoked". Revoked is a "full stop" and since the work in bug 107491 we already display error pages for all "full stop" errors.


c includes all the various reasons for untrusted: self-signed, issuer explicitly untrusted, issuer unknown


I will write more comments to describe my thoughts around converting these dialogs into error pages.

What is required to convert the errors dialogs to error pages?

The simple strategy is: Convert each of expired-dialog, domain-mismatch-dialog, untrusted-for-whatever-reason-dialog (includes self signed) into a new error page.

If you're looking for the simplest approach, and if you want to make all of these dialogs a full-stop-error-page, then ok, this would be simple.


But I recommend we should be slightly smarter.


A certificate can have problems from all 3 categories.
A certificate can be expired, have a domain-mismatch and be untrusted, at the same time!


We should report all problems with the cert at the same time.

Say, a cert is untrusted, and the user finds a way to override the trust (using the new mechanism that we will implement). Then the user might try to connect again, and will get another, different error message. We should avoid this frustration.


I'm making a recommendation here. I'm not making this a hard requirement.


But as of today, if a cert has all 3 problems, the user will get 3 consecutive dialogs.

And we agree, we still need error dialogs for Mail and other protocols.

So my proposal is:

- write code that combines the 3 separate error reporting dialogs into a single dialog

- when we run into at least one of the above failures, bring up a single error page (in the browser) or a single error dialog (in mail and other protocols)


The good news:

I have already worked on this proposal.
I have working code in bug 345007 that collects all errors reasons and brings up a single dialog.

I had intended the code in bug 345007 as the preparation for error pages.


Why did bug 345007 not land yet?

Because I was told: The new combined dialog that I had proposed has way too much details. (See bug 345007 comment 15 and following).


The good news is:
We no longer need to explain all the possible error reasons.

We agree that we no longer will allow click-through.
We agree we want that dialog (or error page) to be a full-stop.

That means, we can omit the big warning phrases.
We will omit the questions about whether or not to go ahead.


This reduces that UI to simply listing the cert's errors, and that brings up to a terse display.


Summary of the above:

- let's base our work on the patch I attached to bug 345007.
- strip out that "permantly override" mechanism from that patch
- strip out the display of potential error reasons from that patch
- convert the click-through dialog into a "sorry, full-stop" dialog


After we have done the above, we have the code that is able to bring up the correct error message in all protocols.

Finally, we can override that dialog with an error page for the special scenario of loading a page into a browser page.


(more comments on related work coming up)

So we have agreed to convert our existing
   show-error-and-allow-click-through

into a new approach which will be
   show-full-stop-error-and-require-to-override-somewhere-else


I'm recommending, our very first step should be: Introduce the new override mechanism.

Only after we have that in place switch to full-stop-errors.


(In reply to comment #45)
> Having had a closer look at the Web Sites section of cert manager, I agree it's
> the obvious place to put it.

I agree.


>  Right now, unless I'm mistaken, importing a cert
> into this list (outside of the existing dialogs which do it for you, as noted)
> is to click the import button, but this launches a file browser; it's only for
> local imports.

I think using the import button in that dialog to import a cert from a file is a very rare scenario.
Usually you get a cert into this tab by visiting an untrusted SSL server and using our existing click-through dialog and accepting it permanently.

(We have agreed to get rid of this possibility, as the future untrusted-cert-error-message will be a full-stop-error-message without the ability to click through).


> I think asking them to download the cert and then add it via local import is a
> little too onerous.  If I remember correctly, though, Kai was looking at
> extending the functionality around certificate imports in here to allow you to
> point directly at a url to import the cert.

Yes, that sounds overly complicated, more so, because as of today, we don't have a export cert feature (although we urgently need that for other reasons, and I hope that I'll be able to add it before Beta, Kaspar Brand contributed a nice patch in bug 315871).


> If we end up with a solution where we error page on, e.g., a self signed cert,
> and the error page says "We can't trust this.  $FRANK_TEXT. If you have reason
> to know better than we do, click this button to open the cert manager, and add
> the cert to your trusted list, but we're not going to one-click that whole
> process for you." and if, once they get to that page, they click a button,
> point at a url, and go, then I think we have a solution that is appropriately
> onerous, and makes use of our existing resources in a sensible way.

We agree we want an error page.

We agree we want a mechanism to allow an override for some errors (self-signed yes, domain-mismatch maybe, expired no).

We agree to make the override harder than today.

We agree a two-step-warning-and-confirm is still too easy.


In this quoted statement (from comment 45), Johnathan proposes "open the cert manager, and add the cert to your trusted list".

Nelson, in your comment 46 you are concerned that "users will click through 
with two clicks instead of one".

I think, this is not what Johnathan proposes.
Because we open Cert Manager, the user will see a complicated UI.
The user will see Cert Manager.
The user will have to figure out on his/her own HOW to add the override for the cert the user just got on this error page.

Right?

Nelson, I hope this particular concern is unnecessary, in the hope that we want to work on an approach that makes everybody happy.

(Note that I'm flexible on this topic, but I agree we should work to find a good  compromise.)


But how could it work?
Johnathan proposed I describe an earlier proposal in more detail:

> kaie - can you comment on the work I mention?  This would be some of what we
> discussed back in March


I will describe that idea in the next comment.
Summary: Use http-style UI for https URLs with invalid certificates → Use error pages for https invalid-certificate errors (instead of dialogs)
How should the user enter an override for a bad cert?

It has been proposed:

- the user should be required to do so 
  out of band of the connection attempt

- the user should manually enter the host name where the override 
  is to be active


In addition, because we must implement a solution that works with all kinds of weird servers, like servers who operate services on multiple ports of the same hostname, with different certificates on each port, we must bring in the port or protocol. I propose an override should specifically bound to the combination of {host name, port number, certificate}.

Another tricky problem is, if we want out-of-band override, but the override should be specific to a particular certificate, how should the user specify the cert? There can be multiple windows open, we can not really know which cert the users wants to override. And, if we offered a "list of recently seen bad certs", this would again allow for a kind of "click through" by selecting a bad cert from a list and saying "allow that". We don't want that.


This brought us to the idea of a wizard-based approach.

The starting point for the wizard is the "server certs" tab in Certificate Manager. There would be a new button. We probably shouldn't call it import. I propose a button label like "Add Override".


When the user clicks the button in order to enter an override, we'll bring up a smart dialog. You might want to look at the attached napkin drawing now.


The idea is, the user must manually type the hostname where the override shall be active.

We can pre-fill the "protocol/port" field with "https", assuming that most users will use this in Firefox and are trying to get to a web page.

If the user wants to connect using a different protocol or to a different port number, the user must type the protocol name or port number into the second edit box of that dialog.

(we might make use of the "select" button and allow the user to point-and-click from a list of most popular protocols, like imap-ssl, etc.)


Note, at the time the dialog opens, it is mostly empty.

The middle section "cert status" is empty.
The "info" section is empty.


After the user entered the hostname (and optionally port/protocol) the user shall press the "check cert" button.

At this time, we will open a connection to that host at the given port number.
We will obtain the certificate and check it for errors.


Now we can update the middle area.
We'll display of what's wrong with the cert.

We'll offer the user to click "view cert details" to open Certificate Viewer and look at all the shiny details.


Based on the cert status, we'll decide what can be done about this cert.
Is it an error that we allow to be overriden? (like self-signed)

Display the application's decision in the "Info" area.


If the application's policy allows for overriding the encountered problem, we enable the "Save Exception" button.

If the user decides to click "save exception":
- we'll import the cert.
- we will NOT assign generic trust to the cert 
  (because someone requested, the cert should be specifically 
   bound to the given host name and port).
- we will store the triple {cert fingerprint, host name, port}
  in our list of exceptions (outside of NSS cert database)


That's it.

Maybe we can reuse some code from bug 345007 in order to implement the stored triples.


There is one more thing to do.

The "web sites" tab of Cert Manager must change.
Neither "host name" nor "cert ID (fingerprint) will be sufficient as a primary key, because overrides are bound to a specific port.

In other words, we should change the "web sites" tab to have a column for "port number", too, and must change the primary key to the triple.


Just to be complete:
When the user uses this dialog to connect to a site with a valid certificate, the dialog should give positive feedback like "everything's fine".
It has been proposed, the dialog could then "just go away".
(But I don't like that idea, the user tried to do something, and we'd give no feedback? No).

So, when we encounter a good certificate, we'd display "good certificate, no override needed" and of course, keep the "save exception" button disabled.
Kai,

Thank you very much for your excellent summary of the state of things.  I hope I won't miss anything when I say that I believe this distills down to 2 work items (in order):

1) Implement support for the "Add Override Cert" wizard, to be launched from the Web Sites page of the Certificate Manager (based on attachement 269919).

2) Once that support exists, bug 345007 can be substantially simplified, and already contains most of the code necessary to make the actual transition to error pages (for clients that can support it).

Is that substantially correct?  If so, I would propose creating a new bug to track the new Override Cert UI (unless there is a bug tracking that?) and to make this bug into a meta bug, to be resolved once both the Override UI bug and bug 345007 are completed.

Kai, does this seem like a useful way forward?  If so, I will create the bug, and move the implementation conversation for your napkin drawing over there.
OK, so I've read through this latest wizard proposal.  The fact that it 
starts with a link/button from the error page means that in the user's mind 
it's still a reaction to the error.  It's not deliberate, It's just a lot 
more clicks.  The users will still slavishly go through all the steps.  
They'll copy-n-paste the URL from the desired page into the new form. 
They'll grumble about it more.  

I didn't see $FRANK_TEXT in it anywhere.  Maybe I'd think differently
of it if I did.  But I think you have to put in a step that requires
some exceptionally deliberate action from the user, like having to 
FIND a menu item, or having to dig down into prefs, in order to initiate
the procedure, in order for it to be other than purely reactionary.

As long as it remains a reactionary step, and is the only obvious choice
for users to follow when they get an error, it won't make users think
any more than they do now.  But It *will* cause a lot of negative user 
feedback from users who are already accustomed to clicking through all 
errors.  They will not see it as having improved their security, but only 
as having made them do more work.  

I think you must make this process look NOTHING like an error override.
Instead it must look like browser configuration.  It should be just as 
much effort for the user to find it and do it as any other aspect of 
configuration, and it must not begin with a button or link on an error page.
BTW, I should add that Kai's back-of-envelope UI mockup seems like a good
one for the browser config/prefs screen/dialog/page on which the user 
finally performs the configuration.  My issue is with how the user gets to 
that screen/dialog/page, not with the page content itself.
But there is no way for the site to provide the user with the download URL for the certificate. Is there? And if there isn't, then they can't just click through - they have to go off and find out the URL of the cert first.

Once they've done that, having a link to the wizard on the error page is a convenience. It seems dumb for software to say "Go to the Options window, Advanced Tab, Certificate button, Web Sites tab, and start the import wizard" when it could just provide you a way to go straight there.

Gerv

Any https URL is (effectively) a download URL for the site's certificate.
Once the user has found his way to Kai's "napkin drawing" page, the URL
of the failing site should be all he needs to "download" the certificate.

The bad cert page should not offer ANY instruction on how to override 
the error.  The idea is to STOP the user COLD from acting in a reactionary
way, such as is likely to occur when the user is being phished.  When the
user is thinking "OMG, I've gotta act NOW or my bank account will be wiped
out", he's not thinking clearly about the security implications of what he
is about to do.  Any trail of breadcrumbs by which he can voluntarily 
vitimize himself to the phisher's attack will be followed.  Only a dead end
will stop him.  The cert error page should be that dead end.
Depends on: 387480
I have opened bug 387480 to track the creation of the necessary UI in the Web Sites tab for adding domain/port-constrained trust to network-fetched certs.
After manually scanning through this bug report, I'm not really sure where this is going.  Therefore, I'm raising some issues that might or might not have been addressed.  

When a user invokes a security exception (e.g., comment #51), can that be temporarily for this session only?  Or having invoked it, will the user then be required to take action to disable or remove it?  

How will this handle the following situations, which I have encountered in real life?  (The more complicated you make the handling of these situations, the fewer users you will have.)  
  *  A site's domain has changed, but the old domain's certificate is still being served.  (This is what motivated me to write bug #276533.)  
  *  A site is being served as HTTPS without a really good reason (where a secure site is not necessarily appropriate) and with a certificate of unknown validity.  (See <https://www.biglumber.com/x/web?mp=1>, which also exhibits a domain mismatch.)  
  *  A site's certificate has expired.  (This often happens when an HTTPS site is developed by an outside service as a one-time project and then left to the site's owner to maintain.)  

My real concern is that, with so much attention focused on security, there might not be enough attention given to usability and how the end user deals with real-world situations.  

David: Firefox cannot take account of the reason why things are as they are, it just knows what is. All domain name mismatches will be handled the same, all expired certificates will be handled the same, and so on. 

Gerv
Reference comment #59:  I know that!  The issue is whether there will be an implementation that is oriented to the end user, who is likely to encounter one of these situations.  

It is likely that end users will want to have security exceptions that are temporary only or that are easily revoked.  It is also likely that end users will not want to get hung up in complex authorization steps when they encounter a secure site that has an expired certificate, a site that is well known to them (e.g., from an existing bookmark).  It is equally likely that they will not want complex steps to enter a secure site where the domain changed from www.foobar.com to merely foobar.com or from www.londonstockexchange.com to www.londonstockexchange.co.uk (per the description of bug #276533).  

Since the browser cannot make judgements regarding why there is a certificate mismatch or other certificate failure, user orientation will require an overall implementation that is generally simple to use, with a minimal number of user steps to execute.  It may also require user options rather than user force-feeding.  
(In reply to comment #60)
> It is likely that end users will want to have security exceptions that are
> temporary only or that are easily revoked.  

I'm sure we will have a list of the added certificates in preferences, with a Delete button to remove certificates that you no longer want to be exceptions. I'm equally sure that no-one will ever use it.

> It is also likely that end users
> will not want to get hung up in complex authorization steps when they encounter
> a secure site that has an expired certificate, a site that is well known to
> them (e.g., from an existing bookmark).  

Except that a site www.example.com presenting an expired certificate may well be www.evil.com with DNS poisoning and a stolen (and revoked) certificate.

> It is equally likely that they will
> not want complex steps to enter a secure site where the domain changed from
> www.foobar.com to merely foobar.com or from www.londonstockexchange.com to
> www.londonstockexchange.co.uk (per the description of bug #276533).

Then the site admins need to set up their sites and certs so that no complex steps are necessary.

Or are you suggesting we assume that www.foo.com and www.foo.co.uk are owned by the same people?

> Since the browser cannot make judgements regarding why there is a certificate
> mismatch or other certificate failure, user orientation will require an overall
> implementation that is generally simple to use, with a minimal number of user
> steps to execute.  It may also require user options rather than user
> force-feeding.  

I don't think your conclusion follows from your premises. I would phrase it thus:

"Since the browser cannot make judgements regarding why there is a certificate
mismatch or other certificate failure" -> for security it needs to assume the worst case scenario of an attack, and make it so that only a determined user can override the error.

Gerv

Which situations are more likely to trigger this capability, negligent site maintenance and configuration or hostile actions requiring strong security measures?  

I have actually encountered negligent site maintenance and configuration (e.g., the situations described in my comment #58).  None of them were contrived.  Maybe I'm overly cautious when I Web surf, but I have never encountered hostile Web sites that used or mimicked SSL (e.g., with defective certificates).    

While protection against hostile sites is important, how that protection is implemented should not create excessive burdens on users who are more likely to encounter mere negligence.  Thus I don't agree that this should be implemented such that "only a determined user can override the error".  That kind of implementation will drive away users.  
I agree with David. With the existing system, when I get to a bad-certificate error, it makes me stop and think:
- What is this site I'm trying to browse? Do I know it? If it was mentioned to me in an email or newspost, perhaps as a tinyurl URL, I may get away fast, not accepting the bad cert and not trying to view the dubious site.
- Din't I make a typo in the URL? What is it? What did I type?
- How well do I trust this site?
...if it's a site I trust (such as my ISP, who, like Microsoft, uses self-signed certs), I may accept the cert, permanentlmy if I can, temporarily if I must.
...if it's a site I trust and which I visit regularly, and Fx won't let me accept the cert permanently, I'll look for an extension to do it, and if I don't find one, I'll decide that "those Mozilla paranoids" are driving me, against my will, towards Opera or Konqueror.

I know that not every user will react by "stopping and thinking" the way I do: you show a luser the manuals but you cannot make him read; you can direct him to the info but you cannot make him think. If the end-user is in "non-thinking" mode, you can make your bad-cert error as detailed as you want, he won't read it: he'll click through if he can, and if he can't he'll fire up IE or maybe Safari.
(In reply to comment #62)
> Which situations are more likely to trigger this capability, negligent site
> maintenance and configuration or hostile actions requiring strong security
> measures?  
> 
> I have actually encountered negligent site maintenance and configuration (e.g.,
> the situations described in my comment #58).  None of them were contrived. 
> Maybe I'm overly cautious when I Web surf, but I have never encountered hostile
> Web sites that used or mimicked SSL (e.g., with defective certificates).    

Sure, I hear your point, but of course it would be silly to make this decision in terms of absolute frequency too.  Of course most sites online aren't malicious, otherwise the web wouldn't be much fun.  On the other hand, a malicious site we let through can do pretty monumental damage, whereas a misconfigured site that we prevent our users from reaching (until they tell us they know what they're doing) is comparatively harmless, and also easily fixed.  

Webmasters who care about their user experience will have a strong incentive to use valid certs, if they want SSL.  This is basically as it should be.  Sites like you mention above in reference to londonstockexchange.co.uk (still using a mismatch cert as of today) are putting their users at risk.  They are also not at all something we want to enable more of, by building a user interface which pleasantly accommodates them.  Ditto expired certificates, where a more laissez-faire approach opens up tasty attack vectors, since CAs don't retain revocation data for expired certs.

I understand how one can look at a proposal which involves deliberately making certain interactions more lengthy in the name of security, and feel like users haven't been considered.  In truth, though, I have no interest in a system, even a provably, perfectly secure one, if no one will use it.  

But SSL doesn't help our users unless it means something.  CAs vet the information in the certificates they issue, and are audited on that vetting, otherwise they don't make it into our root store.  What's the point of that, how does it help our users, if we then streamline the ignoring of that information in the name of ease of use?

Blocking bad certs by default is something we should have been doing all along though, and had we done so the SSL world today would likely have a lot fewer londonstockexchange.co.uk's - which is a net WIN for users.

> While protection against hostile sites is important, how that protection is
> implemented should not create excessive burdens on users who are more likely to
> encounter mere negligence.  Thus I don't agree that this should be implemented
> such that "only a determined user can override the error".  That kind of
> implementation will drive away users.  

I'm not convinced, here.  I think a lot of our users view us as a more secure choice, I think they're right, and I think we will maintain and grow that reputation to the extent that we are willing to put our users ahead of negligent site operators.  On balance, I suspect that it will be the negligent site owners who will lose users, if they persist in ignoring the problem.

Out of interest, what happened to the idea gerv mentioned in comment 15:

"On the other hand, one might do B) for site name mismatches (or perhaps some
site name mismatches, **depending on what the effective TLD service says about
the two domains in question**)."

I'm guessing the subdomain mismatches problem is actually quite common and I know it's a problem on our internal site. I may be misunderstanding something, but it looks quite unlikely that an attacker can have control over a sibling of a legitimate subdomain, in cases where security really matters. So perhaps in this case the configuration step could be made a little easier?

(In reply to comment #52)
> I believe this distills down to 2 work
> items (in order):
> 
> 1) Implement support for the "Add Override Cert" wizard, to be launched from
> the Web Sites page of the Certificate Manager (based on attachement 269919).
>
> 2) Once that support exists, bug 345007 can be substantially simplified, and
> already contains most of the code necessary to make the actual transition to
> error pages (for clients that can support it).


Yes, this seems complete, however with one more detail:

We remove the old dialogs, but we still need a combined dialog for other procotols than https.

So the new code shall be flexible enough to either report the error using a dialog, or as an error page (using the existing mechanism implemented with bug 107491, at the time the error happens inside PSM, we look for mExternalErrorReporting).



> Is that substantially correct?  If so, I would propose creating a new bug to
> track the new Override Cert UI (unless there is a bug tracking that?) and to
> make this bug into a meta bug, to be resolved once both the Override UI bug 
> and bug 345007 are completed.
> 
> Kai, does this seem like a useful way forward?  If so, I will create the bug,
> and move the implementation conversation for your napkin drawing over there.

Sounds good to me, thanks.

(In reply to comment #53)
> The fact that it 
> starts with a link/button from the error page 

I didn't say that (I hope).

I'm saying:
- show the error page, full stop
- the user must be smart enough to find cert manager,
  the server tab and the button

(In reply to comment #55)
> But there is no way for the site to provide the user with the download URL for
> the certificate. Is there? 

As Nelson said, the idea is, the user enters the hostname and the protocol, like https)

The trailing /path/to/somewhere.html is not required.


> And if there isn't, then they can't just click
> through - they have to go off and find out the URL of the cert first.

Or at least the host name. And the port number (if for whatever reason the site does not use the standard https port 443, or the port of the mail protocol).


> Once they've done that, having a link to the wizard on the error page is a
> convenience. It seems dumb for software to say "Go to the Options window,
> Advanced Tab, Certificate button, Web Sites tab, and start the import wizard"
> when it could just provide you a way to go straight there.

I agree with Nelson that we don't want to say that.

Just say "can't connect, cert is bad, because..."

Don't tell the user there is a mechanism to override.

(In reply to comment #65)
> I'm guessing the subdomain mismatches problem is actually quite common and I
> know it's a problem on our internal site. I may be misunderstanding something,
> but it looks quite unlikely that an attacker can have control over a sibling of
> a legitimate subdomain, in cases where security really matters. So perhaps in
> this case the configuration step could be made a little easier?

If want to use many subdomains, and you are allowed to (because you own the TLD), you can get a wildcard cert like *.mycompany.com

But the browser doesn't know whether we in fact have
  customer1.somehostingcompany.com
  customer2.somehostingcompany.com

In response to Gerv's comment 15:

I really like Gerv's idea to give "ahead warning" if a cert is about to expire soon. If we're switching to the "full stop" behavior, giving feedback seems like a good idea to me.

But a complex page might load content from 20 different sites, and 5 of them might expire within the next 2 weeks.

So any attempt to give an early warning would require a mechanism to provide a list of certs/hostnames. So maybe a status bar icon (like the suppressed popup icon) and when clicked we could open page info with a tab about soon-to-expire certs.

If you think we should do this, I propose to file a separate enhancement bug.

In reply to comment 65, One upon a time, long ago, the browser did allow
some certs to be considered domain name matches if the domains matched,
effectively treating every cert as a wildcard cert for the domain of the
server.  That quickly became reported as a huge vulnerability by the usual
vulnerability alarm services, and the feature was removed shortly therafter.
Let's not repeat that.
Kai: Let's not overcomplicate things. I was actually imagining that the feature would either be an extension, or would require about:config pref tweaking for a whitelist of domains for which the warning was shown. And I think it's fine for it to warn for top-level pages only.

Nelson: why is it a vulnerability? Surely the owner of foo.com could get a cert for bar.foo.com, even if they have delegated responsibility for that domain name to a third party? So treating a cert as a cert for the domain and all subdomains is just a reflection of what is true in practice.

Of course, it wouldn't do much for the CA's business model...

I think it's important for the overrides to only apply to a single protocol/host/port triplet, even if it's a wildcard cert or has alternative names. That prevents a cert being trusted in one context and that trust overflowing into another. (This is specced on the wiki page, I believe.)

The cleanest interface for the override would be for the user to paste the URL of the website (including port number, if appropriate) into a text box, and for Firefox to go off, fetch the cert and add it. Is that what's envisaged?

Gerv

In reply to comment 72:  "why is it a vulnerability?"
Because it allows the sysadmin for funandgames.corporation.com to use his
system to masquerade as payroll.corporation.com.
Attached patch Patch v1 (obsolete) — — Splinter Review 
This patch implements a backend service to store overrides for specific combinations hostname-port-certificate.

It changes PSM to (hopefully always) provide a nsISSLStatus object, even when a connection gets canceled because of an invalid cert (as we want to do by default in the future).

This could allow the implementation of our desired add-cert-override-wizard to make use of an xmlhttprequest in order to obtain the cert.

But the cert alone is not sufficient. As information like domain-mismatch is tied to the specific connection attempt, I extended nsISSLStatus to provide domain-mismatch/expired/untrusted flags.

In addition this patch removes our current dialogs for domain-mismatch, untrusted cert or expired certs. It replaces them with an error page (in the browser) or an error dialog (for all other protocols).

The error page is simple at this time. It uses our general SSL error page that we recently introduced with bug 107491. It consists of these strings:

It will always start with this string, where %S is host:port

+certErrorIntro=An error occurred during a connection to %S because it uses an invalid security certificate.


Then it will contain 1, 2 or 3 of the following strings. If there is only a domain, you'll only get string certErrorMismatch. If a cert has all 3 classes of errors, you'll get 3 strings. (only one of expired/not-yet-valid)

+certErrorUntrusted=The certificate is not trusted or its issuer certificate is invalid.
+certErrorMismatch=The certificate is not valid for domain name %S.
+certErrorExpired=The certificate has expired on %S.
+certErrorNotYetValid=The certificate will not be valid until %S.

(Note, if you're going to test, there are some links here: http://kuix.de/mozilla/certwarndiscussion/proposal20061016/ 
Ignore the screenshots, they do not reflect the latest patch.)


(Implementing a pretty error page like attachment 212595 [details] will require more work.)
I missed to include these changes in Patch v1
I'm changing the bug summary, as we must address all protocols at the same time (not just https).
Summary: Use error pages for https invalid-certificate errors (instead of dialogs) → New error reporting for invalid-certificate errors (error page for https, or combined dialog)
(In reply to comment #72)
> Kai: Let's not overcomplicate things. I was actually imagining that the feature
> would either be an extension, or would require about:config pref tweaking for a
> whitelist of domains for which the warning was shown. And I think it's fine for
> it to warn for top-level pages only.

When I first read this, I was wondering whether this applies to the proposal in general, but Gerv clarified, hist statement only applies to the "give ahead warning of expiring certs".

I'm really open to all options on this. As you say it could well be done using an extension, I think we agree it can be done in a separate step.


> The cleanest interface for the override would be for the user to paste the URL
> of the website (including port number, if appropriate) into a text box, and for
> Firefox to go off, fetch the cert and add it. Is that what's envisaged?

I'd leave that to Johnathan, as he'll be doing the UI implementation. I'm ok for the field to accept URLs, as well, but the tricky part is, IMHO, this UI should be implemented in a way suitable for all Mozilla applications, which includes the Mail and LDAP protocols, etc., where URLs are not used by end users. That was the motivation for separating the host and port/scheme fields.

Please change the word "New" in the bug summary to some other work, such as
"Improved" or "Replacement".  Every email update about this bug looks like
a New bug being reported.  Thanks.
Summary: New error reporting for invalid-certificate errors (error page for https, or combined dialog) → Improve error reporting for invalid-certificate errors (error page for https, or combined dialog)
This might be a stupid question, but: why is it more of a security threat to connect to a site over HTTPS with a bad certificate, than to connect to it over HTTP?  In either case, you have no assurance that the site is legitimate.  Why should the HTTPS site be treated as less secure?  In fact, it's *more* secure: while spoofing is just as possible with HTTPS as with HTTP, an attacker who merely eavesdrops on an HTTPS connection will not be able to read transmitted data such as passwords, whereas using HTTP an eavesdropper could pick up all exchanged data.  This can be a useful benefit.

Of course, you can say that site admins should use free certs instead of self-signed ones, and that's a good point that would increase the security of the exchange.  But I have to ask how many site admins will either disable HTTPS (making their site less secure than HTTP), or tell users to use a different browser, rather than fixing their certificate, which they may not have the time/inclination/knowledge to do.  Furthermore, it may be that the site admin does not control an entire domain name but only a subdirectory, or has de facto control over a site but cannot contact the registered owner of the domain, etc., etc.  In these cases a self-signed certificate should (if I understand correctly) provide protection against eavesdroppers, without spoofing protection.

(Needless to say, none of the above applies to certificates that have been revoked.  Then you have definite knowledge that there was probably some kind of malicious activity using the certificate, or attempts at such.)
(In reply to comment #79)
> This might be a stupid question, but: why is it more of a security threat to
> connect to a site over HTTPS with a bad certificate, than to connect to it over
> HTTP?  

Because it gives users a false sense of security and risks mixing secure content/cookies/passwords with malicious scripts.

> In fact, it's *more* secure:
> while spoofing is just as possible with HTTPS as with HTTP, an attacker who
> merely eavesdrops on an HTTPS connection will not be able to read transmitted
> data such as passwords

When is it possible to eavesdrop but not possible to MITM?

Anyway, if you have data worth protecting, you should be willing to spend the two hours to get your site using HTTPS correctly.

> But I have to ask how many site admins will either disable HTTPS
> (making their site less secure than HTTP), or tell users to use a different
> browser, rather than fixing their certificate, which they may not have the
> time/inclination/knowledge to do.

Self-signed certificates are already uncommon on the web, thanks the current security dialogs, so I'm not too worried about the latter outcome.
(In reply to comment #80)
> Because it gives users a false sense of security

Only if they're perceptive and technically knowledgeable enough to spot the extra letter in the protocol prefix in the URL bar, which is a fairly marginal case.  I would expect most people who understand the difference between "http" and "https" to be sophisticated enough to not be immediately lulled into a sense of security by the latter, in the very conspicuous absence of the URL bar coloring and padlock icon.

> and risks mixing secure
> content/cookies/passwords with malicious scripts.

An issue with the content/cookie/password handling, not with permitted/prohibited user actions.

> When is it possible to eavesdrop but not possible to MITM?

It's always much easier, since you don't have to construct and maintain a convincing web page.  You could, for instance, listen for any POST containing something that looked like a credit-card number or password and log those for later use.  I can also imagine scenarios where you have a limited number of routers and can only listen to part of the exchange, making spoofing impractical, but those are probably less likely.

> Anyway, if you have data worth protecting, you should be willing to spend the
> two hours to get your site using HTTPS correctly.

"Worth protecting" is always relative.  It may merit the zero minutes it takes to leave alone your existing HTTPS configuration, but not the couple of hours (or more, depending on proficiency) to set up a proper certificate.

> Self-signed certificates are already uncommon on the web, thanks the current
> security dialogs, so I'm not too worried about the latter outcome.

I don't know about you, but in the past, I've used self-signed certificates on a regular basis.  I run a site where a previous admin had apparently set up self-signed and non-matching certificates just (I assume) for the transmission security.  Others have linked to other examples of sites doing this kind of thing.

Overall, as a lowly Firefox user who's also a Web developer/system administrator, I don't think there's much of anything to be gained by this, and something to be lost (in terms of inconvenience to users).  But that's me.
I think that the percentage of FireFox users who set up and use their own
self-signed certificates (instead of getting a verifiable one for free) is
probably less than 1 on a 1000, less than 0.1 %.  Historically, for the 
convenience of those 0.1%, we have weakened the security for the other 99.9+% 
to the point where it has become a derisive joke among security experts.  
It's clearly time to reverse that trend.  

If we need a special mode for those 0.1% of users, so they can use invalid
certs without any inconvenience to themselves, then lets make a special 
"advanced" mode, settable only through about:config, that enables them to 
hurt themselves, but doesn't lessent the security for the other 99.9+%
Attached patch Patch v2 (obsolete) — — Splinter Review 
(In reply to comment #74)
> This patch ...
> 
> changes PSM to (hopefully always) provide a nsISSLStatus object, even when a
> connection gets canceled because of an invalid cert (as we want to do by
> default in the future).
> 
> This could allow the implementation of our desired add-cert-override-wizard to
> make use of an xmlhttprequest in order to obtain the cert.
> 

It turned out this didn't work yet.

When Johnathan and Gavin tested to make use of this using XMLHttpRequest, they didn't get all the details. Thanks a lot to the hints I received. I was able to code and test a mechanism that works for me.

My other comments from comment 74 still apply.
Attachment #273696 - Attachment is obsolete: true
Attachment #274679 - Attachment is obsolete: true
I used this snippet for testing. I adds test buttons to cert manager that trigger fetching.


FYI, depending on whether the cert is good or bad, there are two different mechanisms used for obtaining the status details.

If the cert is good, one can immediately fetch the details from the channel.

However, if the cert was bad, it has to be obtained from the notification callback.

In my testing, I attempted to access the listener.mStatus from within the dotest() function, but at that time it still was NULL. I assume this is a matter of timing.
Attached patch Patch v3 (obsolete) — — Splinter Review 
Slightly changed bug, on top of patch v2 from bug 386654 (attachment 276552 [details] [diff] [review]), with merging conflicts fixed.
Attachment #276534 - Attachment is obsolete: true
Flags: blocking1.9? → blocking1.9+
Flags: in-litmus?
Attached patch Patch v4 - work in progress (obsolete) — — Splinter Review 
This patch works for me.
I need to review it myself for memory leaks and should improve the way it references the pointers for the new auxiliary data structures, probably wrap them in auto ptrs.

It's not yet providing a replacement to fetch certs from any given port (including mail ports), I'll do that as a separate step and patch.

This patch currently includes the patch from bug 387480, I'll remove that from this patch before I request reviews.
Assignee: nobody → kengert
Attachment #276553 - Attachment is obsolete: true
Status: NEW → ASSIGNED
I should mention, this patch modifies the web sites tab of cert manager to display the new kind of overrides that we're adding with bug 387480.

Comment on attachment 280554 [details] [diff] [review]
Patch v4 - work in progress

You didn't ask for review of this patch, so I won't give it a r+ or r-,
but I object to part of this large patch (shown below) for reasons I 
gave in bug 193960 comment 23.

>Index: mozilla/security/manager/ssl/src/nsNSSCertHelper.cpp

>@@ -2140,8 +2140,6 @@ getCertType(CERTCertificate *cert)
>     return nsIX509Cert::EMAIL_CERT;
>   if (CERT_IsCACert(cert,NULL))
>     return nsIX509Cert::CA_CERT;
>-  if (cert->emailAddr)
>-    return nsIX509Cert::EMAIL_CERT;
>   return nsIX509Cert::UNKNOWN_CERT;
> }
(In reply to comment #88)
> (From update of attachment 280554 [details] [diff] [review])
> You didn't ask for review of this patch, so I won't give it a r+ or r-,
> but I object to part of this large patch (shown below) for reasons I 
> gave in bug 193960 comment 23.

My response is in bug 193960 comment 24. You might have assumed "trust.HasPeer" refers to "trusted peer", but all it does is checking for "valid peer". I propose we discuss this detail in bug 193960 and summarize it here once we have an agreement.

Incorrect.  I have made no such assumption.  the "valid peer" trust flag is
an OVERRIDE.  It forces a cert to be treated as valid, even when on its face
it is not valid.  For a long time, PSM erroneously set that flag on all certs
it imported into the DB, something that we fixed recently (IINM).  
This patch says, in effect, only display certs that have had the override 
flag set on them.  That's wrong.  More in bug 193960.
(In reply to comment #90)
> Incorrect.  I have made no such assumption.  the "valid peer" trust flag is
> an OVERRIDE.  It forces a cert to be treated as valid, even when on its face
> it is not valid.  For a long time, PSM erroneously set that flag on all certs
> it imported into the DB, something that we fixed recently (IINM).  
> This patch says, in effect, only display certs that have had the override 
> flag set on them.  That's wrong.  More in bug 193960.

Thanks for the clarification.

I have reverted the change you criticized in comment 88, the next patch will no longer make that change. I would like to store certs (associated to an override) without any trust flags associated. In order to categorize such certs, which might be either "server" or "other people" or "orphan" certs, I will compare against the list of overrides managed by PSM.
Attached patch Patch v5 (obsolete) — — Splinter Review 
Let's start the review of this monster, I think I'm done with 99% of the work, although I need to self-review and clean up this patch a bit.

We should look at the UI and the strings first (the changed .properties and .dtd files are at the top of the patch by coincidence).

Johnathan, this patch contains my proposal for function addException for your patch in bug 387480.
Attachment #280554 - Attachment is obsolete: true
Attachment #281159 - Flags: review?(rrelyea)
Patch v5 removes the old nsIBadCertListener and introduces the new replacement nsIBadCertListener2, which can only be used to suppress the error message display. It can no longer be used to "make the connection work anyway".

I found several places where the old interface was used. Here is my first round of changes I used to make it compile.

In particular Mike Connor was interested that we will still be able to suppress error messages caused by bad certs, I believe in nsXPInstallManager, so I'm asking Mike to have a first look on this.
Attachment #281161 - Flags: review?(mconnor)
This screen shot illustrates the new look and feel of the web sites tab in cert manager. See next comment for the explanation.
Attachment #281162 - Attachment is patch: false
Attachment #281162 - Attachment mime type: text/plain → image/png
Comments for understanding / reviewing Patch v5:


nsCertTree.cpp implements the tree display of Cert Manager.
It uses several data structures for storing the information displayed.
One of them was mCertArray, an array of all the displayed certs in sorted order.

After this patch, multiple displayed lines can refer to the same cert.
In addition, the display requires additional information, not associated directly to the cert, 
but originating from our separate list of host:port based overrides.

I introduced a wrapper data structure nsCertTreeDispInfo. 
Each object of that type represents one displayed certificate line in the tree,
which holds the type of entry (cert from db or a host:port override) and optional details for display.

In other words, array<cert> gets replaced with array<nsCertTreeDispInfo>.


The JS code used in Cert Manager's UI needs to access these new properties for making decisions:
- can the element be "edited" (have its trust changed)
- can we display the cert associated to the element

Therefore the new data structure is made available as nsICertTreeItem and can be obtained using nsICertTree.getTreeItem()

The JS code has a function getSelectedCerts. I cloned this function into a new getSelectedTreeItems. If you wonder about the style of that code, it's really a clone of that other function, so I'm not inventing something new here.


I changed the way the "delete" function works in cert manager. In the past, the delete was done in JS and the change was communicated to the tree data structure in order to synch. As the new world delete might only delete an override, but not a cert, I completely changed that. The "confirmation" dialog will get a string representation for each selected item, but it will no longer delete. Instead the delete requests are sent to the data structure that holds the display items (nsICertTree) and will decide accordingly. A cert will not get deleted while there are still other items refering to it (for this I'm using the new helper data structure nsCertAddonInfo which holds the cert and a reference counter).


Some words about the visual presentation and the possible data behind it.

In the past, the web sites tab would only display the following kinds of certs:
- server certs that got imported and have permanent trust associated

After the new patch, it will no longer be possible to use "bad cert alert click through" and have certs permanently trusted. But end users who update to a newer version of Mozilla may still have such old overrides stored in their profile. So, we must continue to display them. In order to distinguish them, they will be shown with a '*' in the new Sites column, indicating the cert is valid for 'any' host. (Cert Manager will allow the user to manually delete such old entries.)


The new kind of overrides are host:port specific. A cert is associated and only the given cert will be accepted on the host:port. The cert will not be allowed for any other host:port combinations, unless there are additional overrides stored for the same cert (which will be listed as separate lines in the display).

An example for such an override is shown in the screenshot for mur.at:443


The third kind of visual represenatation is kind of an edge case. Most users will never see it. The new kind of overrides are not stored in the NSS database, instead we manage them at the application level in the PSM code. Profiles contain a new text file cert_overrides.txt (more on this file later). As of today, the certificate database files are closely related to the application profile. However, this will change in the nearby future. The NSS database can be shared amongst multiple applications (and each user login will likely only have a single database).

In such a shared scenario, the cert we had stored for convenience might get "lost" (because the user deleted it using some other application). When this happens, our application will no longer be able to display the certificate associated to an override. Instead, the proposed UI will display the cert as (Unknown) for organization and (Not Stored) for certificate name. However, the override will still work. We stored the fingerprint of the certificate together with the override and will be able to detect the matching cert at the time we connect to the site.


Based on the above three kinds of lines, I adjusted the state of the edit and view buttons.

The "edit" (trust) button can only be used when an old-style permanent-trust item is selected. The button is grayed out for the new host:port overrides. You can't edit them, only delete them. You can, however, re-run the wizard for the same host:port, and the resulting new entry will replace the current one.

The "view" (cert) button can be used for old-style entries and for new-style entries if the associated cert is available in the database. It's disabled for the entries where the cert got lost.


Some details about the new configuration file cert_overrides.txt

It's an ASCII file, one entry per line, stores host:port, SHA-1 fingerprint of associated certificate, the certificate "key" for finding it in the database (as base64 encoded issuer name + serial number).
Finally, it contains a string representation of a bitmask, where the bits are M (overrides domain mismatch), U (override untrusted, the equivalent of the old permanent trust) and T (override Time errors like expired or not-yet-trusted).
This bitmask represents the errors shown to the user at the time the user used the "add exception" wizard.

Suppose, at the time the wizard was used, the cert had a "mismatch" but was otherwise valid. The user adds an exception. We only store an override for the mismatch. If at a later time the certificate becomes untrusted (by changing global trust) or expires, we will again reject a connection to the site. The user will be forced to re-run the wizard to override the new failures, if desired.

Example line from this file:
mur.at:443      SHA1    70:BC:BA:13:58:11:86:D0:31:FD:21:0B:94:D9:C1:E2:E3:D1:26:2D     MU      AAAAAAAAAAAAAAACAAAAVjMFMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD  VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFz  cyAzIFJvb3Q=


You'll see that the patch completely removes the old dialogs:
- domain-mismatch
- untrusted cert
- expired cert


The patch contains a change I wanted to do earlier, but couldn't do on the 1.8 branch:
nsIX509Cert3 derives from nsIX509Cert2 which derives from nsIX509Cert


The patch still contains some "#if 0" sections with brainstorming, I'll remove them before the final patch.


Minor TODO for the next patch, I will work on this while we review:
- I need to make the cert-overrides service threadsafe. This will be a small change on top of this patch to use a lock around accessing the in-memory list of overrides.
- I must clean up the in-memory-array in nsCertTree::FreeCertArray(), just a simple loop

Elsewhere there is a RFE requesting that we get rid of the Edit button,
and combine the edit function (which is merely 3 checkboxes) into the 
other cert list views, such as the cert chain view (used to view server 
certs) and the cert manager's tabs.  Can we consider that change now?
(In reply to comment #96)
> Elsewhere there is a RFE requesting that we get rid of the Edit button,
> and combine the edit function (which is merely 3 checkboxes) into the 
> other cert list views, such as the cert chain view (used to view server 
> certs) and the cert manager's tabs.  Can we consider that change now?

I'm ok with the idea of doing that change, but it does not overlap with the code changes in this bug, and there I would like to keep it as a separate task.

Explaining why it's separate in more detail:
- this bug does not touch how "edit" and "view" work (it only touches whether buttons are enabled or disabled), so all such changes would not overlap with the patch.
- your requested change would touch the UI for all cert manager tabs (while this patch only changes the web sites tab)

I agree both with the idea of the change mentioned by Nelson in comment 96, and with Kai's assessment that we not include it in the work here.  This is already a large patch, and codependent in an uncomfortable way with the one in bug 387480, I think we should be looking to minimize the delta here, rather than adding on, even if the work is related.
Attached patch Patch v6 (obsolete) — — Splinter Review 
Ok, my TODO list for this patch is done.
Can you please review?

I added the cleanup (converted the array in observer service to hold nsRefPtr, not raw pointers) and the thread safety changes (added a monitor to the observer service).
I've changed the uuids for the interfaces where I change the inheritance.
I've done a round of self reviewing and hopefully no longer have leaks.
I renamed some variables for clarity and added a bunch of comments.
If you wonder why I did that change in the SmartCardEvent code, it is to fix a compiler warning about incorrect order of initializers.

The screen shot and the patch for code outside of PSM remain unchanged.
Attachment #281159 - Attachment is obsolete: true
Attachment #281307 - Flags: review?(rrelyea)
Attachment #281159 - Flags: review?(rrelyea)
Comment on attachment 281161 [details] [diff] [review]
Changes outside of PSM based on Patch v5

r=me
Attachment #281161 - Flags: review?(mconnor) → review+
Attached patch Patch v7 — — Splinter Review 
BobR sent me review comments by private mail.
Here is the next patch.

The patch no longer contains the changes to extensions/help, they are included in that other patch attached to this bug (already reviewed by Mike).

The patch contains an addition to config/system-headers, so that linking works on x86_64.

Other changes requested by Bob are:
- renamed selected_cert_index to selected_index for clarity
- removed an unused var
- removed a TODO comment that is now done
- added some more out-of-memory checks and null checks around
  GetCertsByTypeFromCertList
- simplified some bit handling code
- converted the use of sha1 to sha256 and changed it to be generic
  based on hash algorithm identifier OIDs
- removed unnecessary writing of cert overrides on profile switch
  (we write whenever adding or removing an entry)
Attachment #281307 - Attachment is obsolete: true
Attachment #281800 - Flags: review?(rrelyea)
Attachment #281307 - Flags: review?(rrelyea)
FYI, entries in cert_override.txt now look like this:

mur.at:443      OID.2.16.840.1.101.3.4.2.1      F8:92:08:EE:6D:C9:26:3F:5B:2C:0E:E8:14:35:33:AA:AB:44:61:2D:48:BA:36:B5:59:E5:B8:6D:76:6A:39:E3    MU      AAAAAAAAAAAAAAACAAAAVjMFMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD  VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFz  cyAzIFJvb3Q=

FYI, the columns in that config file are separated by tabs. The base64-encoded cert contains spaces, these were converted from the original newlines to spaces. This was the most efficient conversion that keeps the data in a single line, without requiring buffer shifting. The decoder will skip all whitespace.

No UI changes in patch v7.

Comment on attachment 281161 [details] [diff] [review]
Changes outside of PSM based on Patch v5

Mike, thanks for the review.

Does this patch need sr?

Boris, it's mostly deleted code, with a small amount of changed code.
Attachment #281161 - Flags: superreview?(bzbarsky)
I'm sorry, but I'm swamped.  Please ask someone else for sr, ok?
In reply to comment 102,
Kai, what's the colon-separated hex, and why isn't it base64 encoded instead?
(In reply to comment #105)
> Kai, what's the colon-separated hex, and why isn't it base64 encoded instead?

The fields in the line are:

- host:port
- OID of hash algorithm (fingerprint algorithm)
- the fingerprint in colon-separated-hex (in this case sha256)
- bitmask of M, U, T for overrides
- base64-encoded issuer+serial number (dbkey)

When comparing a site's cert against the stored override, we will compare both issuer+serial number and the fingerprint.

Comment on attachment 281161 [details] [diff] [review]
Changes outside of PSM based on Patch v5

Why wouldn't you just remove the badCertListener from xpinstall like you did elsewhere? There are two cases in XPInstall: if "chrome" is doing the install (extension update or plugin finder, for example) then we wanted to suppress the dialogs. If the user entered the URL in the address bar then we wanted it to work "like the web". But if normal surfing doesn't get dialogs anymore then I don't need a badcertlistener2 to supress them, right?

sr=dveditz overall. we can file a followup bug on xpinstall if we want to change it.
Attachment #281161 - Flags: superreview?(bzbarsky) → superreview+
Note also bug 228684, which deals with the user experience of nagging dialog box popups.

There is an extension to help deal with certificates that have problems: the user is given the option to create a whitelist, so that mismatched domains or expired certificates can still be honored without incident.

The UI for this extension is very good.  With the opportunity to create a whitelist for frequently-encountered certificates, the user will encounter errors much less often.

Having less errors for the user means less chance of annoying the user into just blindly clicking past everything and not reading the warnings in the first place.  These popup dialog boxes are "crying wolf" too often, teaching users to ignore symptoms of a real attack.

If the suggested change is made here, to change these SSL errors from popup dialogs to placeholder webpages, I hope this whitelist UI enhancement can be made at the same time.

(In reply to comment #108)
> If the suggested change is made here, to change these SSL errors from popup
> dialogs to placeholder webpages, I hope this whitelist UI enhancement can be
> made at the same time.

bug 387480
(In reply to comment #107)
> (From update of attachment 281161 [details] [diff] [review])
> Why wouldn't you just remove the badCertListener from xpinstall like you did
> elsewhere? There are two cases in XPInstall: if "chrome" is doing the install
> (extension update or plugin finder, for example) then we wanted to suppress the
> dialogs. If the user entered the URL in the address bar then we wanted it to
> work "like the web". But if normal surfing doesn't get dialogs anymore then I
> don't need a badcertlistener2 to supress them, right?

It's a bit more complicated.

It's correct to say "normal surfing will no longer display error dialogs for bad certs".
This is because we are introducing error pages.

But displaying an error page only works when an SSL connection happens in the context of a browser window / docshell, that provides the error page capability.

For all other contexts, like SSL mail connections, xmlhttprequests started from chrome, a different mechanism is used to communicate connection errors to the user: An error dialog.

We have a new single error dialog that will displayed for any SSL connection errors outside of a browser window. The dialog will explain the error with a localized error message and a always-english-error-identifier. The dialog will not allow to "click through", it will be a "hard failure" notification message.

So, if application code like xpinstall runs into a SSL connection failure, you will get an error message by default. If you want to suppress that, you can provide a context object that overrides the new nsIBadCertListener2 interface, which will receive a callback upon a bad cert error, with the ability to stop PSM from bringing up the error dialog.

Comment on attachment 281800 [details] [diff] [review]
Patch v7

r+ Assuming function overloading in this context is acceptable in mozilla.

bob
Attachment #281800 - Flags: review?(rrelyea) → review+
(In reply to comment #111)
> r+ Assuming function overloading in this context is acceptable in mozilla.

Yes, we're in C++ code, so overloading functions with different arguments is allowed.


Adding a dependency to bug 397296, because the patch in this bug requires the rather new function SEC_StringToOID. However, I might temporarily add a static renamed copy of that function to my PSM check in, so we aren't blocked in landing this one. If I do, I'll revert it once we get the new tag.
Depends on: 397296
This is the patch I checked in today.
It combines the two reviewed patches attached to this bug.
It also has the bustage fix for camino (top of patch).
It contains a copy of a NSS function that has not yet landed, will be removed soon. (for justification see comment in file mozilla/security/manager/ssl/src/nsCertOverrideService.cpp )
I adjusted the merge conflict that resulted from the recent landing of the cert export functionality.
marking fixed
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9
Depends on: 398534
This took me several minutes to figure out given the state of our security prefs UI (you achieved your goal!):

To add an exception (domain mismatch in my case): Tools -> Options -> Advanced -> Encryption -> View Certificates -> Servers -> Add exception. Paste the URL of a page from the offending site, click through the warning.

(In reply to comment #115)
> To add an exception (domain mismatch in my case): Tools -> Options -> Advanced
> -> Encryption -> View Certificates -> Servers -> Add exception. Paste the URL
> of a page from the offending site, click through the warning.

Thanks, I can now again access my work email. I am not so sure that the average user will find this in the options though. Shouldn't this error page have some sort of "i want to access this evil web page anyway, add it to the exception list" button?


If you read the discussion above, the whole idea is to make it really hard to access such sites to improve the users' security and force the administrators to fix their servers.

I do wonder if the less passionate users will just switch to other browsers. Hopefully people that absolutely have to access improperly configured servers will be smart enough to google the instructions (there aren't any at the time, but that's because the change just went in).

I work with security appliances that are access with SSL over SSH tunnels which means that all URL's look like https://127.0.0.1:<per device tunnel port>/ which means this will be a major pain adding 100+ certificates using the new UI.
Is there a way to wildcard the host:port in cert_override.txt ?
(In reply to comment #118)
> I work with security appliances that are access with SSL over SSH tunnels which
> means that all URL's look like https://127.0.0.1:<per device tunnel port>/
> which means this will be a major pain adding 100+ certificates using the new
> UI.
> Is there a way to wildcard the host:port in cert_override.txt ?

A wildcard is not currently possible. Are all your applicances use the same cert? Then you could duplicate the lines in cert_override.txt and change the port number (you should modify the file while the application is not running).

I see another problem with using host:port as the key, most home router appliances have the address of 192.168.1.1 and if you switch between two networks with different certificates it's not possible to have both in the exception list or am I wrong ? In my case most of them have the same certificate but the ports of the tunnels are sometimes reused between different devices with different certificates (this can of course be worked around by modifying my ~/.ssh/config).
(In reply to comment #120)
> I see another problem with using host:port as the key, most home router
> appliances have the address of 192.168.1.1 and if you switch between two
> networks with different certificates it's not possible to have both in the
> exception list or am I wrong ?

Correct. Only one entry per host:port or ip:port


> In my case most of them have the same
> certificate but the ports of the tunnels are sometimes reused between different
> devices with different certificates (this can of course be worked around by
> modifying my ~/.ssh/config).

Yes, you could also have dummy entries in your /etc/hosts file (or other OS equivalent) where you place dummy hostnames for your individual decvices, like
  mydevice-1 127.0.0.1
  mydevice-2 127.0.0.1
Then the stored overrides could be bound to those dummy hostnames, even if you're using the same port.

(In reply to comment #121)
> (In reply to comment #120)
> > I see another problem with using host:port as the key, most home router
> > appliances have the address of 192.168.1.1 and if you switch between two
> > networks with different certificates it's not possible to have both in the
> > exception list or am I wrong ?
> 
> Correct. Only one entry per host:port or ip:port


If you are using a laptop that you're carrying with you and visiting different home networks, you can use the /etc/hosts trick there, too.

  my-apartment-in-new-york 192.168.1.1
  my-apartment-in-london   192.168.1.1

Instead of using https://192.168.1.1
you'll use
  https://my-apartment-in-new-york
or
  https://my-apartment-in-london

That way you can add individual overrides for the same IP, same port, with different certs.

Folk with some network skill can figure that out, John Doe that moves between his home and his girlfriends apartment might not. How about making this less strict for RFC1918 networks or what would the the risk by doing that ?
(In reply to comment #123)
> Folk with some network skill can figure that out, John Doe that moves between
> his home and his girlfriends apartment might not. How about making this less
> strict for RFC1918 networks or what would the the risk by doing that ?

First off, I agree with the fact that people without appropriate network sophistication will have trouble with this, and that we need to think about providing, if not instructions, at least explanations in a clearer fashion.  I intend to file a follow-up bug about that.

Giving preferential treatment to RFC1918 networks is something I thought about too, but consider:  The reason we're doing this is to respond to the gross vulnerability of the old system ("click okay to make this dialog go away and trust the untrusted cert") to man in the middle attacks.

The concern is that a user on, for instance, coffee shop wireless clicks their web banking bookmark, and is MiTM'd.  The rogue AP is diverting https://www.bank.com to a server they operate in order to steal credentials or otherwise exploit trust.  In such a case, using an RFC1918 class address is absolutely something the attacker could do - indeed, the server is *likely* to be running on the same machine as the rogue AP.

Simson Garfinkel talks about key continuity management (e.g. http://www.truststc.org/pubs/5/johnny2_talk.pdf ) as a way to approach this too - saying that rather than shut down self-signed certs completely in cases where CA-verified identity doesn't matter, we should just remember the certs we see, let the traffic flow, and only make noise when the cert CHANGES, since that is the specific hallmark of a MitM attack.  However, in a situation where an individual is moving between, and administering, multiple routers that use the same IP address but different, non-trusted certs, this won't help either, as I understand it. 
(In reply to comment #124)
> Giving preferential treatment to RFC1918 networks is something I thought about
> too, ...
> 
> The concern is that a user on, for instance, coffee shop wireless clicks their
> web banking bookmark, and is MiTM'd. ...


Also, you could be in a corporate network, and the network admin might try to steal your paypal password.


> Simson Garfinkel talks about key continuity management ...
> let the traffic flow, and only make noise when the cert CHANGES

I think it is necessary to block bad certs on first sight, too.

Say you're getting a phishing email, with a link to a fake site that looks like paypal.

We have no choice to detect the site is supposed to fake a site you have visited before, and therefore can't do a cert comparison with the known real papyal cert. If we don't block the cert on first visit, the attacker succeeds.

(In reply to comment #118)
> I work with security appliances that are access with SSL over SSH tunnels which
> means that all URL's look like https://127.0.0.1:<per device tunnel port>/
> which means this will be a major pain adding 100+ certificates using the new
> UI.
> Is there a way to wildcard the host:port in cert_override.txt ?

I think it would be safe for Firefox to allow https connections to 127.0.0.1 (at least ones where the IP address is in the URL, rather than a hostname).  Kinda hard to MITM those :)
(In reply to comment #125)
> (In reply to comment #124)
> > Simson Garfinkel talks about key continuity management ...
> > let the traffic flow, and only make noise when the cert CHANGES
> 
> I think it is necessary to block bad certs on first sight, too.
> 
> Say you're getting a phishing email, with a link to a fake site that looks like
> paypal.
> 
> We have no choice to detect the site is supposed to fake a site you have
> visited before, and therefore can't do a cert comparison with the known real
> papyal cert. If we don't block the cert on first visit, the attacker succeeds.

I think we should be careful here - this change is an important one for
preventing things like MitM, and more generally for changing our default user
education around "granting things trust is the default option" but I wouldn't
want to go too far down a path of treating it as a fix for email-based phishing
attacks.

I agree that the attack you describe would be thwarted, but the APWG says the
number of phishing attacks using SSL is still quite small - I think whether we
do things this way or not (particularly so if we block on first contact, of
course) most phishers will not bother with SSL at all unless they perceive some
payoff there, and hence that the need to block those attacks is secondary. 
Though, of course, this is subject to change.

Since this bug is closed and has a large CC list, I've opened two follow-ups:

 - bug 398718 to track suggestions for making the error page more
explanatory/human readable.
 - bug 398721 to track the idea of using KCM in PSM 

> Also, you could be in a corporate network, and the network admin might try to
> steal your paypal password.

On a corporate network a malicious admin can populate the cert_overrides.txt file on your corporate workstation with whatever he likes, if he has control over your DNS or the corporate HTTP proxy the attack is possible even with todays implementation. There are many other ways your network/workstation admin can attack you. The "no malicious administrator" assumption is just that, an assumption.

I have visited a lot of corporate intranets that use certificates from a self-signed CA where the CA certificate can be obtained from a SSL site with uses a certificate signed by said CA, this makes it kind of catch-22.
(In reply to comment #126)
> I think it would be safe for Firefox to allow https connections to 127.0.0.1
> (at least ones where the IP address is in the URL, rather than a hostname). 
> Kinda hard to MITM those :)


If we do this, a phisher could say:

  "Download and click this program ...
    (which is a shell script that starts ssh to open a port on 127.0.0.1
     with a tunnel-forwarding-ssl-connection)

  ... then you will be able to access your bank account again..."

I'm not sure if this is sufficient justification against your proposal.
If you still think we should do this, we might want to open a separate bug for discussion.

(In reply to comment #128)
> On a corporate network a malicious admin can populate the cert_overrides.txt
> file on your corporate workstation with whatever he likes, if he has control
> over your DNS or the corporate HTTP proxy the attack is possible even with
> todays implementation. There are many other ways your network/workstation admin
> can attack you. The "no malicious administrator" assumption is just that, an
> assumption.


Ok, Johnathan's example of roaming in an wireless hotspot is better (where the hostspot provider does not have physical access to your laptop, but you are still forced to go through that foreign network.)

I propose we move the discussion to a separate bug report that combines the proposals around RFC1918 addresses and 127.0.0.1

(In reply to comment #129)
> If we do this, a phisher could say:
> 
>   "Download and click this program ...
>     (which is a shell script that starts ssh to open a port on 127.0.0.1
>      with a tunnel-forwarding-ssl-connection)
> 
>   ... then you will be able to access your bank account again..."
> 
> I'm not sure if this is sufficient justification against your proposal.
> If you still think we should do this, we might want to open a separate bug for
> discussion.

If someone gets you to download and run arbitrary code, you are screwed in other ways.



In reply to comment 120:
> I see another problem with using host:port as the key, most home router
> appliances have the address of 192.168.1.1 and if you switch between two
> networks with different certificates it's not possible to have both in the
> exception list

There are home appliance routers that use certificates, and to which users
connect via SSL?  Please, name one!  I've never seen one.
(In reply to comment #132)
> There are home appliance routers that use certificates, and to which users
> connect via SSL?  Please, name one!  I've never seen one.

My Linksys home router has an option to "Use HTTPS administration" (disabled by default). When enabled, the web interface uses a cert that's not signed by a CA in our root store. Probably not a very common scenario, but I don't think it's as far-fetched as you make it sound.
So is there a reason the nsCertTree code doesn't use alread_AddRefed<> for the addrefed pointers it returns?  Then you wouldn't need to sprinkle getter_AddRefs all over where it's used....
I'm also a little confused as to why we're manually addreffing/releasing stuff before putting it in mDispInfo.
(In reply to comment #132)
>There are home appliance routers that use certificates, and to which users
>connect via SSL?  Please, name one!  I've never seen one.
We use something called a Safepipe. The http page is simply a form with a button "Please switch to HTTPS now by clicking the 'Continue' button." and the cert has a CN of "Safepipe Configuration Interface" so you'll always get a mismatch.
Neil, thanks for the info.
It's unfortunate to hear that product vendors are institutionalizing the
use of certs that fail validity tests.  Do they let you replace the 
initial cert with a valid one?
In answer to my own question of comment 137, yes, SafePipe does permit a 
real CA certificate to be installed as a trusted CA certificate, and enables 
a user go generate his own certificate request, send it to a CA, and get a 
real cert from a CA, and install it in the SafePipe. 

SafePipe products also have built-in CA software that permits a user to 
issue his own self-signed CA cert and then use that to issue his own 
server certs.  One SafePipe product can act as the CA  for any number of 
their products.  

It appears they can also generate self-signed server certs, with no CA 
cert involved.  

Their instructional web page http://www.eicon.com/support/helpweb/safepipe/x509.htm
only explains the use of their own built-in CA software for cert issuance, 
and does not explain how to get a cert from a real CA.  It also does not 
explain the necessity of installing the self-signed CA cert into any browsers
that wish to communicate with these products using SSL.  

So, I conclude that these products probably CAN be used with certs from 
trusted CAs, and when these products are used as CAs, they produce CA certs
that can be installed in browsers as valid CA certs.  Either of those 
methods would be preferable (IMO) to using self-signed server certs.
Depends on: 398915
Depends on: 398949
Depends on: 399019
Depends on: 399022
(In reply to comment #132)
> There are home appliance routers that use certificates, and to which users
> connect via SSL?  Please, name one!  I've never seen one.

I tested my Linksys and it does come pre-installed with a certificate.  I enabled https on it, and was able to connect after adding it as an exception.  It did *appear*, however, that all such boxes use the same cert/private key, so I don't think it adds as much security as I would have hoped.



(In reply to comment #134)
> So is there a reason the nsCertTree code doesn't use alread_AddRefed<> for the
> addrefed pointers it returns?  Then you wouldn't need to sprinkle
> getter_AddRefs all over where it's used....

(In reply to comment #135)
> I'm also a little confused as to why we're manually addreffing/releasing stuff
> before putting it in mDispInfo.

Boris, thanks a lot for your comments.
I knew it would be good to ask you! :-)
I'll address these requests in bug 399022.

(In reply to comment #139)
 
> It did *appear*, however, that all such boxes use the same cert/private key, 
> so I don't think it adds as much security as I would have hoped.

OMG!  Bob, you're being so polite.  If All those boxes use the same cert/priv 
key, then any such box, off the shelf, can masquerade for any other.  It's an
off-the-shelf MITM attack against all wireles router boxes of that brand. !!
Depends on: 364667
Solving Bug 116169 can be good for sites with one certificate and multiple hostnames.

See also http://wiki.cacert.org/wiki/VhostTaskForce
I'm a bit uneasy with this change.

+ As an internet user I'm glad that there will be more pressure on system administrators to get their TLS-setups correct.
- As a Firefox user I'm afraid that many people will switch back to less secure browsers simply to spare them the annoyance of being blocked out from a site (however badly managed). Keep in mind: Clicking that other icon on your desktop to start a different browser is *easier* than adding an exception for the site in question. Keeping the task oriented user from accessing a site with an invalid certificate would imply hindering that person from starting a different browser. I foresee a *huge* backlash upon the release of Firefox 3. If this remains in the release we need an extremely well prepared information campaign and an army of bugzilla duplicate killers.
- As someone who offers TLS as service for various websites I feel this step comes too early. I have to run all the websites from the same IP address (everything else would be cost prohibitive) and all on the same port. The OpenSSL-library didn't ship yet a stable version with TLS server name indication and once it will be released it will take some time to show up in other software/package distributions. This means I'll have to explain to my users how to add exceptions for their domains in Firefox, training them to accept the same advice more easily from phishers too.

So all in all I simply think that it is too early for this change to be made. It will cost Firefox a lot of goodwill and not necessarily make the internet a more secure place.
Depends on: 399043
No longer depends on: 398534
Depends on: 400093
Hi, just found this bug after downloading the latest nightly and couldn't access a router with a built-in certificate. My company manages over 400 of these devices, assigning each one a DNS entry under our domain for easy management. 

Judging by the comments above it's going to be suggested that 1) we should manually enter all 400 of these hostnames into the UI, or 2) we're fools who are begging to have our network brought down by hackers because we're not going through the trouble of installing a custom certificate in each of these devices. Neither of these suggestions are helpful.

I know this bug is closed, but I have 2 suggestions:

1) allow wildcard entries for domain mismatches, eg use the UI to load the cert as currently happens, but then have a box to "allow this cert to be used for sites at *.foo.com." This is a deal breaker, and our company will have to use another web browser if things don't change, because management of a list of every device over 50 users' browsers is just not feasible.

2) a simple sentence in the error page such as "if you trust this site, add it to the exception list in your preferences." Don't spell out for the user how to do so, for the valid concerns above, but do advise of the possibility.

(In reply to comment #145)
> Hi, just found this bug after downloading the latest nightly and couldn't
> access a router with a built-in certificate. My company manages over 400 of
> these devices, assigning each one a DNS entry under our domain for easy
> management. 

See bug 399275, and other bugs in this bug's dependency chain.
I've just used the latest build of minefield (2007102205) and was presented with the message below and "Try again". It's a self-signed certificate. This is a major problem IMHO:
a) It's not clear what the problem is - "The security certificate issuer (name here) is not trusted"
b) Try again? (the certificate issuer isn't going to change)
c) No way to accept (certainly none that are obvious) - what if the only way to obtain the CA certificate is to download it from the said website?  I'd be stuck
d) Many, many places have self-signed certificates - most internal sites, most appliances, even Microsoft's licensing site (which is dreadful of them I must say)

If this stays as it is without a way to allow the trust to be added easily and permanently then this will have the effect that people will use another browser.  NB: I say permanently since if the user is continuously prompt with "allow" dialog boxes then they will automatically click them instead of checking.

Secure Connection Failed

An error occurred during a connection to www.example.com:443 because it uses an invalid security certificate.
The certificate is not trusted or its issuer certificate is invalid.
 (sec_error_untrusted_issuer)     
   
    *   The page you are trying to view can not be shown because the authenticity of the received data could not be verified.

    *   Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
Another data point:

I filed https://bugs.maemo.org/show_bug.cgi?id=2153 due to some Maemo websites having certificate issues. I had to use FF2 to get more detail about exactly what was failing... For example, www.maemo.org was presenting a cert for maemo.org, and repository.maemo.org was presenting a cert for a248.e.akamai.net (!). Im FF3, the same generic error was reported for all of them.

A small, but very important, use case of these error pages will be for web admins trying to determine why Firefox 3 isn't working for users. If there isn't a good way to detail the error for everyone, adding a "More Info" or "Advanced" button or somesuch would be something to consider. 
I just wanted to say I agree with Adrian Bridgett

This is major inconvenience, many people including myself have home brewed web servers, there are internal websites, etc... that all use "untrusted" certs. I had to google to figure out how to add my site to the trusted list (w/e). This will for sure drive many user away. It makes my life harder, because I'd like to use ssl, but then if I have a few finds visit the site, they'd wouldn't even bother trying to figure out how to add it.

So I suggest some type of button (maybe give an extra warning beforehand) that will allow one to easily the cert as being trusted.
(In reply to comment #149)
[...]
> So I suggest some type of button (maybe give an extra warning beforehand) that
> will allow one to easily the cert as being trusted.
> 

IIUC, the whole purpose of this bug (and of a few others related to it) is that the Security gurus, in their infinite wisdom, have decreed that there MUST NOT be any possibility to click-through on a bad-certificate error, because it would "train" users into a "bad" conditioned reflex (i.e., clicking through a bad-cert error without reading), which, in turn, would open the way to all sorts of phishing (and similar) attacks. The bad-cert error page MUST be a dead end; there shall be a way to circumvent it, maybe even a "discoverable" one, but not easily. If this annoys the users, so much the better: it will incite the webmasters to clean up their act. And if some users abandon Firefox (a "safe" browser) for IE (an "unsafe" browser) in the process, it's their funeral.

So I guess you shouldn't expect any button next to that error message. At the most (IIUC) some more or less cryptic message telling users that, elsewhere, there exists a method to work around it.

Maybe I'm being overly sarcastic, but apart from that, the above is how I understand the matter. Please correct me, O Security people, if I'm wrong.
I see the security issue of it, but if you want to support "safe browsing" it would be wise, to somehow make the process easier, maybe click have a lock with an x around it, and the user must click that in order to continue. And possible asking if you sure you want to continue to an insecure site. 

There are many people who want to have ssl (such as myself), but don't have $50-$200 to spare on ssl cert (hey that why we are running the servers out of our homes anyways)

There are many parts of my site that give https links on, and this would mean I would have to remove all of them, because my peers (no savvy computer users) would not bother to mess around with such a complicated process.

And if a small business has setup SSL on one or two LAN web servers, why would they spend a huge amount of money when a home made one can be made for free? And work just fine within the LAN.

The average user is just going to get **** of when they can't get the site thay want, they'll load up ie or whatever. They don't really know that firefox is safer than ie. Then people tell theirs friends/peers/coworkers, that firefox didn't work with XX website and its just a huge chain affect. But the big point/thing is that no matter how much you do or don't lock a user they'll just click on things without reading it. I can't tell you how many people I see just click ok on dialogs without even reading them. Users are going to be users, and they really is no point in restricting them that much.

Maybe we should mimic what IE7 does. I think IE gets the point across real well with a untrusted site. (First it gives you a screen telling you that the stie is not trusted, then it has check to bring you back to the page you came from, or it has a big red shield that says continue anyways (visually most people see the check and click on it). Also once you enter the untrusted site the url becomes read.
Please see bug 398718 which is about improving the bad certificate error page and bug 399275 which is about adding a pref which would restore the Fx 2 functionality of a per-page SSL error override.
Our Firewall has an integrated web server interface which is now inaccessible thanks to this bug. Now using IE7 to access it. 
Camino nightly builds now use this gecko engine. There is no interface at all to add exceptions or certificates. I have multiple personal secure connections that I use externally due to not being able to ssh into my home system on many hotel networks, and my work uses self-signed certs for out internal computer connections. My secure email provider no longer works as my domain is not the same as the host's domain name that the cert is issued for. Camino nightly means no access.

I am amazed this conversation about trying to convince the developers to allow a means to add in the choice to do something the user wants to do is even taking place, especially considering that there seems to have been little if any discussion on taking away that choice!

I won't use ff (many reasons), I much prefer camino, but now I must choose another browser due to this. You can take away my choice to accept these certificates, but you cannot take away my choice to use another browser. And that means no more gecko engine for me, too.
Tyler: you need to file a bug on Camino and get them to add the necessary UI. (They may wish to provide an override in the mean time.)

For everyone else: I thought that we have an override mechanism (even if it's currently a bit obscure). Isn't that the case?

Gerv

(In reply to comment #155)
[...]
> For everyone else: I thought that we have an override mechanism (even if it's
> currently a bit obscure). Isn't that the case?
> 
> Gerv
> 

IIUC, there is -- intentionally -- no path from the error message (in a popup or error page) to the override mechanism (in some Certificate Properties dialog), which makes it more than "a bit" obscure. So obscure that, fom the above comments, it seems that many users failed to find the override mechanism when they needed it and, in desperation, went back to IE. (I wonder, though: shouldn't they have gone back to Fx2 instead? Or is this bug already fixed-on-branch?)
(In reply to comment #156)
> IIUC, there is -- intentionally -- no path from the error message (in a popup
> or error page) to the override mechanism (in some Certificate Properties
> dialog), which makes it more than "a bit" obscure.

Thinking about it, I'm inclined to agree that the decision not to provide a direct link to the Add Security Exception dialog (on Windows, Tools > Options > Advanced > Encryption > View Certificates > Add Exception...) should be reconsidered. A button could be provided that opened the Certificate Manager at the Servers tab and the Add Security Exception dialog in front of it (and perhaps pre-filled the Server Location field?).

This which would mean that only five clicks would be required to actually see the site if the user is convinced that it's safe and wants to override (click on button on error page, Get Certificate, Confirm Security Exception, OK and then Reload); rather than up to 12 (!) steps at the moment. Also, I think that the text warning ("You are about to override how Firefox identifies sites. Legitimate banks, stores, and other public sites will not ask you to do this.") and yellow caution triangle on the Add Security Exception dialog are probably enough to warn casual users from adding an exception unless they're absolutely sure the site is safe. As a side-benefit, this approach would let admins and anybody else who's interested to actually see the invalid certificate in question; this is not easy at the moment (you have to get to the Add Security Exception dialog, type or paste in the address, click Get Certificate and then click View).

> So obscure that, fom the above comments, it seems that many users failed to
> find the override mechanism when they needed it and, in desperation, went
> back to IE.

I did also propose a middle-ground solution (bug 398718 comment 40) of "a direct link on the error page to a KB article on SUMO which would clearly illustrate how to add a security exception (and how to enable the pref to restore the per-page override option, if bug 399275 gets implemented)?"

> (I wonder, though: shouldn't they have gone back to Fx2 instead? Or is this
> bug already fixed-on-branch?)

This is only fixed on the trunk. The Fx 2 behavior hasn't changed.
See attachment 286643 [details] on bug 398718 for a mockup of the proposal I posted in comment 157 above (and slightly modified in bug 398718 comment 45).

Also potentially of interest: bug 401575.
(In reply to comment #154)
> Camino nightly builds now use this gecko engine. There is no interface at all
> to add exceptions or certificates. 

(In reply to comment #155)
> Tyler: you need to file a bug on Camino and get them to add the necessary UI.


Bug 398417 already filed.
Depends on: 402477
Blocks: 401575
Depends on: 403219
Much say I just compiled and the error message is much better! Thanks for changing it!
Just testing FF3b1: the new PSM is great. The exceptions dialog makes it IMHO the best cert manager compared to other browsers. But ... bug #159483 is still not solved with it.

There will come the day when one of the trusted CAs (or one of their sub-sub-intermediates) lets slip through a "subjectAltName=*", and then we're all toasted.
I can think of a significant drawback to the new SSL error page.  I use various Department of Defense websites for the US Army, and all use self-signed certificates.  There are times when it is not possible to install the DoD certificate package, and this would require adding exceptions in the tens just to login and use a couple of sites.

I propose that a link be added to the error page that allows the request to go through, as IE7 features.

In addition, could the DoD be added to the Mozilla shipped CAs?
(In reply to comment #164)
See Bug 208323.
I suspect there are some special cells in Leavenworth reserved for DoD 
sysops who use self-signed certs on official DoD sites.
Flags: wanted1.8.1.x-
nsIBadCertListener2.idl has documentation for "@param cert" which does not exist.
Comment on attachment 212595 [details]
Detailed information on what failed

just cleaning up reviews ..
Attachment #212595 - Flags: ui-review?(beltzner)
Attachment #212595 - Flags: ui-review-
Attachment #212595 - Flags: review?(johnath)
this caused regression bug 415786 because of an accidental string removal.
Blocks: 415786
I find this change is quite the opposite of improvement for me. I do not need to provide justification why I would want to visit a site with a self-signed certificate. All that this change has done is caused me to search for hours for a way to get past the message. I found it, buried 8 clicks deep -- impressive, isn't it? Did some user actually ask for this functionality, or what prompted the developers to want to hold my hand and tell me what I do not want to do? Did someone ask - please make this harder for me, I am not competent enough to take decisions myself. Is the Gnome disease spreading here too?
Depends on: 423247
(In reply to comment #167)
> nsIBadCertListener2.idl has documentation for "@param cert" which does not
> exist.

Patch to fix this the documentation.
Attachment #311866 - Flags: review?(rrelyea)
I am very unhappy at the way FF3 deals with this issue currently (I just compiled from CVS to look for sure). The way Intranets/Extranets/Friendnets are cast into realms of evil borderline ways to use the Internet isn't very uplifting.

Some ideas. One is, revive fingerprints! This idea that noone is tech-savvy enough to handle fingerprints is insulting your users. If I hand out a physical piece of paper to all of my employees with a fingerprint on it, and tell them to absolutely make sure it is correct before selecting that "I swear I have checked that fingerprint" button, then they will do so. Even my mother would do so. If it's feasible and doesn't require a thousand "View Details" clicks, we're in business. So when CA-based certification fails, what about an "Authenticate by fingerprint" button? Why not display the technical details immediately?

I'd like to have full fingerprint authentication support for both CAs and single certificates. If you don't agree with me, make it a pref at least, so I can tell them what to change in about:config.

Another thing is, there are far too many CAs and sub-CAs that each one of us is supposed to trust. I'd like a pref that lets me consciously decide to accept a new certificate EVEN WHEN it is signed by a proper authority. When a certificate is replaced by a new one, I'd like to see the two in comparison. I understand this means keeping a certificate store of all certificates a user has seen. I would gladly invest the hard disk space for an enhanced knowledge of when, were and how certificates are changing.

I'll be hopefully looking out for cvs diffs!  :D

I just played around with base64 encoding of fingerprint. Makes it easier to recognize. The less tedious, the more users are willing to pay attention. Additionally the awareness for security issues appears to me to be growing. Everyone I know is willing to invest a little into making his/her net experience safer. If that means comparing my bank's fingerprint code with a brochure, we'll do that, additionally to trusting one out of hundreds of CAs.

I also wondered if one could come up with a graphical/color encoding of a fingerprint the certificate data itself. Something that the human brain finds a lot easier to store and compare.

And finally the user should still have the option of just "using" some website after acknowledging, that its identity is not authenticated. Sometimes it's just completely unimportant.

Like.. okay, it's not safe. You told me, thanks, now let me take a peek. I promise I won't use my credit card here.


Hi Carlo,

I really appreciate you trying to be constructive with alternatives here, instead of just coming in and saying "this sucks."  This bug is closed though, and has a long list of people who were watching the original, but may or may not be interested in the follow-on discussions.

I would therefore encourage you to open new bugs for individual ideas you have about improving things.  They might not all get done, but at least they will be individually tracked, discussed, and evaluated that way.
(In reply to comment #173)
> ...
> And finally the user should still have the option of just "using" some website
> after acknowledging, that its identity is not authenticated. Sometimes it's
> just completely unimportant.
> 
> Like.. okay, it's not safe. You told me, thanks, now let me take a peek. I
> promise I won't use my credit card here.

Apologies for the bugspam, but just to clarify, when you run into a certificate error you *do* still have the option of "just using" the website by adding an exception.

And if you choose to set the about:config pref browser.ssl_override_behavior to 2, then it is only 3 more clicks to see the website after you have run into the certificate error (granted, it's 4 if you choose to make it only a temporary exception).
Comment on attachment 311866 [details] [diff] [review]
fix IDL comment [checked in]

r+ rrelyea
Attachment #311866 - Flags: review?(rrelyea) → review+
Attachment #311866 - Flags: approval1.9?
Comment on attachment 311866 [details] [diff] [review]
fix IDL comment [checked in]

a1.9=beltzner
Attachment #311866 - Flags: approval1.9? → approval1.9+
Attachment #311866 - Attachment description: fix IDL comment → fix IDL comment [checked in]
Sorry to comment on a closed bug, but I'm still seeing the occasional modal dialog -- on top of the new XUL error page.
------
Alert

www.example.com:443 uses an invalid security certificate.

The certificate is only valid for <a id="cert_domain_link" title="www.example2.com">www.example2.com</a>

(Error code: ssl_error_bad_cert_domain)
------
I've seen it probably 2 or 3 times over the last couple of weeks; I visit dozens of these sites a day, and with cert_override.txt getting overwritten with every nightly update I often don't get to skip the warnings. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051504 Minefield/3.0pre
(In reply to comment #178)
> Sorry to comment on a closed bug, but I'm still seeing the occasional modal
> dialog -- on top of the new XUL error page.
> ------
> Alert
> 
> www.example.com:443 uses an invalid security certificate.
> 
> The certificate is only valid for <a id="cert_domain_link"
> title="www.example2.com">www.example2.com</a>
> 
> (Error code: ssl_error_bad_cert_domain)
> ------
> I've seen it probably 2 or 3 times over the last couple of weeks; I visit
> dozens of these sites a day, and with cert_override.txt getting overwritten
> with every nightly update I often don't get to skip the warnings. Mozilla/5.0
> (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051504
> Minefield/3.0pre

This is bug 431712
Test case added for the overall look and feel of the error page.
https://litmus.mozilla.org/show_test.cgi?id=7742
URL: https://litmus.mozilla.org/show_test....
Flags: in-litmus? → in-litmus+
Blocks: 94972
Blocks: 268975
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: