451655 - FF 3 self-signed cert handling creates major usability problem for appliance vendors

Status: RESOLVED DUPLICATE of bug 431826

(Firefox :: Security, defect)

Description

[Kimbro Staken]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/523 (KHTML, like Gecko, Safari/523.10) OmniWeb/v621.0.99313
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

The changes for self-signed certificates have created a serious usability problem for appliance vendors and are going to result in an overall reduction in security due to it. 

I'm going to present a point from the perspective of an appliance developer, but this problem will extend in other areas as well.

Appliances will generally be deployed on the local network, pull an IP address from DHCP and then present a web interface for configuration. That interface is generally served via https for the sole reason of encrypting the connection. NOTE: In this scenario there is absolutely NO way to use a valid CA signed certificate. Because of this the Firefox "Secure Connection Failed" error will be generated when the user goes to access the configuration interface for the appliance. This user experience is extremely hostile and there is no good way for a product developer to effectively handle the situation. From a product development perspective having users confronted with the  "Secure Connection Failed"  error is an absolute show stopper. The result? Since this error was designed to scare users, that ends up scaring users away from using the product. A product developer with a "secure" product that no one uses because their browser tells them it's broken is not a product developer that will be in business for very long. 

By introducing this change to try to protect people from MITM and untrusted certificates you're creating a user experience that's so hostile that product developers will have no choice but to react by simply turning SSL off. Arguments about MITM attacks are weak when it's compared to the reality of everyday network sniffing. Network sniffing is common and because of this, the FireFox 3 handling of self-signed certs will have the net effect over time of making the network less secure.
 
There needs to be a separation between the trust elements and the encryption elements. In the scenario outlined above, the user has virtually zero reason to not trust the device they're connecting to so setting up encryption in that scenario is not in any way problematic. But telling the user that "Secure Connection Failed" and all the other hoops it makes the user jump through is extremely problematic.

The saying that's relevant here is "you can't see the forest for the trees". This change is so focused on the security edges cases that you've really lost sight of the bigger picture and the understanding of how users and developers will react to this kind of change and the actual effect that this is going to have over time. 

To reiterate, the changed handling of self-signed certs is fundamentally broken and is going to result in less secure products, frustrated users, increased support costs for companies and an overall reduction in network security. Please change this back to something sane.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Matthias Versen [:Matti]]

Turning SSL off is the right way if you have self signed certificates without fingerprints stored somewhere else (and secure !) and users who are been able to compare the fingerprints. MITM are very common with the DNS Poison attacks.
(from the last days: http://securitylabs.websense.com/content/Alerts/3163.aspx ) 
Using HTTP is at the same security level as using ssl with self signed certificates and without fingerprints.

marking as dupe of bug 433324 (wording change in the exception dialog)

Comment 2

[Kimbro Staken]

So let me get this straight, you're telling me that it is Mozilla's official position that it is more secure to turn SSL OFF and pass information in clear text than it is to use encryption with a self-signed cert? 

Why are you so worried about MITM that you completely ignore the simple fact that encryption even in a completely unauthenticated form is VALUABLE! Even if MITM was so prevalent that 1 out of every 10,000 connections gets hit with a MITM attack, that is still far BETTER security than the wide prevalence of simple network sniffing attacks, especially on wireless. I will happily take the MITM risk and I am absolutely furious that we're being forced to REDUCE SECURITY because you guys are so hung up on protecting against that one problem. Self-signed certs are used widely in all kinds of environments for the sole reason of setting up an encrypted channel. People don't use certs because they want authentication, they do it because there is NO OTHER ALTERNATIVE to get an encrypted session. By taking the stance that you have, you simply reinforced the original point of my ticket that this change is reducing security.

Comment 3

[Matthias Versen [:Matti]]

That is my personal opinion of course or Do you expect that in every bug report (we have over 400000) gets a comment from someone from Mozilla.org ?
BTW: General discussions about such design decisions should not be done in bugzilla, please use the newsgroups for this.

The point of the change is that using self signed certificates are reducing the security because users are trained to accept such certificates and if they encounter a real MITM attack which can easy use a self signed certificate they are accepting it before thinking about it if you have only a "ok" button. SSL is designed for security, using it only for encryption is like security by obscurity. Using it only for encryption means that you are using SSL in a different way then it's designed.
Not the Firefox change is reducing the security, self signed certificates are doing that.
Displaying a "security failed" message is the right way to show inexperienced users who don't know something about SSL that something here is wrong. Showing "this is only a little bit secure [OK]" means that a John Doe will read "secure" and he will enter his Credit Card information or Bank Account data on such a page. You talk about MITM attacks and weak and that is funny with the recent DNS attack but even without this DNS problem an MITM attack is not unlikely. 

BTW: One result of this change is for example that one german hosting company switched away from self signed certificates to real Certificates from an official CA. 

Johnathan or Daniel should resolve this bug

Comment 4

[Matthias Versen [:Matti]]

btw: the newsgourps for such discussions is mozilla.dev.tech.crypto

Comment 5

[Matt Anderson]

While I can understand the concern you have over self signed certs, and teaching end users poor security habits I don't think that is particularly relevant in this case.  The bug as it was entered is about appliance vendors, something that end users should be rarely interacting with.

Would it be possible to control this exception handling dialogue via an about:config variable?  This way end users would still be presented with the new warning, but experienced users who typically have to deal with appliances can disable it.

Comment 6

[Johnathan Nightingale [:johnath]]

(In reply to comment #5)
> While I can understand the concern you have over self signed certs, and
> teaching end users poor security habits I don't think that is particularly
> relevant in this case.  The bug as it was entered is about appliance vendors,
> something that end users should be rarely interacting with.
> 
> Would it be possible to control this exception handling dialogue via an
> about:config variable?  This way end users would still be presented with the
> new warning, but experienced users who typically have to deal with appliances
> can disable it.

Hi Matt,

Your concerns are somewhat different than Kimbro's, but yes, for experienced users who expect to encounter many of these because of oddly behaving appliances or just unusual browsing habits, two preferences exist which shorten the path.  Specifically, you may want to investigate browser.ssl_override_behavior and browser.xul.error_pages.expert_bad_cert.

 (In reply to comment #0)
> The changes for self-signed certificates have created a serious usability
> problem for appliance vendors and are going to result in an overall reduction
> in security due to it. 
...
> By introducing this change to try to protect people from MITM and untrusted
> certificates you're creating a user experience that's so hostile that product
> developers will have no choice but to react by simply turning SSL off.
...
> Arguments about MITM attacks are weak when it's compared to the reality of
> everyday network sniffing. Network sniffing is common and because of this, the
> FireFox 3 handling of self-signed certs will have the net effect over time of
> making the network less secure.
...
> The saying that's relevant here is "you can't see the forest for the trees".
> This change is so focused on the security edges cases that you've really lost
> sight of the bigger picture and the understanding of how users and developers
> will react to this kind of change and the actual effect that this is going to
> have over time. 

Kimbro, you seem pretty comfortable making the assertion that Mozilla has failed to consider the matter as deeply as you have.  I hope, then, that you will not take offense if I suggest that you may not have considered everything that we have, either.

You assert at several points, for example, that network sniffing is an easy and common attack, whereas MitM is difficult and rare.  I'm not sure where that statistic is coming from, but even if I stipulated that it was accurate at some point in the past (which it was, absolutely), I don't think it is at all a sound idea to base decisions on today, when tools like the Middler, webmitm, ettercap, and Kaminsky's DNS attacks are well understood, and point-and-click simple.

I confess that your tone wanders so often into pedantic, derisive lecturing that it's hard to believe you were looking to effect meaningful change or engage in productive dialog, but obviously I understand why a browser change which conflicts with your business model would be frustrating, so I'm trying to read your comments as helpful.

Despite your last sentence, I don't really believe you want us to change things back to the way they used to be.  You seem interested in promoting the security of the internet and our users, so I'm sure you don't want us going back to a world where users are taught to blindly dismiss fleeting security messages everywhere they turn.  In any event, it's not something any of *us* are keen to return to.  What we ARE interested in doing is:

a) If we can find a way to do it without risking the integrity of the web in the process, trying to make a distinction between self-signed certs which are likely benign, and those which are more troubling (based on, e.g., whether a given site has presented a valid CA cert in the past).  bug 398721

b) Improving the language and presentation of the warnings we do have to show, since they are still relatively technical and difficult for users to understand. bug 431826, bug 433324, bug 433422

c) Working with various interested parties on solving their actual problems.  For instance, I suspect that a technology like TLS/SRP would be a better approach for network appliance vendors that want to encrypt traffic, for instance, given your claims that no possibility exists to use the existing public key infrastructure.

I'm closing this bug. There does not appear to be any action to take here beyond the action described in the other bugs I have linked to.  If anyone re-opens this again, I trust it will be with a specific problem statement and proposed way forward, at which point the bug will either be ready for patches, or WONTFIXed.