449061 - Gecko based browsers should distinguish between unknown and invalid certificates

Status: RESOLVED INVALID

(Firefox :: Security, defect)

Description

[@4u]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.9.0.1) Gecko/2008071720 (Gentoo) Minefield/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.9.0.1) Gecko/2008071720 (Gentoo) Minefield/3.0

Dear developers,

This bug report should define and track an optimized new certificate handling of Mozilla Firefox 3.0.x as the current one may be seen as a bug:

#431386 and #433422 discusses the invalid behaviour of Mozilla Firefox 3.0.x in connection with a self-signed certificate. As noted there the definition of an "invalid certificate" (as it is shown right now) is just plainly wrong.
#446567 links to a page for the option "expert_bad_cert" ... certificates from unknown sources are not "invalid" or "bad" as they are shown in current versions.

As reported for example at slashdot.org this new behaviour is a violation of net neutrality and should be threaded and corrected with the highest priority available.
http://tech.slashdot.org/tech/08/08/04/0058217.shtml

Why is this the case?

Have a look at https://bugs.freedesktop.org/. This is a trustworthy website with an "unsupported" CA called "CA Cert Signing Authority" (http://www.cacert.org). Now Mozilla Firefox 3.0.x says not that this CA is not trusted. It says "invalid certificate" and in the upcoming dialog it even informs users "that trustworthy websites will not ask users to accept this certificate" which is, sorry for my rude language, a lie.

How should this bug be resolved?

1. Add a "Accept this certificate forever" checkbox and a button to continue using the website without a long four step procedure. Do not open a extra dialog with a mandatory process and unacceptable texts like the "trustworthy websites will never ask you ...".
2. Correctly define self-signed certificates as a "potential security issue" because defined values like company names etc. might be invalid.
3. Auto-download certificates in the certificate wizard for "untrusted" CAs or if the users selects "Accept this certificate forever". Make this process a one-click one.
4. Do never inform users that unknown certificates are not trustworthy. They are unknown to Mozilla Firefox - that's all!
5. As a workaround set "expert_bad_cert" to "true" until this bug has been resolved.

Reproducible: Always

Steps to Reproduce:
1. Visit a https website from a "unknown" CA
Actual Results:  
Users are forced to accept "untrustworthy" certificates to visit trustworthy websites. This will influence user behaviour and they will click through these dialogs without differentiating between "trustworthy but unknown CA certificates" and "certificates from phishing websites".

Expected Results:  
1. A one or two click process to accept unknown but trustworthy = standard complaint certificates.
2. Correct definitions for self-signed and unknown certificates as unknown and not as invalid.
3. Removed text about "trustworthy websites will never ask you ..."

I know that this "new behaviour" is already discussed here at bugzilla and the mailing list - that's why I do not open a "simple" bug report but a "tracking bug" for changing / optimizing the current behaviour. Keep up the good work but please do not think anymore that all users should be treated as DAUs and practical "developer settings" should be hidden in the "about:config" dialog ...

Comment 1

[Kevin Brosnan]

This bug fails more than one of the Principles section of https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html with more than one issue per report the bug will never get closed in a timely manner.

Read bug 215243 carefully as to why caCert is not trusted.

Comment 2

[@4u]

Thanks for your reply - you are right, that it addresses more than "one bug". On the other hand they are all related to the new certificate process and may be seen as one bug. My main problem is the definition of "invalid certificate" and one of the worst examples of user interface design to get an unknown certificate through the "acceptance process".

IMHO this bug report does only violate one principle: "One bug per report" which may be seen otherwise as stated above.

1. Be precise: I hope I am, English is not my native language, so please ignore minor mistakes.
2. Be clear - explain it so others can reproduce the bug: This is easy
3. One bug per report: Well ...
4. No bug is too trivial to report - small bugs may hide big bugs: Ok ... we meet this principle
5. Clearly separate fact from speculation: I hope I did that - please note "facts" if they look like "speculation".

Preliminaries are met and system data is provided.

Comment 3

[Matthias Versen [:Matti]]

There are bugs for each problem in bugzilla and there is no need to add another one. 
BTW: If visit a signed page and the certificate is signed from an unknown CA, then they are not trustworthy. If you thrust the CA then go to the CA site which is hopefully signed from another known CA and install the root certificate from that CA. IMHO it's ok to mark an unknown CA as invalid because it's not secure.

>Users are forced to accept "untrustworthy" certificates to visit trustworthy
>websites.
Why are websites want to be seen as trustworthy if they use certificates from known not trustworthy CA's ?

-> invalid not because of the secure/invalid discussion but because there is no need for such a bug which itself is a dupe.

Comment 4

[@4u]

(In reply to comment #3)
> There are bugs for each problem in bugzilla and there is no need to add another
> one. 

Are you sure? Is there one that discusses / tracks a change to the current process?

> BTW: If visit a signed page and the certificate is signed from an unknown CA,
> then they are not trustworthy.

I agree with that - but still they are not "invalid" as is written in the dialogs everywhere. They are simply not known or not "trustworthy" in a general sense to add them to Mozilla Firefox. This does not mean that they are not trustworthy - I'm sure you will agree that Mozilla can't know (and they do not have to IMHO) "all trustworthy CAs"?

> If you thrust the CA then go to the CA site
> which is hopefully signed from another known CA and install the root
> certificate from that CA. IMHO it's ok to mark an unknown CA as invalid because
> it's not secure.

That's not true from a technical view. It's just easy to have one dialog for all circumstances where the certificate test fails. But end users will just believe Firefox and think that a page is not trustworthy even if it is. That's the wrong direction to go!

> >Users are forced to accept "untrustworthy" certificates to visit trustworthy
> >websites.
> Why are websites want to be seen as trustworthy if they use certificates from
> known not trustworthy CA's ?
> 
> -> invalid not because of the secure/invalid discussion but because there is no
> need for such a bug which itself is a dupe.
> 

I will change the title and description - afterwards please decide if it's still an "invalid report", ok?

My main issue (which is not yet addressed elsewhere) is the questionable definition of "invalid" for all certificates that fail at least one test - even if that's not, what an end user would expect a browser to do.

Comment 5

[Matthias Versen [:Matti]]

that title would make it a dupe of bug 433422...

Comment 6

[@4u]

Thanks for your patience Matthias but I' not sure if this bug report would be a duplicate of #433422 or #431386. These bug reports are only talking about self-signed certificates which are only part of the "bigger bug" introduced with the new certificate manager.

Have a look at:
https://webmail.uni-koeln.de/
https://webmail.aditsystems.de/
https://mail.snv.at/
https://webmail.us.army.mil/

These are either government projects, university webmail systems or larger companies. From an end-user perspective these are all possible man-in-the-middle attackers because they use "invalid" certificates from "untrustworthy" sources (as written in the error page). IMHO end users won't check if the CA is unknown or what's wrong. The trustworthy browser says "these are bad websites. period" From a technical perspective all certificates are just fine.

And the Debian project is not suspect in my eyes either: https://nm.debian.org https://rt.debian.org

So not only self-signed certificates are denounced as "bad certificates" but all unknown ones are as well. So is this a dup? I don't think so. Is it working as designed? I don't think so either. It is maybe a step into a more secure internet but the collateral damage is to high ...

I still recommend to add a "unknown certificates" procedure with one or two simple steps (without an extra dialog to pop up) and leave the current one for "invalid" and maybe self-signed certificates ... but please change the text at least ...

(I accept your point of view - so I only request to have a look at my arguments once more and than decide if this should stay as an "invalid bug report")

Comment 7

[Matthias Versen [:Matti]]

There is no technical difference for the browser if the CA is unknown or if it's a self signed certificate, the browser can not know if it self signed or just a CA that is not in the database. The reason for showing an error is in both cases the same reason. 
The browser doesn't say that they are bad sites, it just tells you that Firefox thinks that the used certificate is from the browsers point of view invalid. Valid means a non broken thrust linkage. Mozilla.org thrusts the required security audit for the CA and the used rules from that CA. The CA itself must be sure that the issued certificate is given to the right person (owner of the domain).
I can create my own CA in 30min and create certificates for every domain I like.

Debian itself isn't suspect of course but the sites security are suspect.
This is working as designed and it's the only wall between an MITM attacker and a secure sites like a Bank for example. MITM is currently very easy done with the DNS poison attack (I hope you know about the weak DNS).

Just an example what an attacker could do:
There is a bank site "bank.inv". The attacker trys to get a certificate for "bank.inv" from a CA that doesn't control the issued certificates as they should or the attacker breaks into weak CAs systems and creates a certificate for "bank.inv".
After that he starts a DNS poison attack either against a not patched DNS provider server or against the client DNS cache (The Mac OS X client is currently unpatched !) and all bank users are getting redirected to the server from the attacker which has a certificate for "bank.inv". You as user get now a warning if the CA is not listed in Firefox database. If the user now just accepts this certificate then the money from the user is lost.
What the browser can only do : Use dramatic wording that the user should not enter any secure data into this page and doesn't make it to easy to override this warning.

Comment 8

[@4u]

(In reply to comment #7)
[snip] 
> The browser doesn't say that they are bad sites, it just tells you that Firefox
> thinks that the used certificate is from the browsers point of view invalid.

Well, in this case it's maybe just a translation error - in German the message in the exception dialog says something similar to: "Trustworthy banks, businesses or public pages will never ask you to do that." My fear is that end users will read this message as "this website is a bad one". And businesses (for example smaller ones) might run their own CA instead of a highly priced signed one from thawte and co. ... and they will ask users to accept the certificate presented ... and maybe they are even trustworthy local service providers ...

[...]
> the DNS poison attack (I hope you know about the weak DNS).

Don't worry, I heart about DNS, the newest (planned ;)) Black Hat presentations and DNSSEC.

[...]
> What the browser can only do : Use dramatic wording that the user should not
> enter any secure data into this page and doesn't make it to easy to override
> this warning.

But think for the children - erm - for users who just believe what's written in their browser windows "The certificate is invalid and trustworthy websites like banks etc. will never ask me to do this" ... so they will just leave because of a (possibly) wrong text or translation ...

Is that the intended behaviour?! Beside from a missing reachable setting under options -> security to switch to an easy accept mode or something similar ...

Comment 9

[Matthias Versen [:Matti]]

A user should leave or should not enter any information in such a site with an error.
"Better safe than sorry".
A usual john Doe can not analyze the problem and can not make a right decision if he can thrust the site or not if the browser shows him an error.

Money is no exception for a self signed certificate in many cases, https://www.startssl.com/ is free.

Comment 10

[Kevin Brosnan]

These are all certs that are signed by unknown authorities. Mozilla cannot
blindly accept organizations into its default set of trusted certificates. Even
Debian or the U.S. Government, doing so starts down a slippery slope. Adding a
certificate authority has a documented process
http://www.mozilla.org/projects/security/certs/policy/.

If you want to discuss this policy
http://groups.google.com/group/mozilla.dev.tech.crypto/ is the correct place
and not this bug.

Comment 11

[@4u]

Thanks for your explanation so far. I personally still have an issue with the wording selected but at least I hope we both see our points of view and I see why you would maybe or maybe not see this a "bug" in our technical view. As this is not the only "bug report" I hope that you as a developer involved see some issues raised here and maybe try to find even better solutions in this case.