Last Comment Bug 427293 - "Secure Connection Failed" makes it difficult to work in the web hosting industry
: "Secure Connection Failed" makes it difficult to work in the web hosting indu...
Status: RESOLVED FIXED
: dev-doc-complete
Product: Firefox
Classification: Client Software
Component: Security (show other bugs)
: Trunk
: All All
: -- enhancement with 2 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-05 15:40 PDT by Kevin Stange
Modified: 2011-01-12 12:29 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
"expert" UI for badCert error pages (1.96 KB, patch)
2008-04-24 13:11 PDT, Daniel Veditz [:dveditz]
jst: superreview+
mbeltzner: ui‑review-
mbeltzner: approval1.9-
Details | Diff | Review
same using new pref (4.80 KB, patch)
2008-05-01 16:16 PDT, Daniel Veditz [:dveditz]
dveditz: superreview+
mbeltzner: ui‑review+
mbeltzner: approval1.9+
Details | Diff | Review

Description Kevin Stange 2008-04-05 15:40:25 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

I work in the web hosting industry and when I install a web hosting control panel on a server, like cPanel, Plesk, H-Sphere, or InterWorx, the default is to use a self-signed certificate for encryption.  This provides the needed level of security for working on the system and most customers never need to buy a certificate.  The new Firefox 3 behavior means that now, rather than being able to click through to a page with up to two warning dialogs, I must now click through even more steps and actually add an exception for every single server I work on, ever.  I do this dozens of times a day and the new feature wastes a lot more of my time.

I don't necessarily advocate that this feature be removed, as it has its place for novice users, but I would like to have something I can do to either turn it off, revert to the old behavior, or create very wide exception patterns, such as all IPs in a specific range.  I can survive if the option is found only in about:config.

Reproducible: Always
Comment 1 Kevin Stange 2008-04-05 15:42:29 PDT
Alternatively, having the interstitial page have a "continue" link like IE 7's would be a suitable solution as it would actually reduce the amount of time it takes to click through.  I don't need or want permanent exceptions.
Comment 2 Matthias Versen [:Matti] 2008-04-05 15:54:57 PDT
I huess this is a wontfix
Comment 3 Omari Stephens 2008-04-06 07:06:43 PDT
I also find this to be a huge waste of time.  A dialog box or even a notification in the status bar would be fine for me.  While I realize that the Internet is becoming a more malicious place, please, please, please don't forget that there are Firefox users who don't need hand-holding.  This behavior has considerably soured my Firefox 3 experience, and I sincerely hope that you will provide some less-intrusive workaround for users who know what they're doing.

As Kevin noted, I have no need or desire to manually store exceptions for even a single site, let alone however many use self-signed certs.  If I were to do banking or shopping online, this feature would be useful.  But I don't, and it's not.  So please, let me surf the web in peace.
Comment 4 Nick Catalano 2008-04-11 18:44:18 PDT
I agree... it is amazingly annoying
Comment 5 Marjolein Katsma 2008-04-19 21:35:47 PDT
I agree there should be a way to set more global exceptions (maybe via about:config or a page deeper in the dialog) so you can enable IP rages or set up a rule to always accept a certificate for *.example.com even if it's issued for www.example.com. Indeed, not all users are novice users.

On the other hand, the way the current dialogs work is confusing, even to me as non-novice user. The first time I hit this I was going in circles: it wasn't clear from the dialog itself what to do. A novice user might conclude the site just isn't reachable any more. Dialog flow and wording need work, and it should be easier to explicitly allow access for a domain (*especially* if the mismatch is on a subdomain only).
Comment 6 Matthias Versen [:Matti] 2008-04-19 22:44:43 PDT
It should not be easy as user to just click "ok" because users will not think about that error. The security is gone with such errors, they are not secure anymore and that's the reason why the design was changed away from an easy "ok" solution.
If you don't want security then use http instead of https and do not suggest using a statusbar notification or such things.

Comment 7 Kevin Stange 2008-04-20 00:01:14 PDT
(In reply to comment #6)
> If you don't want security then use http instead of https and do not suggest
> using a statusbar notification or such things.
> 

I do, of course, want security.  I want what I'm doing to be encrypted, but I also know I can trust the self-signed certificates because I have installed the software on the system that generated them and I know that a man-in-the-middle is mostly implausible for the network environment I'm working in.  A trusted network range feature in Firefox would be more than acceptable to address my problem.

I understand the benefit for novice users, but it is an impedance to my workflow to have to take so many steps so frequently for sites I want to trust and to have no way to say, "I understand the risks, now shut up" to the browser.  I know that users of these servers I work with are going to be equally perturbed, but will have the benefit of only having to ever add one or two exceptions to regularly access their systems.

If this feature is not improved to allow some method of circumvention, I really don't think I can upgrade to Firefox 3 and have any hope to remain efficient in what I do.  I will probably have to stay back on Firefox 2 until the issue can be rectified with an extension, a patch, or something more official.  I like Firefox 3 in every other way that I've toyed with it, so I would really like to be able to upgrade when it's released.
Comment 8 Omari Stephens 2008-04-21 08:23:46 PDT
(In reply to comment #6)
> If you don't want security then use http instead of https and do not suggest
> using a statusbar notification or such things.
You say that like it's a choice that most folks can make.  In many cases, a link in a page I'm looking at will direct firefox to https://something.or.other.com/.  Having to manually remove the "s" each time is a tremendous pain in the butt, and is often not an option.  Remember that, while some people do run these servers, most of us just access them.
Comment 9 Matthias Versen [:Matti] 2008-04-21 08:44:45 PDT
If you think that a man-in-the middle attack isn't possible, then you don't need security because http is also secure in that case.
If you need security because it's dangerous then you also are affected by the man-in-the-middle attack and you want to look at the certificate to be sure that this is only the certificate error that you expected.
You have to do this one time and can import the certificate permanently.
You can also use a free certificate from http://www.cacert.org/ for all your servers and accept the CA once.

If you get this on other servers then complain about the problem. That you get such errors more and more frequently is a result of Admins don't think about what they are doing with the result that users are trained to don't think about certificate alerts and just click the alert away.


Comment 10 Kevin Stange 2008-04-21 11:22:21 PDT
I didn't say "not possible" I said "mostly implausible."  It is possible under certain conditions, though it is rare and like I said above "I don't need or want permanent exceptions" and would rather have the option to verify the cert still, with the familiar two-click approval if I feel it warrants closer review.

I would rather have the old behavior back because it still allows me to review SSL certificates on a case by case basis with fewer clicks than the system requires now or to skip reviewing them if I already know better.

The idea that a man-in-the-middle attack would even result in a prompt is a bit of a sham too, considering you can buy a single site SSL certificate for under $20 per year.  If you were expecting to make $20 out of what you stole, you could pick up any signed certificate for your man in the middle attack and completely defeat this system.  There's no reason that having a signed valid certificate chain means anything, other than that you were willing to spend a small amount of money to get another company to claim you're trustworthy.

SSL certificates I work with are generated automatically at installation and are self-signed with no certificate chains. What you are suggesting is that I spend even more time regenerating them all based on a free certificate chain, effectively reducing my productivity even further.

Since this appears to be something you feel is ridiculous to even discuss (as I do, but for the opposite reason), I've already patched my existing installation to skip the hidden "add exception" button step and to auto-load the certificate in the dialog.  Hopefully I will have the time to learn how to convert this into an extension.
Comment 11 Daniel Veditz [:dveditz] 2008-04-22 09:51:01 PDT
The UI around this is all handled in the Front-end, moving back to Firefox (though maybe should be Core given it's the general neterror page)

We added a pref to make this slightly easier, for just this case, browser.ssl_override_behavior
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/app/profile/firefox.js&rev=1.323&mark=715-719#715

Setting that to '2' will eliminate one click on the dialog, at least, by pre-fetching the cert.

The other annoyance is that you first have to click on a link to unhide the buttons, and then click on the button to get to the cert dialog. We might want to think about a pref (perhaps the same one) to reduce this annoyance, but for now you can get around this by adding the following to userContent.css

div#securityOverrideDiv a#securityOverrideLink {display: none !important;}
div#securityOverrideDiv div#securityOverrideContent {display:block !important;}

That reduces the annoyance to two clicks, one more than in previous versions of Firefox. It will also add the exception, which is actually more secure if you will ever in your life go back to that site even once.

Should we document these two workarounds for this type of power-user? I bet this is going to come up a lot and we'll want a page we can point people at. Not sure if it should be a MDC or support.mozilla.com/kb/ article (probably MDC).
Comment 12 Daniel Veditz [:dveditz] 2008-04-22 10:00:58 PDT
> There's no reason that having a signed valid
> certificate chain means anything, other than that you were willing to spend a
> small amount of money to get another company to claim you're trustworthy.

They should be requiring proof that you control that domain.

Comment 13 Daniel Veditz [:dveditz] 2008-04-22 11:03:35 PDT
Johnathan sent me a link to his addon to do something similar ("MITM Me"):
https://addons.mozilla.org/en-US/firefox/addon/6843
Comment 14 Kai Engert (:kaie) 2008-04-23 18:47:10 PDT
I have one more thing you can try.
I'm still unsure whether it's a good idea to provide this, but given that Johnath already opened pandora's box, I guess there is no longer an argument to hide it.
http://kuix.de/sslhazard/sslhazard.php

Please never spread it to uneducated or little educated end users.
Please use a separate profile for your admin work.
Even if you consider yourself a power user, please don't install such extensions into a profile that you use for surfing the web.
Comment 15 Daniel Veditz [:dveditz] 2008-04-24 13:11:51 PDT
Created attachment 317597 [details] [diff] [review]
"expert" UI for badCert error pages

My ideas in comment 11 are better built-in than requiring an extension, though if I can't get this in I suppose I will try to push the extension. Since we already have an "expert mode" pref to simplify the certificate dialog by pre-fetching the cert I figured the same pref should also simplify the error page.

The netError.xhtml page can't look at prefs directly so we have to pass in the mode. I used the cssName rather than inventing a new argument to avoid having to change signatures, but if reviewers think this is too much of a hack we can go ahead and do that.

I was originally going to actually use CSS like comment 11 since that worked well for me in my userContent.css, but that would require changing at least 6 copies of netError.css in the tree, copying the warning icon as expertBadCert_favicon.png in every theme, and then worrying that 3rd-party themes out there will miss this UI change.

Not sure who should review this, I'll start with Johnathan, but will want jst's OK on the docshell change and bsmedberg's on the neterror hack.
Comment 16 Benjamin Smedberg [:bsmedberg] 2008-04-24 13:24:22 PDT
Comment on attachment 317597 [details] [diff] [review]
"expert" UI for badCert error pages

I delegate review to people who know more than I
Comment 17 Johnathan Nightingale [:johnath] 2008-04-27 19:17:16 PDT
Comment on attachment 317597 [details] [diff] [review]
"expert" UI for badCert error pages

I sure as heck ain't no docshell peer - biesi has generally been patient with my requests for reviews to this stuff, but I'll offer a couple thoughts.

>Index: docshell/base/nsDocShell.cpp
>             if (errorClass == nsINSSErrorsService::ERROR_CLASS_BAD_CERT) {
>                 error.AssignLiteral("nssBadCert");
>+                PRInt32 style = 1;
>+                mPrefs->GetIntPref("browser.ssl_override_behavior", &style);
>+                if (style == 2) {
>+                    cssClass.AssignLiteral("expertBadCert");
>+                }
>             } else {
>                 error.AssignLiteral("nssFailure2");
>             }

I'm sure it's not the only time we've done this by a long shot - but we're introducing code in docshell that checks a firefox-only pref, which feels unseemly.  I trust that GetIntPref does a sensible thing if the pref doesn't exist?  Is there an rv we should be checking or something, if we do it this way?

The other way I see to do this is to get netError to fire off some kind of special event at the end of its init ("DOMErrorPageLoaded" or something), which could bubble up into browser (or any other consumer).  We could then catch it, check the pref from chrome code, and tweak the DOM styles as necessary, and docshell could remain none the wiser.  This would be generically useful for about 27 different reasons, honestly, but I don't know how much trouble it creates.  I bet biesi does.  :)

>Index: docshell/resources/content/netError.xhtml
>         var className = getCSSClass();
>-        if (className) {
>+        if (className && className != "expertBadCert") {
>           // Associate a CSS class with the root of the page, if one was passed in,
>           // to allow custom styling.
>           document.documentElement.className = className;

I guess the reason you put the guard in here and special cased it was so that you wouldn't need a separate favicon in this case, right?  I've always found that favicon trick bothersome, tbh, and I wrote the stupid thing.  AFAIK, no one depends on it since malware was moved to its own about:blocked page, instead of piggybacking on about:neterror, but removing it here is probably beyond this bug's scope.  Hrm.

>@@ -188,6 +188,9 @@
>           faviconParent.appendChild(favicon);
>         }
>+        if (className == "expertBadCert") {
>+          showSecuritySection();
>+        }
>       }

If we don't change anything else, I do agree that this will accomplish the desired task.  

I'm gonna clear my review request here, though.  If we decide to go ahead with the current approach then you'll need a docshell peer anyhow, but if you're interested in the event-emission approach, then the patch'll look totally different.  I will give it my ui-r stamp of approval though - I am fine with the idea that setting the pref should have the effect of unhiding the buttons (since the user is explicitly telling us they know what they're doing.)
Comment 18 Mike Beltzner [:beltzner, not reading bugmail] 2008-05-01 12:00:50 PDT
Comment on attachment 317597 [details] [diff] [review]
"expert" UI for badCert error pages

I'd like to keep us open to switching the default value of this pref to "2" so that if someone *chooses* to make an exception, the cert is prefetched for them. Could we make this a new value like "3"?
Comment 19 Daniel Veditz [:dveditz] 2008-05-01 13:10:47 PDT
> we're introducing code in docshell that checks a firefox-only pref

This whole codepath is contingent on the "browser.xul.error_pages.enabled" pref, it doesn't seem to be a problem. If the prefs get renamed they can all get renamed together.

(In reply to comment #17)
> >+        if (className && className != "expertBadCert") {
> 
> I guess the reason you put the guard in here and special cased it was so that
> you wouldn't need a separate favicon in this case, right?

Right. Otherwise I've either got to remove the favicon code (which I didn't know was unused) or duplicate the existing warning favicon under the name expertBadCert_favicon.png so it'll be found. In every theme.

> If we decide to go ahead with
> the current approach then you'll need a docshell peer anyhow,

jst certainly counts for that.
Comment 20 Daniel Veditz [:dveditz] 2008-05-01 16:16:43 PDT
Created attachment 318920 [details] [diff] [review]
same using new pref

Same as before except using a separate pref rather than assuming the state of the "cert pre-fetch" pref.
Comment 21 Mike Beltzner [:beltzner, not reading bugmail] 2008-05-01 17:14:44 PDT
Comment on attachment 318920 [details] [diff] [review]
same using new pref

uir+a=beltzner, thanks
Comment 22 Daniel Veditz [:dveditz] 2008-05-02 00:37:43 PDT
Fix checked in.

Expert users can set the pref "browser.xul.error_pages.expert_bad_cert" to true to unhide the "add exception" buttons on the error page, and set "browser.ssl_override_behavior" to 2 to pre-fetch the certificate on the exception dialog. (The latter might end up the default in the shipping FF3)

This is one more click than the Firefox 2 and earlier click-through, with compensation that we'll remember that you granted the exception and not bother you with it on subsequent visits. Remembering the cert is both less annoying and more secure since if the error page comes up again when you hadn't changed the cert you know something is wrong.

If that's still not enough for web-hosting people then you really shouldn't bother with SSL--it's not buying you anything--but if you can't avoid it then you want the "MITM Me" addon.
Comment 23 Kevin Stange 2008-05-02 01:07:00 PDT
This is quite good.  I never really wanted a way to bypass the warnings, just a better method for speedy workflow.  I prefer to be reminded that I'm bypassing a verification process and retaining the point at which I'm able to review the actual certificate before blindly accepting it.  I think "MITM Me" goes to far.  The modifications I myself made to the jar files in my FF3 installation did exactly what these options do.

The extra steps by default are certainly not a bad thing for novice users.  I think that the default to accept the certificate permanently may not be necessary be a good thing, but I'm curious, does accepting the certificate permanently generate a warning if the certificate is replaced?

Adding a "permanent" initial exception and getting a warning if the certificate changes would be a more useful metric to me that I need to look more carefully at what's going on.  Then I can do a quick thought process: "Was this server just re-provisioned?  Yes?  Okay!  No?  Danger!"  This, much in the same way that I have to kill entries in my known_hosts file after the SSH keys have changed, gives me a chance to see if a man "jumped" in the middle... generally they won't have the chance to get in the middle while we're processing the provisioning or immediately after it (and at this time there's little actual security risk).

If a changed certificate doesn't generate a warning after a permanent exception is created, I'd like it to, and I'll be happy to file that bug if needed.
Comment 24 Johnathan Nightingale [:johnath] 2008-05-02 05:39:15 PDT
(In reply to comment #23)
> The extra steps by default are certainly not a bad thing for novice users.  I
> think that the default to accept the certificate permanently may not be
> necessary be a good thing, but I'm curious, does accepting the certificate
> permanently generate a warning if the certificate is replaced?

Yes, it does.  In fact, more specifically, an exception is a 3-way association:

host:port:cert

If any of those three change, the exception doesn't apply.  So a different host presenting that cert is a warning, the same host presenting a different cert is a warning, even moving around on the port list (since hosting sites may have independent sites on different ports) is a warning.  Anything except the *exact* exception that was added is treated as though there is no exception at all.
 
> Adding a "permanent" initial exception and getting a warning if the certificate
> changes would be a more useful metric to me that I need to look more carefully
> at what's going on.  Then I can do a quick thought process: "Was this server
> just re-provisioned?  Yes?  Okay!  No?  Danger!"  This, much in the same way
> that I have to kill entries in my known_hosts file after the SSH keys have
> changed, gives me a chance to see if a man "jumped" in the middle... generally
> they won't have the chance to get in the middle while we're processing the
> provisioning or immediately after it (and at this time there's little actual
> security risk).

Right.

And thanks for the fix, Dan.
Comment 25 Daniel Veditz [:dveditz] 2008-05-07 14:47:16 PDT
(In reply to comment #23)
> Then I can do a quick thought process: "Was this server just re-provisioned?
> Yes?  Okay!  No?  Danger!"

Yes, this is what I meant by the FF3 response to self-signed certs being "more secure" in comment 22. In older releases once you're habituated to the click-through you won't really notice if it's the exception you see every day or an exception dialog from an attacker.

> This, much in the same way that I have to kill entries in my known_hosts file
> after the SSH keys have changed, gives me a chance to see if a man "jumped"
> in the middle...

Yes, we consciously adopted this model for exception handling. It's better than the nothing Firefox 2 supported, and a familiar model to the sorts of people who had legitimate uses for self-signed certs.
Comment 26 Kai Engert (:kaie) 2008-05-07 15:40:47 PDT
But I really hope we'll never do "first connection to a site is secure with any cert". I hope we'll always warn about bad certs on first sight.
Comment 27 Tim Powell 2009-01-28 18:46:26 PST
This appears to be broken in 3.0.5 (2008120122)

Setting the option does not make any difference in the alert window that pops up for self signed certs.

The window is titled "Alert"
The body is:

hostname:443 uses an invalid security certificate.

The certificate is not trusted because it is self signed.

(Error code: sec_error_ca_cert_invalid)
Comment 28 Daniel Veditz [:dveditz] 2009-01-28 23:30:02 PST
There has been no change, 3.0.5 works just the same. The option described in this bug affects the XUL error pages only; any alert popping up is something else (maybe an XHR request?).

I don't get a popup alert from hostname:443 so it's hard for me to guess what you're seeing and whether it's a bug or not (yes, I know you're not being literal). If there is a problem, however, it should go in a new bug because this one was strictly about the XUL error pages.
Comment 29 Eric Shepherd [:sheppy] 2009-02-18 08:58:20 PST
What's the documentation issue here?  This appears to be just a new preference.  Is that correct?
Comment 30 Eric Shepherd [:sheppy] 2009-05-18 17:26:45 PDT
Still waiting for information on what exactly requires a developer documentation update here; I don't really see anything obvious.
Comment 31 Johnathan Nightingale [:johnath] 2009-05-19 06:32:28 PDT
(In reply to comment #30)
> Still waiting for information on what exactly requires a developer
> documentation update here; I don't really see anything obvious.

I suspect, based on comment 11, that this was intended to be flagged user-doc-needed, not dev-doc-needed.  Am I right, dveditz?
Comment 32 Eric Shepherd [:sheppy] 2011-01-12 12:29:28 PST
This preference is now documented here:

https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks

Note You need to log in before you can comment on or make changes to this bug.