Closed Bug 452335 Opened 16 years ago Closed 16 years ago

SSL Exception Handling Has Insufficient Options

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 398721

People

(Reporter: josh, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/3.0.1 It requires between two and four clicks to access a website with a self-signed certificate. This behaviour has numerous positive aspects for consumers and is an advance in Firefox security. The wording of the message has been discussed in bug 433422. The number of clicks can be minimized by setting browser.xul.error_pages.expert_bad_cert=true and browser.ssl_override_behavior=2 . Free certificates can be obtained at https://www.startssl.com/?app=1 Now that I'm done with the summary....the actual problem is the restrictive handling of certificates which penalizes those who use the browser in non-consumer ways or have different needs. I have four administration machines that I use in different locations/contexts to administer many dozens of devices with SSL admin interfaces. Those systems sometimes don't even allow the certificate to be changed. In any case it would be a needless expense / effort to install valid certificates on every device I interact with (and sometime impossbile when I don't have control of the devices). Similarly, going through a long process on every machine I use to interact with these devices is painful. I request one or more of the following solutions: 1) A preference to disable ALL warnings of self-signed certificates. browser.ssl_override_behavior=3? Just take the problem away. 2) Perhaps the Green extended validation bar on the Location Bar could be a Red no validation bar in cases of untrusted certs. Show me I should be concerned, but let me decide whether to care. 3) Automatic acceptance of self-signed certificates....the first time. Loud warnings if the certificate changes. 99% of the time the self-signed cert I'm getting is actually the certificate of the server I'm talking to. If the goal is to catch MITM attacks, I only need to be informed if the cert CHANGES. This behaviour would match that of SSH which is renowned for it's security. I'm terribly surprised that this hasn't already been discussed and resolved, especially with the loud coverage of the issue. I support the efforts towards security and safety in the new versions of Firefox. I simply don't think that a UAC-type solution works for everyone. (And at least in Vista, I can turn UAC off.) Thank you for your efforts and time! Reproducible: Always Steps to Reproduce: 1. Access http server with a self-signed certificate.
> 1) A preference to disable ALL warnings of self-signed certificates. > browser.ssl_override_behavior=3? Just take the problem away. If we added a pref like this, I think too many users would set it. They would become insecure, and this would reduce the pressure on sites and device manufacturers to get their certs in order. You can change the behavior in your own builds, of course, but I don't think we want to make it that easy. Does https://addons.mozilla.org/en-US/firefox/addon/6843 do what you want? > 2) Perhaps the Green extended validation bar on the Location Bar could be a Red > no validation bar in cases of untrusted certs. Show me I should be concerned, > but let me decide whether to care. This has subtle security problems, so it would be even worse to add a pref for. See http://robert.accettura.com/blog/2008/07/19/unobstructed-https/#comment-386085 > 3) Automatic acceptance of self-signed certificates....the first time. Loud > warnings if the certificate changes. 99% of the time the self-signed cert I'm > getting is actually the certificate of the server I'm talking to. If the goal > is to catch MITM attacks, I only need to be informed if the cert CHANGES. Same problems as #1. But see bug 398721. > This behaviour would match that of SSH which is renowned for it's security. This is a non-sequitur. SSH usage is very different from Web usage.
(In reply to comment #1) Jesse, thanks for the fantastic, well thought out response. It really helps to get some insight into the thinking on this. > If we added a pref like this, I think too many users would set it. This is the argument I have the greatest problem with. If it's a feature that the users want, then it should exist. If the security techniques are too invasive, people just find a way around them. Whether that's a pref, or going back to IE, or something else. It's my computer. On the other hand, well designed security measures shouldn't feel invasive. > and this would reduce the pressure on sites and device > manufacturers to get their certs in order. This argument is more fully discussed in the bug you linked. Interesting ideas. On the other hand, the manufacturers don't get any pain from the dozen annoyances I run into during my day. 'Works fine in IE' is still the dominant attitude. Heck, I'm happy when a device works at all in FF. I don't think it's reasonable to use the user base as a political football in a dispute with manufacturers. > Does https://addons.mozilla.org/en-US/firefox/addon/6843 do what you want? It appears to. I should have linked to that in my summary. Unfortunately, the comments indicate that it's not working. I just tested on FF-MacOSX and it did nothing. I'm not sure if the author is responding. That said, however, a working plugin would be as good as a pref to disable the checks. I think this is an appropriate solution. > See > http://robert.accettura.com/blog/2008/07/19/unobstructed-https/#comment-386085 > see bug 398721. Excellent information here. It's hard to keep my mind on all of the threats that you're trying to solve for. There's definitely a need for these kinds of fixes to make browsing safe. However, I still need access to my network administration / html rendering console. Web-based administration is just barely reaching the level of 'usable'. It's going to take a while for the manufacturers to catch up to 'good'. And they never patch old product. I am confused about one thing. Isn't the feature, as implemented, a KCM solution (as per the bug above)? The weak warning/strong warning is implemented...just with more clicks (and maybe some prejudicial phrasing). Is there a way to work this towards an interface with less friction? Maybe if I pass a 15 question quiz on phishing and nigerian scams my browser will let me just get on with things? Nevermind. That would be silly. Then we'd have to enter all those bugs to get the bookmark sync folks to do 'quiz sync' at the same time. The simplest thing for now would be a plugin, preferably a supported one so that I'm not faced with the dilemma of security upgrades vs. losing my plugin.
Speaking of syncching, synching cert exceptions across your computers would solve the problem, right?
...I think it might. I'd have to try it in practice. But I think that might do the trick.
It would certainly improve your security, if not your efficiency ;)
Even though I'm not in favor of self-signed certificates (who actually really is?), I think that Josh's proposal makes some sense. I'd opt for a combination of #1 and #2. It would give power users who really needs them some relief. I don't expect mom-and-pop to change those settings via the about:config page. Everybody else either really needs it or is ignorant, either of them should know what they do. I also believe that the pressure upon device vendors and other site operators would not be off in this way.
(In reply to comment #2) > (In reply to comment #1) > > Does https://addons.mozilla.org/en-US/firefox/addon/6843 do what you want? > It appears to. I should have linked to that in my summary. Unfortunately, the > comments indicate that it's not working. I just tested on FF-MacOSX and it did > nothing. I'm not sure if the author is responding. > > That said, however, a working plugin would be as good as a pref to disable the > checks. I think this is an appropriate solution. Well hell, I wish AMO would send me email when people review my addons. I'll take a look at what's going on here with the add-on as soon as I can.
(In reply to comment #7) > (In reply to comment #2) > > (In reply to comment #1) > > > Does https://addons.mozilla.org/en-US/firefox/addon/6843 do what you want? > > It appears to. I should have linked to that in my summary. Unfortunately, the > > comments indicate that it's not working. I just tested on FF-MacOSX and it did > > nothing. I'm not sure if the author is responding. > > > > That said, however, a working plugin would be as good as a pref to disable the > > checks. I think this is an appropriate solution. > > Well hell, I wish AMO would send me email when people review my addons. I'll > take a look at what's going on here with the add-on as soon as I can. I believe MiTMMe should work again, and as you say, this extension approach is preferable to building the behaviour into the browser. Josh: does MiTMMe suit your purposes? Is this bug closeable?
I just updated MiTMMe from the link above (version 1.21) and tried it in FF3 on Windows and Mac. In neither case did it work. I still get the 'Secure Connection Failed' message. Can you explain what method MitMMe uses to disable the security check? While I think the plugin does solve my immediate need, I would be happiest if I could get FF to auto-accept all certificates on the first attempt and warn if they change. This would provide the ease of use I'm looking for as well as a threshold of warning should I be attacked.
(In reply to comment #9) > I just updated MiTMMe from the link above (version 1.21) and tried it in FF3 on > Windows and Mac. In neither case did it work. I still get the 'Secure > Connection Failed' message. Yes, MitMMe does still display the error page, but you can bypass it with 1 click ("Add exception") instead of the usual 4-step process. Bypassing the initial error page is harder, since that is thrown up by backend code before our front-end code even knows what's happened, basically. > Can you explain what method MitMMe uses to disable the security check? While I > think the plugin does solve my immediate need, I would be happiest if I could > get FF to auto-accept all certificates on the first attempt and warn if they > change. This would provide the ease of use I'm looking for as well as a > threshold of warning should I be attacked. What you are describing here is called "Key Continuity Management" and discussion of whether or not Firefox should employ that behaviour is in bug 398721. As Jesse mentions, though, this is an approach with its own complications. Given that, I'm interpreting your comments here as indicating that this bug is substantially a duplicate of 398721, outside of the aspects that are mitigated by the addon, so I'll resolve your bug here as a duplicate of that one.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Hey! The extension cited in this thread is not available anymore. Currently, the situation is that a user has to add an exception for some site, then forgets about it, then come back to the site, the padlock is green and therefore, they don't remember an exception was added. A red padlock or a broken padlock would help in this case. Is there already another bug for tracking something like #2?
Hi Vincent - as of bug 1201437 (which landed in Firefox 47), if a user adds an exception, the lock is grey with a yellow triangle instead of green. Hopefully this addresses your concern.
Hi David, Thanks for the pointer. Yes, this totally addresses my concern.
You need to log in before you can comment on or make changes to this bug.