Closed Bug 399275 Opened 17 years ago Closed 16 years ago

create preference which restores per-page SSL error override option for IT professionals

Categories

(Core :: Security: PSM, enhancement)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: beltzner, Assigned: KaiE)

References

Details

Bug 327181 removed the click-through on SSL error pages to enhance security for regular users, but comments on other bugs (see bug 398915 comment 14) lead me to wonder if this might not alienate some important technical users who have been our early adopters and testers.

Users who know what SSL is about can be expected to make informed decisions based on the SSL errors, and should be given the option to quickly override an error. By supporting an about:config pref (which would have to be manually added) we could help this audience without adding risk for the general user.
Flags: blocking-firefox3?
Assignee: nobody → kengert
Component: Security → Security: PSM
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: firefox → psm
Flags: blocking1.9?
In bug 399275, comment #18, mrz gives a good explanation as to why such a preference is needed in the real world.
So, you'd prefer to click through an exception for every visit, 
as opposed to setting an exception, just one time for each site, and 
then never having to do it again?  (which the present implementation offers)?

Are you sure this isn't just force-of-habit dictating behavioral preference?
I believe (see the comments in the other bug) that the issue at hand is that in certain test environments this sort of thing is pretty common to happen at the tens-to-hundreds of certs level, and so enabling the clickthrough is a lot less painful than going through our labyrinthine UI for adding exceptions (prefs > advanced > encryption > view certs ... > servers > add exception ...)
Well, if you had to go through the whole labyrinth for every cert, then 
yes, I'd agree.  But it seems that once you get to the heart of it, you
can do a lot while you're there.
Reed meant to refer to bug 398915 comment 18.  Please go read that.
Dave, I'm already familiar with all the comments in that bug.
No one is proposing that you buy 100+ certs.
The presently implemented scheme allows you to "permanently" 
record the server cert for any https server with a single URL pasted
into the right dialog.  You do it once per server.  After the first
few minutes on the first day, you never do it again.  

Do you really want a pref to click-through those certs, day after day, instead?  
Does that save hostname mismatch overrides as well?  None of the hostnames match.  We use a URL like "servername.ilo" to reach the server, and the certificate is for something like "HPDL360125456USEF".

Even if that did save hostname overrides, you're talking about spending an entire day doing data entry for a small datacenter, and a couple weeks for larger ones.  To most people, a couple seconds for a clickthrough every time you hit the box is much less of a hassle.  A checkbox on that dialog that says "any time I get a cert for HPDL360125456USEF consider it a match for servername.ilo" would be cooler though.
Maybe this pref shouldn't restore the dialog, but instead add a button on the error page that shows the certificate information and lets you whitelist it (without going all the way through Preferences).
Yeah, I'm with Jesse there. :)
In answer to comment 7:
> Does that save hostname mismatch overrides as well? 
Yes.
Cert Manager is a modeless dialog.

Power users can open it and go to the Servers tab when they encounter such a data center box the first time during their firefox session.

You can keep the cert manager open all the time while you manage your boxes. When you go to a new site, copy, paste, two clicks, done.

I have dealt with self signed certs and mismatching hosts in the past, myself. Here is what I experienced from my own behavior: I was trained to click through that dialog all the time, because I required it for my work. Now what happened when I did some private surfing to random sites? Even though I'm a professional, I realized I clicked through the dialog on foreign sites, too. I clicked faster than I could think about it.

I don't know whether the same applies for you, too. But I feel, not having to click through all the time might protect you better when you do browsing in the wild.

(In reply to comment #7)
> Even if that did save hostname overrides, you're talking about spending an
> entire day doing data entry for a small datacenter, and a couple weeks for
> larger ones.

Although you can do that "as you go".

> A checkbox on that dialog that says
> "any time I get a cert for HPDL360125456USEF consider it a match for
> servername.ilo" would be cooler though.

If you always use "servername.ilo" to open the page, and the cert is always the same, the add-exception dialog gives you that.

(In reply to comment #11)
> Power users can open it and go to the Servers tab when they encounter such a
> data center box the first time during their firefox session.
> 
> You can keep the cert manager open all the time while you manage your boxes.


If that seems inappropriate, but we want to avoid "going through our labyrinthine UI" (comment 3) every time, what about making certificate manager more easily accessible? What about adding a menu command "Extras / Certificates"?

This reduces the amount of clicks required to reach it, but you still "have to know where to go".

(In reply to comment #11)
> You can keep the cert manager open all the time while you manage your boxes.
> When you go to a new site, copy, paste, two clicks, done.

This is painful - who wants yet another floating window open for the off chance that I *might* need to add a cert exception.  The most logical place is on the error page if the user decides to enable that functionality in about:config.

> I have dealt with self signed certs and mismatching hosts in the past, myself.
> Here is what I experienced from my own behavior: I was trained to click through
> that dialog all the time, because I required it for my work. Now what happened
> when I did some private surfing to random sites? Even though I'm a
> professional, I realized I clicked through the dialog on foreign sites, too. I
> clicked faster than I could think about it.

Perhaps you should not enable the pref that allows you to do that then.  In my work, I know the possible impacts of clicking through the page, and choose to do it.  We should at least give the user a choice rather than dictate what they can and can't do.

> I don't know whether the same applies for you, too. But I feel, not having to
> click through all the time might protect you better when you do browsing in the
> wild.

Point is, I am OK with the risk as I actually read the dialog, and want a simple, one-time exception to override the warning.  I don't want it permanently stored anywhere, I just want a way to override for this session.  I understand why you would not enable this for the general public, but seems reasonable to have the functionality there through a pref (which most users will never change).

This often comes up if we are testing new sites or staging sites.  We often want to see the content before the certs are in their final form.

> If you always use "servername.ilo" to open the page, and the cert is always the
> same, the add-exception dialog gives you that.

When we are in a rush trying to get a server back up (often when we use ilo), the last thing I want to do is go into the prefs, navigate to the cert prefs page and add a exception for that host.

What's the harm in making this a user pref?  I guess I don't understand the pushback.


> What's the harm in making this a user pref?
> I guess I don't understand the pushback.

Well, usually for niche use-cases we preferred extension-based solution to a pref (arguments being the code size, trying not to ship more code we don't test, etc) :)
I'd be happy with an extension as long as the functionality is available somewhere. :)

Unlike Justin, I wouldn't mind having it permanently store my decision for that site.

I just tried out last night's Minefield nightly with a couple of said sites, and checked out the exception UI.  As a whole, it's not bad.  It does waste precious time trying to get to the dialog if you're in a hurry to fix a broken server, however.  One thing I do notice is if you store an exception, it appears on the dialog as if it's saying "ignore any verification errors I get trying to access this site", which doesn't feel safe to me.  I'd rather it do something like "A cert with this CN is okay with this site" or "this specific certificate is okay with this site".  Otherwise you're opening yourself up to MITM again if you add an exception.
Can't we add a button on the error page to open the Certificate Manager with the Servers tab selected?
At the very least, the error page needs to explain that you can add a exception in the Certificate Manager.
(In reply to comment #15)
> I just tried out last night's Minefield nightly with a couple of said sites,
> and checked out the exception UI.  As a whole, it's not bad.  

> One thing I do notice is if you store an exception, it
> appears on the dialog as if it's saying "ignore any verification errors I get
> trying to access this site", which doesn't feel safe to me.  I'd rather it do
> something like "A cert with this CN is okay with this site" or "this specific
> certificate is okay with this site".  Otherwise you're opening yourself up to
> MITM again if you add an exception.

Dave, Thanks for giving it a try.

You'll be glad to know that when you add a cert as an exception, 
it means exactly "this specific certificate is okay with this site".  

Apparently the UI didn't make that clear.  Please help us to figure out 
how it failed to send that message, so that we can improve that UI.

The UI shows the host name and port for which the cert will be accepted.  
To me, the presence of that site name and port number strongly implies that
the cert is good only for that site and port.  But I suspect I'm too close 
to this subject to understand how others will interpret it.  So please tell,
What was it about that UI that conveyed a different message?  
(In reply to comment #16)
> At the very least, the error page needs to explain that you can add a exception
> in the Certificate Manager.

Please see bug 398718 for discussions on how to enhance the error page.

(In reply to comment #17)
> What was it about that UI that conveyed a different message?  

There's a column on the table in the Servers tab that says "Certificate Name", and that column says "(Not Stored)" on the exception entries I made.  That sounds a lot like it didn't store the actual certificate to me.  The only column with any data in it is the "Site" column.  The View and Edit buttons are also dimmed out when this exception entry is highlighted.

(In reply to comment #19)
> There's a column on the table in the Servers tab that says "Certificate Name",
> and that column says "(Not Stored)" on the exception entries I made.  That
> sounds a lot like it didn't store the actual certificate to me.  The only
> column with any data in it is the "Site" column.  The View and Edit buttons are
> also dimmed out when this exception entry is highlighted.


I think you ran into bug 399057.
You get that display when the server cert labels itself as being a Certificate Authority cert...

In reply to comment 19:
Ah, the certs being offered by that server are more seriously screwed up 
than average. :-)  They're setup as CA certificates, not as server certs.
The appearance of such certs is the subject of bug 399057.  SOmething will
get done about that.  Not sure what though.  
One problem I have with the exception UI is that it doesn't allow me to make my own certificate "super trusted". We use the same certificate for all domains on the same IP address and port and can't use server name indication because OpenSSL doesn't support it yet. What would be helpful would be an exception to make a certificate accepted for all connections to a certain IP address, no matter what the hostname. In a few years when the tooling support for SNI will be available widely this could be changed back.
So, if this is really for sysadmins managing servers and the like, would it not make more sense to add a pref for just ignoring cert errors entirely for nonroutable IPs?  This would allow mrz and Justin and justdave to access servers on the internal network, without compromising on "no click-through on the open internet"  It'd be less annoying to them, since I"m sure they never actually read the dialogs, since they're expecting them, and doesn't get them in the habit of blindly accepting dialogs so that they get exposed on other things.

Its not zero-risk, but its a reasonable compromise that actually improves the sysadmin experience IMO.  And to answer Justin, the pushback is that every single user pref adds code complexity, we should only add things that actually are justifiable and maintainable.
s/nonroutable// - I wouldn't assume that every internal network is RFC1981 or that non-RFC1981 space was "routable" (Mozilla is the first place I worked at where that's the case - 3Com had a /16 and there was little reason to use RFC1981).

I did think about that - if I had some hidden option to whitelist a whole range of IP addresses I'd be happy.
re comment 19

Maybe we should change 'not stored' to 'only hash available'? Our exceptions are tied to a specific cert, which we identify by the cert's hash. We store the cert only for UI purposes (so that you can see what cert you're exception applies to in the UI). It's possible that that cert may not be in the database (though it usually requires manual intervention for that). You can, for instance, share your exceptions file with othere. In that case they would still except a specific cert, but would not be able to display information about that cert.

bob
  From my perspective, the old behavior with self-signed certificates right now is perfectly fine. 

  There are probably more situations with self-signed certificates that you're going to hear about in this bug, but right now you're getting feedback from technical users, because that's who uses test/nightly releases.

  For example, imagine a user who bought a home router, but this home router decides that it wants to be secure by default and redirects its web interface to https, using a self-signed certificate. The UI for a user to access his router should be *discoverable* to this user. That means it can't be in an extension (he can't get out to the Internet anyway) and it can't be hidden too far away from the actual error page itself.

  Another use case, perhaps less important but still valid, is a small office with some internal servers that are used by admin people and technical people. Maybe there's only one technical person, or the technical person is a consultant. They're on a tight budget, so he used a self-signed cert. He wants security for his office (saves him time), so he installs Firefox on their desktops. He leaves instructions with the Office Manager about how to accept the self-signed cert. Formerly, these instructions were simple (click OK), and they should continue to be simple enough to be *explained to others* by a non-technical person.
(In reply to comment #27)
>   Another use case, perhaps less important but still valid, is a small office
> with some internal servers that are used by admin people and technical people.

Or, an OSS org that uses VMware ESX and lets QA folk get to the ESX https admin interface to powercycle hung VMs... it was easier to switch browsers than it was to find and whitelist this host.  I fear others would do similiar.
A few months ago, my father almost lost a lot of money to one of those fake bank websites (operated by the Russian maffia) that managed to get his VISA card number and CSC code. The first transaction (1000 euro) was carried out, but the second one (3000 euro) was blocked by VISA, and then his card was blocked and the money reimbursed. Let me tell you, the danger is real here.

He was actually using Firefox 2 ofcourse, but he just clicked on the 'accept' button, because he assumed that it was the bank. And he was used to click the same button in Exploder too, he thought it was normal ! (he didn't see the difference between that warning and the regular-warn-before-you-submit) And he also assumed that the presence of the lock-icon guaranteed that it was a save connection.

Aside from detecting the phishing site, what's important is that Firefox makes it difficult to accidentally accept a fake or incorrect certificate. The current workaround is fine for me, but unfortunately too complicated for most common users. They need a little help, see bug 398718. If we allow the to accept the certificates, it should use very strong warnings, to prevent phishing sites. Maybe with an intermediate warning page, so that it requires 2 clicks.

IT professionals might want a global option to switch it off, but I don't think this is a good idea, because people will post this trick on websites, and then we're back at the old situation. The problem is that people who don't know this option, will think that FF is broken and go back to IE (in which case they're also back worse). Adding such an option isn't the right solution, it just makes it worse.

Maybe we can add an exception for RFC1918 (not 1981 as in comment 24) ipaddresses ? Not accepting them right away, but adding a button to do so (with the same dang warnings obviously). That might also cover most home routers and similar equipment.

I asked a few former colleagues who write the software for the Thomson ADSL modems, why they use self-signed certificates instead of real verifiable ones. The reason is very simple : you need the certificate to connect to the modem (to configure it), *before* you have an internet connection (it's an RFC1918 address). So you can't verify it at all. And downloading a root-certificate first from the device itself, would just be as insecure (and more inconvenient, since it's a 2-step process).

Switching to a real certificate after installation also doesn't work, because you still need access to the configuration page if your internet connection doesn't work anymore.

Installing a real verifiable certificate, using a root that is installed in all browsers, wouldn't require internet access to verify it. But this would require to assign a certificate to 192.168.0.10 or whatever the default ipaddress is (since you don't have DNS either), and this also has security implications.

This is ofcourse their opinion, so don't complain if there's another solution. I just wanted to voice what the manufacturers think about this issue.
With Fx3a8+, I can no longer access my webmail using SSL. Infomaniak hosts thousands of websites, all having their own name, so I doubt they can have certificates which match them all. There is a single SSL cert for *.infomaniak.ch, but Fx3 rejects its.

Oh, and I cannot test Bugzilla using SSL locally anymore, because I use the cert provided by default by my Linux distro. Do I have to leave Fx to do QA??
(In reply to comment #31)
> With Fx3a8+, I can no longer access my webmail using SSL. Infomaniak hosts
> thousands of websites, all having their own name, so I doubt they can have
> certificates which match them all. There is a single SSL cert for
> *.infomaniak.ch, but Fx3 rejects its.

Can you post the exact URL you are trying to visit?

 
> Oh, and I cannot test Bugzilla using SSL locally anymore, because I use the
> cert provided by default by my Linux distro. Do I have to leave Fx to do QA??

Are you saying that you get an error message when you visit https://bugzilla.mozilla.org ?  If so, what is the error message?

OK, I have a wild idea.  We already store a bunch of history information somewhere, correct?  How about any time we visit a site that has a valid SSL certificate, we remember the fact that we used a valid cert on that site forever.  If at any point in the future you hit that same site and the cert isn't valid (expired, self signed, domain mismatch, whatever) we do the absolutely refuse to go there thing.

But if we hit a site with an invalid cert for which we've never seen a valid one (particularly if it's self-signed) we have less-restrictive UI with ability to bypass it.
(In reply to comment #27)
>   There are probably more situations with self-signed certificates that you're
> going to hear about in this bug, but right now you're getting feedback from
> technical users, because that's who uses test/nightly releases.
> 
>   For example, imagine a user who bought a home router, but this home router
> decides that it wants to be secure by default and redirects its web interface
> to https, using a self-signed certificate. The UI for a user to access his
> router should be *discoverable* to this user. That means it can't be in an
> extension (he can't get out to the Internet anyway) and it can't be hidden too
> far away from the actual error page itself.
I agree with this comment.  I don't believe the average use will see the error and attempt to figure out the process for adding the cert.  What they will do is see the error, assume that FF is broken, see that IE or Safari works, and assume that IE or Safari is somehow better than FF.  By adding this feature we are moving backwards towards the days of "IE only" sites.

> How about any time we visit a site that has a valid SSL
> certificate, we remember the fact that we used a valid cert on that site
> forever.  If at any point in the future you hit that same site and the cert
> isn't valid (expired, self signed, domain mismatch, whatever) we do the
> absolutely refuse to go there thing.


So we can't do that for every site. Real sites change their certs yearly. This means with this scheme you will break going to amazon, your bank, etc. about once a year. Also, some sites have web farms where their may be different certificates used depending on which server happens to be hit (we know this because sometimes one or more of those servers have broken certs at time). This is not the experience we want for the average user.

The problem we have is a to low bar for bypassing broken certificates in the general case (which is why this change was made).

If you want this behaviour, you can still go to your override button and override the certificate. If you remove all of your root certs you will get the first part of the behavior as well.

(In reply to comment #35)
> So we can't do that for every site. Real sites change their certs yearly. This
> means with this scheme you will break going to amazon, your bank, etc. about
> once a year. Also, some sites have web farms where their may be different
> certificates used depending on which server happens to be hit (we know this
> because sometimes one or more of those servers have broken certs at time).

You misunderstood my suggestion.  I didn't say to save which certificate we used with that site.  Only whether it was valid or not.  If we visit a site and it has a valid cert, then we assume that the operators are responsible and will maintain it being valid (even if they change the cert, the one they replace it with should still be valid).

(In reply to comment #32)
> Can you post the exact URL you are trying to visit?

https://webmail.cdis-ts.ch/login.php


> Are you saying that you get an error message when you visit
> https://bugzilla.mozilla.org ?  If so, what is the error message?

No, I said "locally" as in "my QA installations installed on my own PC".


Could we get some traction from beltzer or mconnor to be sure to not forget this bug for Fx3, setting the blocking flag accordingly? ;)
Dave, This bug proposes a pref to change the UI.  In comment 33 - 36,
you are proposing something called "Key Continuity Management".
There is a separate bug for that subject, bug 398721.
Please take the KCM discussion there.
Severity: normal → enhancement
Shouldn't this bug depend on bug 327181?
>This bug proposes a pref to change the UI.

I'm glad that hasn't been forgotten about. There's been precious little discussion on that pref since the first half-dozen comments. What are the chances of this getting in to 3.0? Is there any interest in developing a patch for this? Sorry for the spam; I'd really like to see this pref but it seems like it's not moving forward at all...
This hit me today - Raritan's KVM-over-IP redirects to https using a self-signed certificate.  
How about to create a pref that can treat cert errors as non-fatal?
(Treat them as fatal by default, of course)

In non-fatal mode, if a cert error occurs:

* background of the location bar becomes another color (ex. red)
* "!" is displayed in front of the padlock icon
* a message bar appears like the popup blocker
* detail of the error is displayed in the security tab of pageinfo
* etc.

This can be used like --no-check-certificate option of wget,
along with indication of cert errors.
Non-fatal mode referred to in comment #42 means that
errors are indicated without click-through dialog.
Regarding comment 14, would an extension have the ability to override functionality at this low level?
Flags: blocking1.9? → blocking1.9-
Bug 401575 added an "Add Exception" button to the error page. So instead of being a dead-end, you can click-through again (with 3 clicks).
Blocks: 412349
I propose to resolve this bug as WONTFIX, now that we have a path to override.

(In reply to comment #46)
> I propose to resolve this bug as WONTFIX, now that we have a path to override.

I would agree.  As an IT professional, I'm satisfied with the current override method.  It's a couple extra clicks than it used to be, but it's quite usable.  At the time most of us were complaining on this bug, trunk didn't have a way to do overrides without manually going to the certificate manager.
WFM too. Comment 37 is now addressed.
(In reply to comment #47)

Dave: As an IT professional, I am not satisfied with the current override method. It's really quite tedious if you work with a lot of self-signed certs.

At the very least, the certificate manager should get the certificate for me - given that it's already downloaded it to decide that it hates it, why do I then have to click Get Certificate?

It seems like you don't want to make it easy for people to use broken SSL sites, which makes sense for some classes of users, but not for me, so I would like an about:config option which enables UI magic on the SSL errors pages for granting temporary/permanent exceptions in no more than two clicks.

This is not unreasonable. Your userbase extends beyond the facebooking masses.
(In reply to comment #49)
> (In reply to comment #47)
> 
> Dave: As an IT professional, I am not satisfied with the current override
> method. It's really quite tedious if you work with a lot of self-signed certs.
> 
> At the very least, the certificate manager should get the certificate for me -
> given that it's already downloaded it to decide that it hates it, why do I then
> have to click Get Certificate?
> 
> It seems like you don't want to make it easy for people to use broken SSL
> sites, which makes sense for some classes of users, but not for me, so I would
> like an about:config option which enables UI magic on the SSL errors pages for
> granting temporary/permanent exceptions in no more than two clicks.

You probably want: browser.ssl_override_behavior

Setting it to 2 gets you there in 3 clicks, by pre-populating the cert dialog.

And: browser.xul.error_pages.expert_bad_cert

setting that to true unhides the add exception button, by default.




Given comment 50, bug 427293's resolution, and extensions like this one: https://addons.mozilla.org/en-US/firefox/addon/6843

...I propose that this bug be closed, since you can now have your choice of 1, 2, 3 or 4 clicks, with or without specifying the hostname manually, temporary or permanent; truly a dizzying panoply of options, and we are all no doubt richer for it.

Beltzner, as the reporter, would you agree?
I agree with comment 51, let's close this.
Per-site override option for SSL now exists, per reporter's request, and there are not one, but two, two, two prefs to modify its behaviour!

FIXOLA.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.