431386 - Self-signed certificates are treated as errors

Status: RESOLVED INVALID

(Firefox :: Security, defect)

Description

[Paul Bramscher]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

Many of us in IT use self-signed certificates, and my online tutorials have been hit tens of thousands of times by commercial and government users worldwide.  Firefox 3 Beta 5 treats them (verbally, the message on the screen) as errors, rather than as bona fide and legitimate uses for openssl by IT professionals, for special purposes, test machines, and limited-audience venues.  Please change the message to be less error-oriented.  Firefox 2.x handled it more appropriately, IMHO.

Reproducible: Always

Steps to Reproduce:
1. Go to a web site with a self-signed certificate.
2.
3.
Actual Results:  
Was presented with "(Error code: sec_error_unknown_issuer)" and irrelevant error-related information.

Expected Results:  
Should have been prompted to the effect that the CA was unknown, and whether or not it ought to be trusted -- this session only, into perpetuity, etc.

Comment 1

[Kai Liu]

But you do have that option: At the bottom of the error page should be a button to add an exception, and you can even make it a permanent exception, if you wanted.

What I do for personal or limited-audience scenarios is add the certificate in question to the browser beforehand (I can even have my users do this: just tell them to visit http://example.com/sample.crt first), which would prevent the error from ever showing up in the first place.

And while self-signed certificates are often used in legitimate ways, making an exception for them simply opens up an easy way for Black Hats to use them for illegitimate purposes.  I agree, it's a pain, but it's the decision that was made, and there are ways to work around it (see above).

Comment 2

[Gabriel Chadwick]

This is the intented behavior. There was a lot of work on this feature and I doubt there will be any change at this point of the release.

I do understand it is frustrating but there is a workaround and it is safer for the typical user...

Comment 3

[Michael]

What I would like is for self-signed certificates to be treated like partial encryption. i.e. the url bar is white not yellow and the padlock has a line going through it. Should I file a new bug for this desired behaviour?

Comment 4

[Gabriel Chadwick]

You can file a bug. But I think this issue was already debated. I suggest you find the bug that created this error message to look at the debate. I think you would understand. There still is a workaround anyway.

Comment 5

[Paul Bramscher]

Self-signed certificates are legitimate functions of the openssl package.  We use them at the Digital Library Development Laboratory at the University of Minnesota, and you can Google around for other Universities (http://www.sonoma.edu/IT/helpdesk/cert/) doing similar things.  What makes a pre-canned authority an authority?  Do they investigate every request for a cert. signing?  As for security, it hinges on the length of the key/modulus, etc.  I believe that Firefox 3 is deviating away from both Firefox 2.x and MSIE with regard to self-signed certs.  They amount fundamentally to a zone/trust issue, not a "bug".  They need to be treated seriously, to be certain, but they are not bugs.

Comment 6

[Kai Liu]

Yes, you're right that they are almost always used legitimately.  And as the link that you pointed to indicates, the correct solution is to get the users to install the cert first.

As for the zone/trust thing, I agree with that too, except that there's one problem: how does the typical Average Joe user determine that trust, that the cert is by a legitimate party (the university, for example) or by someone pretending to be the university?  The vast, vast majority of people don't even know what a certificate is.  Most never never bother to read the old Firefox 2 certificate warning messages before clicking through.  Ideally, yes, a heavy-handed tactic should not be used, but the reality is far from ideal.

Anyway, the real solution is to get people to install your self-signed cert first.  Keep it simple (the link you provided is one example where what is really a simple process has been made more complicated than it needs to be) and print it in big letters on the first page of the "welcome to our network" welcome packet that companies and schools often give to their new users.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> Self-signed certificates are legitimate functions of the openssl package.

They can be used that way, but they're no longer following the SSL model and the browser can't tell the difference between legit and non-legit uses. You have to use out-of-band means (such as adding an exception or installing an institution's own root cert) to tell the browser it's OK to trust that connection.

> As for security, it hinges on the length of the key/modulus, etc.

There's a huge difference between mere encryption strength and the identity guarantees SSL was designed to enforce. A MITM eavesdropper using uncrackable crypto doesn't help you any. SSL security hinges much more on key/certificate management.

Comment 8

[Paul Bramscher]

Not using the SSL model in what way?  The chief issue here is that the big cert. providers pay $$$ or exert some other leverage to the major browsers to pre-can their CA's in the browser (Thawte, Verisign, etc.)  Are there any .org CA's that come pre-recognized in Mozilla, MSIE or Safari?  This is not really a technology or SSL "model" issue, but rather a business issue.

I don't understand your MITM eavesdropper scenario.  A self-signed cert is merely the establishment of a public/private key pair, same concept in PGP, GNUPG, SSH/SFTP, etc. etc.  This is ultimately a user/zone/trust "issue", not a technology "problem".  Doing it yourself is a good thing, like open source software in general.  Why should anyone have to pay annually for running a few simple ssl commands?

Comment 9

[Kai Liu]

(In reply to comment #8)
> I don't understand your MITM eavesdropper scenario.  A self-signed cert is
> merely the establishment of a public/private key pair, same concept in PGP,
> GNUPG, SSH/SFTP, etc. etc.  This is ultimately a user/zone/trust "issue", not a
> technology "problem".
Certificates are worthless unless authenticity can be verified.  That can be done (1) through a CA vouching for it (expensive, but automatic), (2) through adding the appropriate certificates to the browser beforehand (free, takes one extra small step during setup, but also automatic), or (3) by manually verifying it.  If the certificate is not verified, then you may be subject to a MitM attack.  Of these three methods of verification, the first two do not generate any errors whatsoever in the browser.  Only the third generates an error.  Most users cannot verify a certificate--the vast majority of them have no idea of what a certificate even is.  For them, the error message makes perfect sense because if they cannot manually verify it, then it might as well be an error.  If the user is savvy enough that they can manually verify a certificate, they are not going to care about how onerous the wording of the error is.

This is not unlike SSH asking you to verify the fingerprint the first time you connect to a new server.  Okay, this takes a few extra clicks, but adding an permanent exception is a one-time deal, just like confirming a SSH fingerprint. And if you find yourself doing this a lot, then why not resort to method #2?  Create your own signing cert, sign everything with it, and add the signing cert to your certificate store.

> Doing it yourself is a good thing, like open source
> software in general.  Why should anyone have to pay annually for running a few
> simple ssl commands?
> 
Then don't.  Follow the correct procedure: add the certificate beforehand.  You can play by the "SSL model" without paying a single red cent to any of the CAs.

Comment 10

[Paul Bramscher]

I agree with most of the previous answer.  But let's take the SSH example, in a modern linux environment, you might get a message like this:

The authenticity of host 'x.y.z.com (10.20.30.40)' can't be established.
RSA key fingerprint is ac:77:7f:44:76:1b:ea:dd:f1:1b:b5:b1:34:bc:ec:za.
Are you sure you want to continue connecting (yes/no)? 

You'll note that the message is both accurate and honest.  It tells us that authenticity is an issue, and that you need to accept it (or reject it).  It is not treated, semantically, as an "error".  That's my main quibble, that we need to offer succinct explanatory verbiage.  Certainly, the user might download a bogus cert. as well.  In that sense, it's a regressive problem (user error, not a technology problem).  The solution, IMHO, is to educate the user with a simple explanatory message.  Perhaps similar to what Firefox 2 employed, or an additional sentence or two explaining the risks of downloading/accepting willy-nilly any CA/cert.  With SSH, it's a simple yes/no.  With CA certs, it's now 4 clicks.  Isn't that a little much?

The MITM attack is possible regardless of whether one has accepted a bogus SSL cert, of course.  Indeed, it would be easier to MITM with XSS cross-scripting, packet-sniffing, iframes, imbedded AJAX, etc.  Making the pipe SSL (bogus or not) wouldn't appear to make MITM easier.  What scenario are you thinking?

Comment 11

[Kai Liu]

(In reply to comment #10)
> That's my main quibble, that we need
> to offer succinct explanatory verbiage.  Certainly, the user might download a
> bogus cert. as well.  In that sense, it's a regressive problem (user error, not
> a technology problem).
I agree, but...

> The solution, IMHO, is to educate the user with a
> simple explanatory message.  Perhaps similar to what Firefox 2 employed, or an
> additional sentence or two explaining the risks of downloading/accepting
> willy-nilly any CA/cert.
...this solution is possible only in an ideal world with ideal users.  The reality is such that user education is doomed (SSL has been around for how long now?) and that unless you treat it as a hard error, users will just go about auto-accepting it.  It's not the solution that I'd want, but it's the best solution given that we exist in an imperfect world.

> What scenario are you thinking?
I personally think that MitM attacks are mostly academic.  They are rare in the wild (in fact, most security problems/attacks don't even involve SSL), they usually cannot succeed without some other security breach, and I personally think it's a little silly how much attention MitM is afforded.

But my personal opinion aside, imagine this scenario: I have somehow managed to hijack your DNS and are now your SSL connection to secure.example.com is going to my server instead.  If the forgery was good enough, how could you tell that you have connected to a forgery and not the real server (remember that the address bar will show the correct address, I just used a DNS attack)?  Well, my server would have the wrong certificate.  But if the Joe Sixpack could not authenticate the certificate (because he has no idea what a certificate is), then how would he know that he's at a forgery?  And if Joe Sixpack was presented with a benign message saying "this is the server's fingerprint, do you trust it?", how do you think he would answer?

The reason it takes 4 clicks (actually, it can be reduced to 3 if you change a hidden pref) instead of a simple "yes" that you see in SSH is that the vast majority of Firefox users of the Joe Sixpack variety who could not be relied upon to do the right thing when presented with a self-signed cert, whereas people who use SSH tend to know what they are doing.  Yes, this is a very parental role for the browser to take, and I can understand how it would irritate advanced users, but I can also see how it's really the best thing for most users.

Comment 13

[Nat Tuck]

Simple fact: Treating self-signed SSL certificates as an error makes the internet less secure overall.

Some sites that would be encrypted are not encrypted (allowing eavesdropping attacks) because browsers flip out over self-signed certificates.

If the fear is spoofing, consider this: pages with self signed SSL certificates could be treated just like unencrypted pages - no lock, white address bar. This is significantly less broken than the current behavior which assumes that a self signed certificate is an attack in progress.

Comment 15

[Daniel Roesler]

I would like to propose we re-open this bug in accordance with the recent Mozilla blog post:
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

The original request was to "Please change the message to be less error-oriented." I agree with Nat in Comment #13: Treat self signed certs as if they are http (i.e. unencrypted) connections. This would not prevent an active adversary, but it would prevent a passive adversary and go a long way to addressing IETF #7258 (Pervasive Monitoring Is an Attack, https://tools.ietf.org/html/rfc7258), which is mostly done through passive monitoring.

Here's a proposed implementation:

1. Since Firefox no longer shows http:// at the front of an unencrypted url, we don't have to worry about whether to show https or http for the url. For self-signed certs, simple don't show the https:// at the front of the url.

2. Show the normal unencrypted globe icon in the address bar, as if it were a normal http website.

3. Don't show a warning when connecting to a self-signed cert website.

4. (Optional) Show the normal self-signed cert warning if the domain had previously been an authenticated https connection (i.e. had the lock). This is optional because even if this weren't implemented, websites could still force the same effect by using HSTS on their own. This is just to help those who don't use HSTS from being downgraded from their https connections.