Closed Bug 345007 (bad-cert-ui) Opened 18 years ago Closed 16 years ago

PSM bad cert overrides - radical new proposal

Categories

(Core :: Security: PSM, enhancement)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: nelson, Assigned: KaiE)

References

Details

(Whiteboard: [sg:want] fixed as part of bug 327181)

Attachments

(2 obsolete files)

NOBODY is happy with the current state of bad cert overrides in moz products. In this RFE, I propose a radical new change to all that. It would be mostly in PSM, and perhaps also in NSS. First a review of the issues: 1. There are two cert override dialogs. One for certs whose validity cannot be determined (e.g. incomplete chain, unrecognized issuer, etc.) and one for mismatches between the desired host name and the cert's host name. 2. If the cert fails its validity check, we prompt the user to decide on an override. That dialog gives the user the impression that he is making a decisino about the web site, and is making a change to the behavior of the web site. But that is not what the override does at all. The override changes the behavior of the CERT. It marks the cert as being true and correct in all its fields. This potentially impacts many sites, all those named in the cert. (And note that the dialog does not show all those names to the user before asking for a decision. bug 308244). So today, the user cannot override the cert and make it valid for ONE site without making it valid for ALL sites it names. And this override may not necessarily help the desired web site AT ALL, since the desired web site may not be one of those named in the cert. That is why the user can still get a cert name mismatch error after overriding the cert validity errors. 3. When the user overrides a cert name mismatch error, the name of the current site's DNS name is added to the list of names associated with the cert, as if the name had been part of the cert all along. But this adjunct list of added DNS names is only transitory, not permanent, so users must (re)do the name mismatch override(s) every time they restart the browser. 4. Today there is an extension for FF/TB that overrides ALL cert name mismatches. Call it the MITM extension. :-/ 5. In bug 228684 comment 91, Scott MacGregor proposes to create a list of DNS names for which the cert name mismatch is always ignored(!). Call it the MITM vulnerable sites list. IOW, if we don't fix this right, someone else will fix it wrong. So, Here is my radical new proposal. We will find a way to permanently store (in cert DB) the list of DNS names (and perhaps email addresses also) that the user has chosen to associated with an SSL cert. (I propose this be stored in the same format as a cert's subjectAltNames extension.) Call this the "override names list". We will change the cert validation and host name matching algorithm by adding one new step before the other two existing steps. The 3 steps will then be: 1. (new step) check to see if the desired host name (or email address) is in the list of names attached to the cert (the set of "override names"). If so, skip steps 2 and 3, and treat the cert as valid and as having a matching name. Else proceed to step 2. 2. (old step) check the cert (chain) for validity for a particular usage (just as we do today). If it fails, bail out, else continue with step 3. 3. (old step) check the cert for a name match, that is, that the desired host name or email address is found in the cert's list of subject (alt) names just as we do today. Any failure of steps 2 or 3 lead to a single bad cert dialog (no more separate dialogs for invalid cert vs name mismatch.) If the user chooses to override, then we do not set any "trust" flags on the cert, but rather we add the desired host name (from the present URL) or the desired email address (from current email) to the list of "override names", and nothing more. I believe this proposal would fix/solve the bugs whose numbers appear above. It *might* also address bug 340198.
An alternate idea would be to go the other way and be much more strict, at least on validity errors. In other words, if a cert has a validity problem, don't tell the user but just write an error to the error console and show the website as an HTTP site. Site admins would see the problem and fix it soon enough. As for cert name mismatches, Necko is currently learning about the structure of the DNS (see bug 342314). That means that perhaps we could outright reject certificates with a "serious" mismatch - e.g. using a cert for www.foo.com on the site www.bar.com - while putting up a dialog for "minor" mismatches, e.g. using fred.foo.com on wilma.foo.com. Gerv
I agree something needs to be done. Nelson, I need to add, one more warning dialog is the "cert expired" situation, so instead of 2 we actually have even 3 different warning dialogs. The situation will soon become more complicated. We are planning to enable OCSP by default. This introduces new failure reasons. The OCSP server could be down, but we already know, users want the ability to continue anyway. I agree that combining the separate warnings into one dialog is better than what we currently have. It reduces the amount of confirmation clicks. And the single dialog that informs about problems could warn about OCSP problems, too. I also agree, if we continue to show a warning dialog, because we want to give the user the chance to cancel, we need the ability to override. Even a single combined dialog that appears repeatedly feels annoying to some users. On first sight, the idea to store an override list, where an "override=yes" is tied to a unique "cert-fingerprint+hostname" is a reasonable approach. But as soon as we introduce "override and remember" lists, the users need to be able to revert their decision. Look at cookies or blocked images. For both the application has UI that allows to manage the user's decisions. I believe a new override list would have to come with a new UI to manage it. I would like to avoid that new UI and the override list. I had already started to work on such a combined error dialog. But now that I read Gerv's proposal I have to say, I would like to make a new proposal, based on this idea. Either a site is secure or it is not. It is secure, if it passes ALL checks. If any check fails, it is not secure. Gerv's proposal is to display a site as "plain http", as soon as ANY check fails. Well, we'd still display the https:// URL in the url bar, because that is the protocol in use. But the idea is probably, do NOT show a secure lock icon. Do NOT change the background color of the url bar to "secure yellow". I think this is a good idea. In addition, we should display some red alert icon in the status bar. Luckily, we already have such an icon available! We currently have the concept of "mixed or broken security". That is, if the content of a web site gets partially loaded from insecure sites, we display such a broken lock icon with some red warning color. I feel this would be a perfect fit for indicating problems with the site's cert, too. Even for OCSP failures, when enabled. This all brings me to the details of a new proposal. I will describe it in the following comment.
======================================================== The "minimal prompts" and "avoid override list" proposal ======================================================== - Remove the "cert expired", "cert not trusted" and "domain mismatch" dialogs, with all their details. - Introduce a new, single cert warning dialog, that displays a very short warning message: You are attempting a secure connection to HOSTNAME but its identity can not be verified. Security on this connection is broken. Do you want to connect anyway? [ ] Do not show this warning in the future. [View Details] [OK] [Cancel] - This new single error dialog offers a button "show details", that can display all additional problems with the cert. Expired, Untrusted, Mismatch, OCSP failure, OCSP revoked. - We offer a checkbox for "warn in the future". Either a user wants warnings, or the user does not want them. This new dialog would behave exactly like our other "entering secure site", "leaving secure site" dialogs. Neither do those warnings currently use a site based override list. - The checkbox in this single combined warning dialog would be connected to a check box in preferences. Firefox 2 has Edit/Preferences/Security/WarningMessages. On that page, we'd have a new checkbox "Show a warning dialog when: I am connecting to a secure site whose identity can not be verified. - When connecting to a site after a "connect anyway" decision, if there is any probem with the site, display the "broken security" lock icon, that includes some red warning color. Do NOT use the "secure yellow" background color in the url bar, even though it says "https". - At any time the user is able to learn about the site' failure. Accesing "page info" or a click on the broken lock icon will display the details of the failure. (This is the same information shown in the waning dialog, when enabled). This will list all the failures that have occurred with the site and triggered the decision to display the broken icon. It will list expiry, mismatch, cert untrusted, OCSP revocation or OCSP server connectivity failures, or the "mixed content" information. If the cert error occurred wih some SUB content (not on the host name shown in URL bar) the page will list the hostname the error was encountered with. The page info will offer to view the certificate of the main hostname (shown in URL bar), and possibly the additional cert used for sub content that triggered the error. With the above approach, I believe it is not necessary to maintain a permament override list on disk. If a user is annoyed, he will turn off the warnings, and still will always be aware of the problem, because of the broken lock icon and the missing url bar color.
Alias: bad-cert-ui
While the previous proposal makes sense for the browser window, where we always have UI to show details about the server connection, I realize we need a solution for other protocols, too. With browser/http the user usually goes to some start page first, that displays UI. The user has a chance to notice the broken icon, even when the warnings are turned off, before entering passwords in a login form. With mail (thunderbird), there is no such feedback UI in the window, and if the warning has been disabled, the application will immediately send the password over the wire. Mail users will be tempted to turn off warnings completely, if that is the only thing we offer. Did I just find an argument why the host based override list would still make sense?
I really like Kai's ideas - although we should perhaps use a yellow info bar rather than a dialog. However, a bug is not the best place to design new security UI, even with the distinguished CC list we have here. Kai: would you care to write up your idea, together with any unresolved issues, and post to the usability and security newsgroups? Gerv
At this stage these are just my personal thinking. I would like to reach a level of agreement within this group before going public. I would like to make sure the road we go is equally appropriate for all protocols. I'm not yet sure the proposal is appropriate for mail.
If we get rid of the dialogs, we need to make sure cookies / passwords / JavaScript privileges are not mixed between "successful https" and "broken https". Otherwise a MITM attacker could easily steal a saved bugzilla.mozilla.org password, for example, with no user interaction on the user's part other than visiting some random http site.
My brainstorming has been too enthusiastic and I would like to take my proposal back. The proposal from comment 3 makes it too easy for users to turn all protection off. In addition I can not come up with a good idea to make the protocols other than https work well without warning dialogs. Jesse also has a point. If a user previously had visited a secure site, and it suddenly no longer is, it is a bad idea to blindly send out cookies. This isn't a problem with sites that never had been secure, but have always been using some broken cert. So, I'm taking my proposal back. Although it is more work - we probably need to go the road of an override list.
I am strongly opposed to "solutions" that go ahead and show the insecure site's contents to the user while asking the user to decide whether or not to override (or instead of asking the user to make any such decision). Any such design will utterly fail to combat phishing. Anytime the user is being phished, he (thinks he) really strongly wants to get to that content. Showing him that content only reinforces his desire to get to that content. If he can see the content he (thinks he) wants, he will dismiss any mere dialog to get to it. He will ignore any missing lock icons, any yellow or red URL bars, and any thin strips along the top or bottom of the browser window, and will focus exclusively on the content he seeks. I have come to believe that we need two separate solutions, one for browsers (where the user doesn't "configure" the server he's reaching, in any sense) and another for email clients, ldap clients and other forms of client that are expressly configured to know about their servers. For the latter, I think it is reasonable for the user to configure the client to know about a cert (that cannot be validated) to (nonetheless) be trusted for that server. The client's configuration for the server can easily include a (SHA1, say) hash of the cert that the user has chosen for that server. This can all be handled in the server configuration in user preferences. For the browser, I believe the only UI solution that will have any impact on phishing is the one proposed in bug 327181 . (Please look at that proposal now before reading further). Note that that proposal stops a phished user cold. He doesn't get an immediate choice of overriding the error. And most importantly, he isn't shown the content from the phisher's site that would reinforce his desire to proceed to be further phished. An implication of that approach is that there must be some other way for users who have legitimate (?) needs to override bad https certs to do what they must. To be effective against phishing, that method must be done in some part of the UI that is not typically visited in the due course of surfing (of being phished), such as in preferences. Since writing comment 0, I've concluded that it doesn't need to be NSS's responsibility to maintain lists of host names for which the user has decided to accept a unvalidatable cert, and their corresponding certs, or hashes thereof. That can quite legitimately be the responsiblity of the application, and each application may want to do it differently. So I am inclined to withdraw the proposal of storing those certs (or cert hashes) in NSS's cert DB. As I wrote above, where server configuration is involved, the cert (hash) may want to be stored as a preference string in the prefs.js file (or wherever it's currently in vogue to store preference strings). For browsers, it can be somewhere else, if that makes sense. NSS already provides the hooks by which the application can intercept the handling of the bad cert, and decide whether or not to override it. PSM already makes use of (some of) those hooks, IINM. Perhaps PSM needs to simply provide a way for the application to get involved there, too (and perhaps it already does).
I agree with Nelson that bug 327181 is the right solution. But again, I would say that if people have proposals, it's much easier if they write them up as a wiki page than trying to piece them together from bug comments, comments on the comments and modifications of the comments on the comments. Gerv
Attached patch Patch v1 for discussion (obsolete) — — Splinter Review
My latest thinking is: - Instead of a radical change at once, I propose we improve things in steps, incrementally. I suspect it is a good idea, because we can get feedback on changes while we go. - (As already said, I no longer support my ealier radical proposals in this bug. If the content is not secure, we should not show it. We should bring up an error first.) - I agree the UI proposed in bug 327181 is a good idea. But is a solution for the browser only. We still need to work on improving the certificate warnings for all the other SSL protocols. - I propose we improve the certificate warnings first, so we have a better solution for all protocols. Then we can do bug 327181 in a following step. - The attached patch is a proposal for a first step in improving the Bad Cert Overrides. It combines the warnings Untrusted + Expired + Domain Mismatch in a single dialog. The single dialog has multiple appearances, depending on the errors that happen to occur. More details to follow in the next comment. - This patch I'm proposing as a first step - it also provides backend functionality that is necessary to implement something like bug 327181, as it provides the ability to collect information about all cert errors at once. And to store a list of cert overrides.
Nelson, you told me: In your opinion, when a cert error occurs, the application should not allow the user to immediately override the cert error. It should be harder. I can agree on this in general, but we need to find a proper UI for that. I agree, a solution like in bug 327181 is a good idea, where the user is presented with an error page telling "you can not connect" and proving some new ability to override that error - either by following your proposal to have the user go to the prefs and enter an override there (which would be very difficult to do for end users) - or like inventing a new status bar control UI, and a user can click and allow to override (like it is currently in place for allowing pop up window overrides). Fact is: As of today, at the time we show a certificate error, end users are already able to immediately override the cert error. The patch I am proposing as a first step does not change that. I agree we can try to make it harder to override in a following step.
I'd like to quote a couple paragraphs from Peter De Silva: > it violates two fundamental princples of secure application design. > > 1. Approval dialogs are not a security mechanism. No matter how fancy they > are, an application must not ask a user "I'm about to do something that > might be dangerous... should I do it"? > > 2. Untrusted objects must never be given a mechanism to request trust. The > operation of granting trust to an object must be initiated by the user > outside the user interface created by the untrusted object. Both of these points are relevant to the receipt of bad certs. The objective is not to make it "harder", but rather to make the giving of trust to an untrusted object (a bad cert) be directly user initiated, not a consequence of an separate action (trying to fetch a web page). It should not be done in the context of "is it OK for me to do this bad thing now?", but as an act of configuration. The user should be saying "Here is a cert I have. I choose to trust it as if it was created by a real CA that I trust."
Let me provide some screen shots before I explain more. Status Quo, these are screenshots of our 3 separate bad cert warnings of the current trunk, which each allow the user to continue despite the problem: http://kuix.de/mozilla/certwarndiscussion/trunk200610/ I came up with a dynamic dialog that combines reporting all 3 problems at once: http://kuix.de/mozilla/certwarndiscussion/proposal20061016/new5.png This is actually a dynamic dialog, which can have 7 different represenatations - depending on the combinations of errors. To see all 7 variations, each with a test case, see: http://kuix.de/mozilla/certwarndiscussion/proposal20061016/ The patch I'm attaching does more than just combining the dialogs. It would introduce a restriction: A permanent override for a certificate will be restricted to the presented hostname. Not for others. It would introduce the new ability to permanently override domain mismatch and cert expired warnings.
Attachment #242416 - Attachment is obsolete: true
Depends on: 356309
(In reply to comment #14) > I'd like to quote a couple paragraphs from Peter De Silva: > > > it violates two fundamental princples of secure application design. > > > > 1. Approval dialogs are not a security mechanism. No matter how fancy they > > are, an application must not ask a user "I'm about to do something that > > might be dangerous... should I do it"? But this is exactly what all (major) browsers currently do. I did some tests with: - opera 9 - ie 6 - ie 7 beta on xp - konqueror When those browsers encounter any combination of untrusted/mismatch/expired, they will allow the user to continue anyway with a single click. Ok, in konqueror its two clicks, but that second click can make the override permanent. IE 6 and Opera use a combined dialog, the same thing I'm proposing for our first step to improve things. IE 7 looks more like bug 327181. But it just looks different than a dialog. It looks "more fancy" to use the words that Nelson quoted. Is it more secure? I do not think so. It still offers to continue anyway with a single click. (And that UI only works for https, not any SSL.) > > 2. Untrusted objects must never be given a mechanism to request trust. The > > operation of granting trust to an object must be initiated by the user > > outside the user interface created by the untrusted object. > > Both of these points are relevant to the receipt of bad certs. The objective > is not to make it "harder", but rather to make the giving of trust to an > untrusted object (a bad cert) be directly user initiated, not a consequence > of an separate action (trying to fetch a web page). It should not be done > in the context of "is it OK for me to do this bad thing now?", but as an > act of configuration. The user should be saying "Here is a cert I have. > I choose to trust it as if it was created by a real CA that I trust." Such a step would make it harder to visit sites using invalid certs than any other current browser I'm aware of. I do not oppose that proposal. I am ok with having a discussion what UI we could use to make it harder to "continue anyway".
Attachment #242446 - Attachment description: Patch v2 for discussion → Patch v2 for discussion (screenshots see comment 15)
Final arguments why I'm lobbying for this first step, currently attached as Patch v2: - Mozilla Firefox is currently more annoying than other browsers when it comes to "continue anyway" on certs. But it is not more secure. So let's combine the dialogs. - Mozilla Firefox *already* allows to accept bad certificates permanently "as you go", using a click on a radiobutton. The patch does not make that worse. Actually, it restricts the override to the given hostname (as Nelson had proposed to do in comment 0 in this bug). - Mozilla currently does not allow to permanently override a domain mismatch. We received a lot of complaints about that. Please see bug 228684 comment 91, which Nelson also quoted in comment 0. The attached patch implements such an ability. I believe allowing to permanently override a name mismatch is less critical than our *already* available functionality to permanently override trust. - Mozilla currently does not allow to permanently override a "cert expired" error. The patch adds that ability. But I implemented this simply for completeness. I do not insist on adding it.
> http://kuix.de/mozilla/certwarndiscussion/proposal20061016/new5.png Way too much text. Combining the "possible reasons for this error" for various errors does not work.
RE comparison with other browsers. The override idea was first introduced by Netscape. Since then other browsers have copied it. This idea was produced in 1995, when the landscape was quite different. It is now 2006, and modern phishing is having an effect. Opera at least treats overrides as insecure connections. IE imbeds the warning in the page itself. It's clear the tragectory is already away from allowing generic overrides. Today phishers do not use SSL at all, but there is slow work at making phishing harder without SSL. Overrides can squash that flat. We need to skate to where the puck will be, not where it is today (or where it was 10 years ago;). I agree that different applications have fundamentally different override requirements. For email, the user must configure his client completely at the beginning. The decision to override is made at the same time the decision to configure was made, not when the user is trying to get his email and suddenly fails. Allowing the override there and treating the connection as unsecure if the override is needed makes sense from a security standpoint.
Bob is right: we need to separate the things NSS should allow from whether a particular application should be able to invoke that ability. So NSS should probably allow server name mismatch overrides on a per-site basis, which we might expose in Firefox, but Thunderbird should certainly not pop a dialog allowing a permanent override on the second or subsequent connection! I strongly agree with Jesse that the current dialog has about ten times more text than it should do. I really want to sit down and try and put together a coherent plan for all error cases, which we can then discuss and refine, perhaps on a wiki. However, what I really need to start that is a list of all the error cases. E.g.: - Server name mismatch - Expired certificate - ... We could then have a table with those down the side, the names of the apps across the top, and discuss and decide behaviour in each case. Does anyone have or can anyone provide such a list? Gerv
Attachment #242446 - Attachment is obsolete: true
(In reply to comment #22) > List of all NSS SSL error codes: > http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslerr.h This list is too big, when looking at the context of this bug. There are "fatal protocol errors" that make it technically impossible to continue a cocncection, because the connection has reached an undefined state. Those fatal errors need to be reported and the connection stopped. But this category of errors is not the subject of this bug. (I have just completed improving error reporting for them, with patches in bug 107491, and for Firefox they will be shown as an error page.) The purpose of this particular bug is to talk about a second class of failures of the certificates with an SSL connection. (In reply to comment #21) > I really want to sit down and try and put together a coherent plan for all > error cases, which we can then discuss and refine, perhaps on a wiki. However, > what I really need to start that is a list of all the error cases. E.g.: > > - Server name mismatch > - Expired certificate > - ... As of today there are just 3 of them. - mismatch - expired / not yet valid - certificate untrusted And any combination of the above, which makes it 7 combinations. > We could then have a table with those down the side, the names of the apps > across the top, and discuss and decide behaviour in each case. There doesn't need to be a separate behaviour for each app. It's just a matter of configuration. See next comment.
Where are we today? I believe we have a new proposal that will address everybody's concerns. No more "click through dialogs" when displaying a bad cert. The connection stops, and the user gets an information message. This can be an error page in the browser. For all other protocols it will have to be a dialog. The page / dialog should explain what happened. Why the cert is bad. As there will be no way to "go ahead" we can omit any warnings from that page, allowing the wording to be terse. But we need to prepare, before we can do the above. Of course, we can not suddenly block all power users from using their favorite self signed certs, without providing an alternative mechanism. There has been the proposal: Require a "proactive" configuration of sites where a cert override is allowed. So the combined proposal is: - introduce a new configuration that allows to configure a list of "bad cert override" hosts - change our code to silently accept any bad cert on a proactively configured site. No warnings, no errors. - finally, disable the bad cert dialogs altogether. Replace them with a purely informational error page (dialog for mail) that tells them "bad cert, can not continue, inform the site administrator" I have started to implement the initial two steps. But we must have a solution for *all* apps. For all protocols. Not just Firefox and Thunderbird. There are other apps as well. Sunbird, the calendar, which could load a calendar over SSL. I believe we require an override configuration that lives in PSM and can be shared amongst all apps.
Filed bug 370804 and attached patches. I am reusing existing UI.
Kai: The Mozilla Corporation has just hired someone who will be looking at security UI in Firefox :-)) His name is Jonathan Nightingale. I like the direction you are going in comment #24, but might it make sense to wait a little until Mike Beltzner and Jonathan can look at all the issues together? Gerv
Clearing the security-sensitive flag on this RFE. Apparently it was accidentally set when I filed the RFE, which was surely not my intention.
Group: security
Whiteboard: [sg:want]
So, I think we are still in agreement to do something very close to my comment 24. I think this bug is now a duplicate of bug 327181, which has the latest detailed proposals and discussions. I reused the code from this bug and worked on a new patch, that implements error pages, and implements a backend to store overrides. I will attach the patch to bug 327181. I have not yet worked on the new UI to allow for cert override. For now I would leave that to Johnathan. In order to allow Johnathan to retrieve the cert details, even for bad certs, even if we will disallow connections to sites with bad certs by default, I've implemented the following solution (inspired by Johnathan and Gavin): The new deliberate-wizard-like-add-override dialog can use an xml-http-request to the host:port of the desired server. As of today, when this goes to a site with a bad cert, the returned data does not provide a nsISSLStatus status object. I changed that to always provide an SSLStatus with at least a cert. I hope it works and I'll ask Johnathan to test. In addition, I extended the nsISSLStatus interface to have new boolean flags to indicated expired/not-yet-valid/untrusted/domain-mismatch.
<rant> I had implemented this patch over a year ago. I think it would have been a reasonable intermediate step to the solution that we have today. While it kept the original click through (and thus wasn't yet the perfect solution), it already implemented the override service, which bound overrides to specific hostnames. If you had allowed this intermediate solution one year ago, FF 2 wouldn't have the problem reported in bug 240261. </rant> I propose that in the future we focus on immediate improvements, and not reject them for better long term visions.
This is really a duplicate of 327181, because the solution we had initially envisioned got implemented there, and a lot of code from this bug got reused over there.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
I don't think this is a dupe of 327181 just because some of this code became part of that much larger re-work. "fixed by" maybe.
Reopening as a 1.8-branch bug as a good starting point in case we want to deal with this in FF2.
Status: RESOLVED → REOPENED
Flags: wanted1.8.1.x+
Resolution: DUPLICATE → ---
Version: Trunk → 1.8 Branch
No, we're not realistically going to make this kind of change in FF2. Fixed on trunk by bug 327181
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Depends on: https-error-pages
Resolution: --- → FIXED
Whiteboard: [sg:want] → [sg:want] fixed as part of bug 327181
Version: 1.8 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: