Open Bug 433422 Opened 17 years ago Updated 2 months ago

Self-signed SSL certificates should not be labeled as "invalid"

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement

Tracking

()

Status:
REOPENED

People

(Reporter: VanillaMozilla, Unassigned)

References

Details

(Whiteboard: PLEASE READ COMMENT 42 BEFORE COMMENTING)

Attachments

(2 files)

new.png
178.54 KB, image/png
Details
old.png
103.93 KB, image/png
Details
When a self-signed certificate is encountered, the user is informed that the certificate is invalid. In fact, self-signed certificates are allowed under current Web standards, so describing them as invalid might be quite misleading. "Unvalidated" or "unverified" might be a more accurate description of what is actually meant. Most of these invalid-certificate popups are false alarms. The warnings are rather technical as it is, and inaccurate information further confuses an already confusing situation. This bug is about accurate wording, not about behavior. It's fine to raise alarms, change behavior, nudge Web standards, halt browsing, blow horns, etc., as long as the information is accurate and correct. There are previous discussions here: http://forums.mozillazine.org/viewtopic.php?p=3362858#3362858 http://www.dria.org/wordpress/archives/2008/05/06/635
Component: General → Security
QA Contact: general → firefox
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
(While bug 431386 started out as a request to change the behavior, the discussion in that bug later veered a bit towards language, and given the existing discussion that was already in that bug, I thought that a dupe was appropriate; maybe 431386 could be reopened for discussions about the change in language?)
Well, this bug is specifically about language, and it could be fixed by changing a single word. Granted that there is discussion there, veering "a bit towards language" does not morph a bug. I can edit the description of that bug, but I'd get my knuckles rapped for it. And I can't edit comment 0 or the ensuing discussion. Ergo, there is no way to properly discuss this bug over there. Can you please reopen this one? Thanks.
I think it may be worthwhile to keep the discussion from fragmenting into too many bugs, but I'll let someone else decide if it's a dupe.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I find the new self-signed certificate process in Firefox 3 to be truly awful. I was not in love with the firefox2 way of handling the acceptance of self signed certs but compared to firefox3, it was much better the old way. I would like to request that firefox 3 re-implement a certificate wizard like firefox 2 has. When presented with a self-signed cert, a user should be provided with a modal dialog explaining what is happening. Encryption should always be a bigger concern than trust (provided the certificate does not conflict with a previously accepted cert for the same host). The new dialog is confusing and is not adequately flexible for non-basic users. In an ideal world, untrusted certs should be retrieved and displayed in the security dialog with at least 3 options: Accept Temporarily, Accept Permanently, Cancel (and possibly Inspect which might allow a user to look at the certificate and connection details in another dialog).
The wording is wrong. A certificate is not invalid, just because it's self-signed. And why does FF stop me from viewing that page? My MUA doesn't stop me from reading an email, just because the signing key is untrusted. There should be information, maybe in the status bar, about the status of the certificate: valid, invalide, trusted etc. but not the necessity to do something about it. What's worse, I don't have the chance to say I don't trust the certificate but I don't care. The only work-around for this bug is to add the certificate and so I lose the information that I don't trust it. How does that help security? No matter what you do, most people don't understand what certificate are and how to check them. If your online banking account is protected by a certificate, it's the bank's duty to inform the customer about how to make sure they don't fall in the hands of a fraud. Nothing FF can do about it. This whole idea of ultimately trusted CAs is flawed anyway and only leads to a false sense of security. Why should I trust a cert by one of the pre-added CAs more than a self-signed one? I don't know how those CAs check the certs or how well they protect their keys. And frankly, I don't care. Maybe tomorrow the CA is sold and the new owner doesn't care at all for security. I only trust a view certificates the validity of which I have checked my self. The others I don't trust, whether they are self-signed or signed by VeriSign. The idea is that I know whether I view a phony online banking site (because I have verified the cert and added it) and I don't care for the rest. But this approach is not supported by FF. I can either add a certificate or not view the site. Hell, I can't even delete all those pre-added CAs easily, because you can't select all the entries at once. They can only be deleted one by one. So while FF hinders me in the name of security, it doesn't support a real security centered approach
I agree that the wording is incorrect, and Harry, you make a great point about self-signed certs possibly being just as trustworthy (or more so) than those signed by the included bunch of CAs (I trust my own server more than anyone else's). A self-signed cert is not invalid, it's simply self-signed.
You guys completely misunderstand PKI and the functions of CAs. The problem is, that nobody else can rely on your self-signed certificates (besides yourself), however certificates are for the relying parties, not the server operator. Just my $0.02
Excuse me, but as a network administrator, if I use a self-signed cert for webmail access on a server *I* built, and then send instructions to 150 users as to how to access webmail, they will each receive a warning about the cert on the server being self-signed. There is NOTHING - not a BLESSED thing - wrong with the cert. It is *NOT* invalid. However, I will get a slew of support tickets opened up telling me that there is something wrong with the server. Please do not tell me that I "completely misunderstand PKI and the functions of CAs." I hold three certifications from Novell, and have been thoroughly tested on CAs and the entire PKI architcture on both NetWare and Linux. None of this has anything to do with Firefox misleading the end user about a cert which has been signed by - as far as the user may know - a *known* party, vs a CA which is already in the trusted store. please *read* the text of this bug before commenting.
(In reply to comment #9) > Excuse me, but as a network administrator, if I use a self-signed cert for > webmail access on a server *I* built, and then send instructions to 150 users > as to how to access webmail, they will each receive a warning about the cert > on the server being self-signed. In that case I'm sure that you also know to instruct them how to install your root certificate or self-signed certificate into the browser. This will also guaranty that your users are only accessing your site and not a MITM. > Please do not tell me that I "completely misunderstand PKI and the functions > of CAs." I hold three certifications from Novell, and have been thoroughly > > tested on CAs and the entire PKI architcture on both NetWare and Linux. In that case you really should know better. > > None of this has anything to do with Firefox misleading the end user about a > cert which has been signed by - as far as the user may know - a *known* party, > vs a CA which is already in the trusted store. please *read* the text of this > bug before commenting. > The browser can't know for which purpose a certificate is going to be used. Perhaps for your internal network and a limited set of users, your self-signed certificate might be sufficient, depending on the policies you implement and ways for key distribution. However the browser is build for a majority of users which are not your own, but anywhere on the globe who might access any site signed by invalid and/or self-signed and/or unknown roots etc. The browser can't start a guessing game about which self-signed certificate might be for a legitimate purpose and which one is set up to commit a fraud. Today you don't have to rely on self-signed certificates. There are certificates from CAs which are recognized by Firefox starting from totally free to very cheap ones. Those CAs are conforming to the Mozilla CA policy and have been audited, which your self-signed doesn't.
(In reply to comment #8) > You guys completely misunderstand PKI No, it's you who misunderstands PKI. It's all about trust: 1) How much do I trust that my peer is who he says he is. In case of X.509 certificates that means, how much do I trust that the public key really belongs to the entity given in the subject. 2) At least as important as 1): How much trust is needed for a certain purpose. E.g., I don't trust bugzilla.mozilla.org's certificate, but I don't care. I do care about the certificate of my online banking site, because there money is involved. These are not technical problems and cannot be solved by technical means, no matter how much PKI you throw at them. They are always decisions to be made by the user in a certain situation and for a certain purpose. PKI can only help you in implementing these decisions. It is however a technical problem of how to store that decisions and how to present them to me and that is where FF fails. I can always remove or add certificates. So FF supports 1) But FF does not support the case "not trusted but don't care". Whenever a certificate is not trusted (i.e. not added to the list of certificates) FF prefents me from visiting a page.
(In reply to comment #11) > It's all about trust: Yes, why not...and here is defined how Mozilla trusts certificates and their issuers: http://www.mozilla.org/projects/security/certs/policy/ > Whenever a certificate is not trusted (i.e. not added to the > list of certificates) FF prefents me from visiting a page. Right, you must add an exception in order to visit the page. That's the way you can override the built-in decision taken by Firefox. Firefox allows you to do that and Firefox doesn't care either if you really care about a certificate or not. It simply gives you the tools to do so. I guess that should be sufficient.
None of what you have said alters the fact that "untrusted" is *not* equivalent to "invalid." Harry hits the nail on the head: It's all about trust. Citing MF's rationale for what CAs are included in the browser is beside the point; I don't want them to include my internal-use-only CA in their browser. What I *would* like would be for FF to differentiate between an expired or malformed cert (invalid) and merely one signed by an unknown CA (untrusted). That is what this bug is supposed to be discussing, not the pros & cons of obtaining a free cert from an already trusted CA.
Aha! Actually I referred to the deeper meaning of self-signed certificates and perhaps reacted after reading comment 5 but also comment 6. In both comments there is an in-depth description about how awful Firefox handles self-signed certificates and how "the whole idea of ultimately trusted CAs is flawed anyway" blah, blah.... I personally don't care if it's now called invalid or untrusted or any other indication about its status. Perhaps untrusted was actually not used in order to not emphasize the "trust" word too much and "invalid" was chosen.
(In reply to comment #14) > In both comments > there is an in-depth description about how awful Firefox handles self-signed > certificates and how "the whole idea of ultimately trusted CAs is flawed > anyway" blah, blah.... Yes it is, but this is not so much my problem, because, as I've already pointed out in #11, FF has good support for implementing my own trust decisions (I can easily add and remove certificates). > I personally don't care if it's now called invalid or untrusted or any other > indication about its status. Perhaps untrusted was actually not used in order > to not emphasize the "trust" word too much and "invalid" was chosen. The most important issue when it comes to security is to make people understand what's going on. While this is hard for people who don't know much about the issue, at least tell them what's really going on instead of trying to scare them with FUD. For me personally the wording is only a minor flaw, because I know that self-signed != invalid. The problem is, that it is not only spelled invalid, but that FF acts as it really where invalid, i.e. by preventing me to visit the page. I want an option to move this information to the status bar, or wherever I can see it without stopping me from not caring about the trust of a certain certificate. The only option I have now, is to trust the certificate (add it to the list), which usually is not my intention. So it is impossible to separate certificates I trust from certificates I don't trust but don't care.
My general thoughts: One of the founding principles of the free and open source software movement(s) is that people come together in free associations to build/debug/study/improve quality software. The warning over self-signed certificates makes no mathematical/algorithmic claim as to the strength or weakness of the cert. It does, however, underscore that there exists no "trustworthy" or free certificate authority pre-loaded into the browser. The "authority" as currently conceived is totally non-open source in spirit/nature. Perhaps if Mozilla allowed a free/open community to emerge and introduce its CA into the Firefox browser (producing certs free of charge), the problem would be alleviated. It remains somewhat paradoxical, we may be forced to admit, that the browser is free/open -- but there are no free/open cert. authorities. Indeed, if we can't trust *that* free model, how can we trust the browser itself? I'm jaded on the issue, and see it largely driven by "lobbying" economics -- not ordinary free/open software dynamics. What are the rules to get one's CA pre-loaded into Firefox currently? I've been unable to locate them online. What sort of auditing does the Mozilla community conduct to ensure that these CA's maintain high QA and professional standards, conduct identity checks, etc? The lock should certainly remain in the status bar -- because the page is indeed encrypted. Maybe we need three kinds of locks: (1) A lock for for-profit cert. authorities (maybe put a dollar sign next to it). (2) A lock for (potential) free cert. organizations that would likely emerge if the pre-loaded CA market were more open. (3) A lock for self-signed certs (put a human there). (Indeed, it's conceivable that we could have a favicon concept alongside the lock. Restricting security management to a small handful of highly connected players seems wholly inimical to open source models, and perhaps free market principles as well.)
Hi Paul, (In reply to comment #16) > The "authority" as > currently conceived is totally non-open source in spirit/nature. CA certification services are not about source at all! The CA you apparently refer to and which I happen to operate is the most open "legitimate" CA in every respect and where it matters. > Perhaps if > Mozilla allowed a free/open community to emerge and introduce its CA into the > Firefox browser (producing certs free of charge), the problem would be > alleviated. Mozilla allows any CA which adheres to its CA policy to be included. Mozilla tries to include as many CAs as possible without compromising the security of its users. In that respect, Mozilla follows the principals of an open, secure Internet! > > What are the rules to get one's CA pre-loaded into Firefox currently? > Here you go: http://www.mozilla.org/projects/security/certs/policy/ And here is the list of the currently pending and processing CAs: http://www.mozilla.org/projects/security/certs/pending/ Here the ones which were included since March 2007: http://www.mozilla.org/projects/security/certs/included/ BTW, I happened to make this argument various times at different occasions: The pricing policy is not a know criteria for CAs. I proved that! And again, self-signed certificates are simply useless to any relying party...
(In reply to comment #16) > The "authority" as > currently conceived is totally non-open source in spirit/nature. Perhaps if > Mozilla allowed a free/open community to emerge and introduce its CA into the > Firefox browser (producing certs free of charge), the problem would be > alleviated. I don't think that's a problem. TLS and X.509 are specified in RFC and so it's quite open. Everyone can be a CA. Just create a certificate that says "I'm a CA certificate". That's actually how it works most of the time. That's why there are a lot of self-signed certificates or company certificates, that don't rely on an external third party. While I think that it is not useful to pre-add any "trusted" certificate, because whom I trust can't be decided by Mozilla, others think differently and I don't have a problem with that. What I do have a problem with, however, is that FF 3 forces it's very narrow idea of security on me, which is: either the certificate is trusted or I won't show the page. It doesn't give me the choice to follow my own idea of security, which is: most of the time I don't care if the certificate is trusted, only warn me about the view certificates I do care about. I also don't see what ever more annoying warnings would gain. When you have been bothered by the security warning 5 times the latest, you will find out about "browser.xul.error_pages.expert_bad_cert=true" and "browser.ssl_override_behaviour=2" to reduce adding an exception to 2 clicks. Adding exceptions will become automated without even reading the warning, like it happens with all annoying frequent warnings, that users have to click away. Soon you won't know, which certificates you really trust and which you have just added to make FF3 shut up and do what it was intended to, i.e. show web pages.
Thank you for the URL's. Let's not confuse self-signing with rolling your own CA. My tutorials (on both) have been hit tens of thousands of times (http://www.tc.umn.edu/~brams006/selfsign.html) by government, academia, and the corporate/private sectors. Self-signing and home-made CA's are used everywhere in research and test environments, small shops, intranets and for special needs. I use them professionally as a programmer at a Big-10 US university, and have saved thousands of dollars in doing so. Why should I spend a few hundred dollars for something I can do in 5 minutes? This may suggest a separate bug report, but Firefox 3.x also requires about 4 clicks in order to accept a new CA and treats them as "errors" with an error code message. Again, this runs counter to the spirit of open source software. I hope the Mozilla group isn't trying to "boil a frog" here and eventually make self-signing and home-made CA's impossible altogether. We've encountered this issue with PGP and other public/private encryption methodologies and while trust rings exist, there are means for ordinary people to exchange key "fingerprints", etc. to ensure identity, etc.
(In reply to comment #19) > Self-signing and home-made CA's are used > everywhere in research and test environments, small shops, intranets and for > special needs. They can certainly be used in research and test environments, but perhaps not for small shops etc. Firefox doesn't prevent you to import your CA root into the browser (for testing, research and anything else). By importing the CA root, you don't have to add any exceptions for your sites. > I use them professionally as a programmer at a Big-10 US > university, and have saved thousands of dollars in doing so. Why should I > spend a few hundred dollars for something I can do in 5 minutes? Oh, you can get them for free and completely legitimate in about the same time or even less then that: https://www.startssl.com/ You don't have to pay a dime and Mozilla's security and that of its users don't have to be compromised because for your need to facilitate self-signed certs. > > This may suggest a separate bug report, but Firefox 3.x also requires about 4 > clicks in order to accept a new CA and treats them as "errors" with an error > code message. Again, this runs counter to the spirit of open source software Who said that? Aren't you glad that those useless pop-up warnings can't be simply clicked away? A whole generation has been educated to ignore any errors and warnings in respect to SSL certificates. Should the truly open source browser be also negligence?
Correct me if I am wrong but startcom (http://www.startssl.com/) certs are free and are out of the box trusted by firefox. When I upgraded to firefox 3, this bug prompted me to finally search out a trusted cert because Firefox's cert handling is so abysmal. (In reply to comment #16) > My general thoughts: > > One of the founding principles of the free and open source software movement(s) > is that people come together in free associations to build/debug/study/improve > quality software. The warning over self-signed certificates makes no > mathematical/algorithmic claim as to the strength or weakness of the cert. It > does, however, underscore that there exists no "trustworthy" or free > certificate authority pre-loaded into the browser. The "authority" as > currently conceived is totally non-open source in spirit/nature. Perhaps if > Mozilla allowed a free/open community to emerge and introduce its CA into the > Firefox browser (producing certs free of charge), the problem would be > alleviated. > > It remains somewhat paradoxical, we may be forced to admit, that the browser is > free/open -- but there are no free/open cert. authorities. Indeed, if we can't > trust *that* free model, how can we trust the browser itself? I'm jaded on the > issue, and see it largely driven by "lobbying" economics -- not ordinary > free/open software dynamics. > > What are the rules to get one's CA pre-loaded into Firefox currently? I've > been unable to locate them online. What sort of auditing does the Mozilla > community conduct to ensure that these CA's maintain high QA and professional > standards, conduct identity checks, etc? > > The lock should certainly remain in the status bar -- because the page is > indeed encrypted. Maybe we need three kinds of locks: > > (1) A lock for for-profit cert. authorities (maybe put a dollar sign next to > it). > (2) A lock for (potential) free cert. organizations that would likely emerge if > the pre-loaded CA market were more open. > (3) A lock for self-signed certs (put a human there). > > (Indeed, it's conceivable that we could have a favicon concept alongside the > lock. Restricting security management to a small handful of highly connected > players seems wholly inimical to open source models, and perhaps free market > principles as well.) >
Irrespective of whether self-signed certificates are a good idea or not, people still use them and FF could do better in terms of usability when it encounters one. Here is what I suggest in terms of improvements: 1. Be more explicit about the fact that the certificate is not trusted, as opposed to invalid. 2. Add the details of the certificate's issuer so that users see all the information that FF has available in order to take an informed decision whether to trust the site or not. 3. Give the user the option to trust the certificate for this session only. Make sure that option is available in a single click.
(In reply to comment #20) > Who said that? Aren't you glad that those useless pop-up warnings can't be > simply clicked away? A whole generation has been educated to ignore any errors > and warnings in respect to SSL certificates. Should the truly open source > browser be also negligence? And now a whole generation is educated to ignore any errors and warnings in respect to SSL certificates, that need 4 clicks to get rid of.
(In reply to comment #22) > 3. Give the user the option to trust the certificate for this session only. > Make sure that option is available in a single click. 4. Give the user the option to view sites with untrusted certificates with _no click_ at all. Untrusted certificates are not a security threat. For 99% of TLS encrypted sites it doesn't matter that the certificate is not trusted, because the user doesn't enter any sensitive data. And it gets really hard to have a close eye on those sites for which it matters, because the certificate store will be filled with uncountable certificates that just have been added to convince FF to do what the user wants, which is to view web pages.
(In reply to comment #23) > And now a whole generation is educated to ignore any errors and warnings in > respect to SSL certificates, that need 4 clicks to get rid of. > The answer for you is Yes! :-) For all the others, it educates users to not ignore the warning, to web sites owners to secure their sites adequately at last... (In reply to comment #24) > Untrusted certificates are not a security threat. They might potentially be exactly that. There is no way to know if there is a MITM or not. That's what's all about. The only way a self-signed certificate *might* be useful is, when you are the only one connecting ever to that site and you know its fingerprint (and also check in on every visit). No other party can rely on it and should you haven't know, digital certificates are for the relying parties, not for the web site owner. I just thought to mention it, because there is many times a misconception about for whom certificates actually are intended. > For 99% of TLS encrypted > sites it doesn't matter that the certificate is not trusted, because the user > doesn't enter any sensitive data. Oh, than why secure the site anyway? Why not plain text? For all the rest, a self-signed certificate is worse than plain text, because it easily may give a relying party the wrong impression that it's secure, which it's not (MITM). (I view passwords as sensitive information and I guess you do as well) > And it gets really hard to have a close eye > on those sites for which it matters, because the certificate store will be > filled with uncountable certificates that just have been added to convince FF > to do what the user wants, which is to view web pages. > Just to view a site, try plain text or add an exception. There must be a reason (or not) why as site wants to be secured. Better use plain text if there is no obvious reason to secure a site... Just for the record, in this discussion it seems like I'm the advocate for the UI decisions of the current Firefox, which I'm not. Those decisions were taken by people much smarter than me and and which are UI specialists ;-)
(In reply to comment #25) > The answer for you is Yes! :-) > > For all the others, it educates users to not ignore the warning, to web sites > owners to secure their sites adequately at last... Actually no. I have very strong feelings towards useless GUI obstactles and get angry every time I encounter them. Other people are more laid back, commit the 4 clicks to their muscle memory and never think about them again. I envy them. > They might potentially be exactly that. There is no way to know if there is a > MITM or not. That's what's all about. True, but I don't always care about that. Will FF show you errors for sites not using TLS in the future, because there could be a MITM? > The only way a self-signed certificate *might* be useful is, when you are the > only one connecting ever to that site and you know its fingerprint (and also > check in on every visit). In that case I wouldn't check on every visit, I'd just add the certificate to the store, because if I can verify the fingerprint, I can trust the cert. Anyway, there is no problem with self-signed certs in FF, there is a problem with untrusted ones, be they self-signed or not. > Oh, than why secure the site anyway? Why not plain text? For all the rest, a > self-signed certificate is worse than plain text, because it easily may give a > relying party the wrong impression that it's secure, which it's not (MITM). That's a problem of how FF presents the information about an untrusted cert to the user, and there must be a better way then saying the cert is invalid and stopping the user from visiting the site. > Just to view a site, try plain text or add an exception. There must be a reason > (or not) why as site wants to be secured. Better use plain text if there is no > obvious reason to secure a site... And how is that my decision to make? Remember that I'm the one who wants to view the site, not the one who sets it up. And yes, there are reasons. Maybe the site offers some service that needs protection (e.g. a login) but I don't use it, I just want to view it. > Just for the record, in this discussion it seems like I'm the advocate for the > UI decisions of the current Firefox, which I'm not. Those decisions were taken > by people much smarter than me and and which are UI specialists ;-) Oh, so specialists decided that? It must be good, then. To re-iterate: it's not just a GUI problem. The error message, saying that an untrusted certificate is invalid is just wrong and the steps I have to take are annoying. But even if I go through them, I don't get the option to continue without adding (i.e. trusting) the certificate. And that's a regression, because it's a perfectly valid and frequent use-case.
(In reply to comment #26)Other people are more laid back, commit the > 4 clicks to their muscle memory and never think about them again. I envy them. > My experience shows that web site owners are getting their act together and start to secure their web sites correctly. There is certainly a strong tendency into this direction. > Will FF show you errors for sites not > using TLS in the future, because there could be a MITM? If you try to submit information via plain text, than yes. Firefox will not complain if the cert is "trusted" or you explicitly trust it. In that sense, the answer is yes. > That's a problem of how FF presents the information about an untrusted cert to > the user, and there must be a better way then saying the cert is invalid and > stopping the user from visiting the site. > Firefox isn't stopping the user from visiting the site, but forces the user to make a conscious decision. In my opinion this is a good thing, but I think we agree that we not agree on this :-) > And how is that my decision to make? Remember that I'm the one who wants to > view the site, not the one who sets it up. Don't! Or be aware about what it means! Ping the webmaster of the site to actually do something about it (that would be the best really). > annoying. But even if I go through them, I don't get the option to continue > without adding (i.e. trusting) the certificate. Of course you do! You don't have to add the certificate permanently...this is what I usually do when encountering such a site.
(In reply to comment #26) > To re-iterate: it's not just a GUI problem. The error message, saying that an > untrusted certificate is invalid is just wrong and the steps I have to take are > annoying. But even if I go through them, I don't get the option to continue > without adding (i.e. trusting) the certificate. And that's a regression, > because it's a perfectly valid and frequent use-case. I don't understand what meaning you're imputing to "trusting" the certificate that is different from navigating to the site. Permanently trusting the certificate is different than temporary, of course, but trusting is nothing more than "accept this certificate for the purposes of encrypting communications with this site." What am I missing about your concern in this regard?
PMFJ(B)I... The thrust of this bug report is that self-signed certificates should not be treated as invalid, thus requiring four steps to accept them (even temporarily) in FF3 (by default) or two steps (thanks for the tip, Harry!). If I have webmail deployed for 30 users in an organization, and Novell GroupWise out of the box configures for using a cert from Novell Certificate Manager, the CA is the signing server (NetWare, Linux, or Windows). This CA is unknown to FF3, and therefor, untrusted. that doesn't make the certificate invalid. It is a waste of my time and resources to perform either of the following: 1) Obtain a cert from a trusted (by FF3) CA, install it, and reconfigure GroupWise; or 2) Explain to 30 users that the invalid certificate information is incorrect, that it can be safely ignored, and to just click through four different prompts to accept the cert (most of these people can barely get through the whole webmail ordeal, let alone manage certificates). An unknown CA is just that: unknown. FF3 needs to distinguish between an unknown CA signing a cert and an invalid cert (due to a malformed cert or a server name mismatch). MITM compromises are not really at issue here (yes, they could be - in extreme cases - but this is not the purpose of this bug). Quite often, such situations involve connecting via IP address and not DNS, making MITM more difficult and less of a concern. No matter; the concern is for management to handle, not for FF3 to determine. As a suggestion, a pref should be added to allow for status bar warnings of self-signed cert and/or untrusted CA instead of forcing the user to walk through a misleading (concerning "invalid" status) set of prompts merely to accept a self-signed cert (or one which has been signed by an unknown - hence, untrusted - CA. I partocularly like Paul's and Bruno's ideas as expressed in comment #16 and comment #22, with the added idea of an override to bypass all prompts and just alert me in the status bar to the condition of the cert (didn't Communcator 4 work this way? it's hard to recall, now). Harry's point, Johnathan, is that the warnings become obstacles (as designed) to simply accessing the site, forcing one to accept (via multiple prompts vs automagically) temporarily (or permanently, though that's not a requirement, here) a self-signed cert. (Harry, if I've misstated your contention, please feel free to correct me, but I do believe that we're of one mind on this.) Cheers.
(In reply to comment #29) > 1) Obtain a cert from a trusted (by FF3) CA, install it, and reconfigure > GroupWise If that's too much for you, I can't help...that's what every admin does with any application he installs and provides services for. It's part of setting up any mail, http, imap, pop3 and whatnot server...sorry, laziness isn't a good justification for compromising the security of 180 million users. > > An unknown CA is just that: unknown. FF3 needs to distinguish between an > unknown CA signing a cert and an invalid cert (due to a malformed cert or a > server name mismatch). > In either case FF3 protects you from accessing the site without a conscious decision from your side. I think that's as intended. If the CA is unknown, distribute the root of that CA to your users and everything should be fine. This is really what I'd suggest for the situation you mentioned above (if you prefer that instead of using a "known" CA). > MITM compromises are not really at issue here (yes, they could be - in extreme > cases - but this is not the purpose of this bug). Quite often, such situations > involve connecting via IP address and not DNS, making MITM more difficult and > less of a concern. No matter; the concern is for management to handle, not for > FF3 to determine. Oh, perhaps you need to explain what the browser's task is in respect to SSL certificates if not preventing an MITM attack! And what exactly does your management has to do with preventing me visiting a site which might be compromised in this way or the other, including DNS cache poisoning and MITM? > Harry's point, Johnathan, is that the warnings become obstacles (as designed) > to simply accessing the site, forcing one to accept (via multiple prompts vs > automagically) temporarily (or permanently, though that's not a requirement, > here) a self-signed cert. Why are you insisting of trying to solve the problem the wrong way if the solution is very obvious and easy to achieve? I don't get it...why insisting on self-signed certs if there are enough alternatives which don't inherit the problems you try to avoid?
Please stop using bugzilla as a discussion forum, and stop using it as a venue for advocacy. Using bugzilla for advocacy is a way to get one's bugzilla registration revoked. Advocacy belongs in mozilla's newsgroups. Bugzilla reports should be used to 1) report a bug, including steps to reproduce, 2) discussion among the responsible DEVELOPERS about any potential fix (If they accept that it's a bug) 3) request that a potential fix be tested 4) report the result of such tests.
(In reply to comment #4) Kai, I think you see the value of this bug now, and it's probably not what either of us envisioned. ;-) Gentlemen, Please read comment 31 and https://bugzilla.mozilla.org/page.cgi?id=etiquette.html .
I don't like that Firefox treats me as if I should be prevented by all means from connecting to a website - no matter if the certificate is self-signed, or if there is a small misconfiguration at the other end. The current practice completely misses out on the fact that SSL is completely broken as authentication scheme, and makes its use as data-encryption scheme between two (unauthenticated) points painful. A warning is OK. Displaying the details is OK. Putting half a dozen roadblocks to be clicked away by the user each time he wants to connect to a site with a self-signed certificate is definitely not OK. This is a regression over Firefox 2. Please revert. Firefox prevented me from using Yahoo: <http://panospace.wordpress.com/2008/08/12/yahoo-unsafe-or-firefox-wrong/>
Some evangelism to add. I'm posting this now from Pittsburgh airport (KPIT). Were it not for a self-signed certificate, I wouldn't be online. Everybody in this airport had to configure their browser to accept a self-signed certificate in order to make it through the captive portal. Some people, using other browsers, had it easy. Others, using Firefox, had a more difficult experience. This is a genuine real-world scenario that is standing in the way of greater Firefox adoption, for reasons stated many times by earlier comments by others in this bug. Thanks for reading this!
You *hope* you were connecting to the portal. Maybe you were connecting through the laptop of some guy just back from DefCon 16 testing out some of the new goodies demonstrated there. Whoever set up that network should be fired, I can hardly think of a better opposite of any situation where an untrusted certificate could legitimately be used.
There are perhaps some misunderstandings what a self-signed (or self-made CA) certificate is all about. When you first ssh to a box and are prompted with the "do you accept the key?" message, you -- as a programmer, developer, or account holder on that machine -- must make the judgment call whether it is a valid ssh key. If you've ever set up SSH keys, if you've ever set up PGP/GnuPG/etc. you'll understand fingerprints, etc. The chief difference with corporate-stamped certificates is that the trust decision is removed from the user (and the user must instead trust that all of the pre-canned CA's in major browsers are themselves legitimate, etc.). In a sense, it can become a regressive problem. I'm a senior developer at a Big-10 university and we use them all the time. The chief point that these messages suggest to me is that perhaps SSL needs to borrow from the SSH and PGP models, which probably lean on the same RSA algorithms and public-private key concepts. Browsers should consider not simply a padlock, no padlock or half a padlock. But rather a variety of certificate authority indications (self-signed, self-made CA, etc.) It's a gross overstatement to suggest that the self-made CA (a little different from a self-signed cert, but same issue) is indicative of some sort of attack. When you make the certificate, you bind it to a particular host. If the person doesn't control that host, you get a totally different warning from Firefox (a warning to the effect that the certificate is a domain mismatch). That's far more serious than a self-made CA. If someone makes a cert bound to xyz.com, and he owns xyz.com, there will be no domain mismatch message -- although there will be an untrusted CA message. If he doesn't own xyz.com and is trying to spoof it, the end-user will still get the untrusted CA message: but he'll also get the domain mismatch message. I hope this clears up some misunderstandings.
Fix this bug immediately, please. I am on the verge of heading to IE because of it and often use IE because I simply can't stand having to clear all of these certificates over and over. If I allow a certificate, it should ALWAYS and FOREVER be allowed, period.
It seems you haven't understood PKI yet...I can make a certificate for xyz.com and spoof or poison your users DNS server and I'm certain that 99% of the user will click through a simple warning - the same way they clicked through the first time they accessed your sites. Importing and trusting your CA is the solution to the problem, not making meaningless self-signed certificates the rule. Supposed your users trust your judgment to whom and to which sites you issue certificates, they will never again have to perform a special action when encountering your certificates. Just for the record, PKI isn't about self-signed certificates. A Public Key Infrastructure's only self-signed certificate is usually the CA root. And as you probably know, CA roots shouldn't function as web server certificates. Promoting SSH and PGP, as if that comes anywhere close to a Public Key Infrastructure just shows the missing knowledge of some folks here about this subject.
Comment 38 was in reply to comment 36. Can we close this bug now?
(In reply to comment #35 & #38) PLEASE!!!!! Read Nelson's comment #31. This is not a mailing list or discussion forum. Those who feel that this is a legitimate bug should vote for it to be fixed and/or provide some code to patch it. Those who want to sell certificates to people - for whatever reason - should ply their trade elsewhere, and those who wish to discuss the pros and cons of self-signed certs should move the discussion to MozillaZine or the newsgroups.
(In reply to comment #40) > Those who want to sell certificates to people Please read the comment carefully and make some research before making accusations!
Please read the bug description CAREFULLY before commenting. THIS BUG IS ABOUT THE WORDING OF THE MESSAGE, NOT ABOUT BEHAVIOR. Please obey Bugzilla etiquette and confine your comments to the carefully define subject of this bug.
Whiteboard: PLEASE READ COMMENT 42 BEFORE COMMENTING
In reply to comment #35, yes, the overall network was insecure and should be treated as such. No encryption was used on the wireless network at all. The self-signed cert was somewhat useless: the only purpose of it was to be a roadblock. There was a captive portal that redirected all connections to a HTTPS site displaying a disclaimer message. Once you clicked "Yes", you were redirected back to the main HTTP site of the airport and were then allowed to browse freely. The important thing is that you weren't allowed to go anywhere else online unless you did complete that initial HTTPS connection, thus requiring the acceptance of the self-signed cert. In reply to comment #42, is there another bug open yet for the behavior, not the wording, of this bug about self-signed certs? People are gravitating towards this bug number here because it's the most relevant so far.
(In reply to comment #43) > In reply to comment #42, is there another bug open yet for the behavior, not > the wording, of this bug about self-signed certs? People are gravitating > towards this bug number here because it's the most relevant so far. I just entered one. Bug 452335
Here's how Google Chrome does it: "You attempted to reach [site obscured].com, but the server presented a certificate issued by an entity that is not trusted by your computer's operating system. This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications. You should not proceed, especially if you have never seen this warning before for this site." Notice that it gives correct information and does not say it's invalid. You can also press a button to get more information.
(In reply to comment #45) > Here's how Google Chrome does it: > > [snip] > > Notice that it gives correct information and does not say it's invalid. You > can also press a button to get more information. How many people are going to read all of that? And then fully comprehend what it means? It is more approachable than most SSL messages, but that's not saying much... IMHO, what Chrome does get right, however, is using "not trusted" instead of "invalid" in the big bold text on the page, not because it's technically correct (which it is), but mostly because that's something that users will better comprehend ("'Invalid?' What the heck does 'invalid' mean in this context?!"). Invalid is too broad a term and is more like "error", whereas "trust" is a more accessible concept.
Right. So can we get that word changed?
Slashdot: "Security Certificate Warnings Don't Work": They then brought 100 people into a lab and studied how they surf the Web. They found that people often had a mixed-up understanding of certificate warnings. For example, many thought they could ignore the messages when visiting a site they trust, but that they should be more wary at less-trustworthy sites. This shows how people make trust decisions and what the technology tries to implant into people do not match that well.
It's been a year since I last discussed on this bug. As I understood it, we had last decided that we would cause pain and annoyance for all web browser users in the hope that this would cause hardware vendors to ship 'more secure' hardware. Have we made any progress on this? Are the linksys routers coming out with embedded signed certificates? If we're still in the same place next year, can we go back to having simple SSL self-signed verifications?
(In reply to comment #48) From http://www.infoworld.com/d/security-central/security-certificate-warnings-dont-work-researchers-say-725?source=IFWNLE_nlt_sec_2009-07-27 please note: In the Firefox 3 browser, Mozilla tried to use simpler language and better warnings for bad certificates. And the browser makes it harder to ignore a bad certificate warning. In the Carnegie Mellon lab, Firefox 3 users were the least likely to click through after being shown a warning.
reply to comment #50 if the goal is to prevent users from clicking through, Firefox 3 does indeed an excellent job - so good that also clicking through to legit sites encrypted by self-signed certificates is significantly affected. It's not the language of the warnings, it's the number of clicks. Look at Opera for a clean and acceptable implementation. When will Firefox finally understand that its users are not all stupid monkeys? The five screens and clicks that I *must* go through to approve the connection to a self-signed SSL site are an offense to the intelligence of the vast majority of users. And for the stupid ones: caveat emptor.
If someone needs such a hostile warning message to know if a site could possibly hurt them, then they probably have already done something stupid like install a malware removal app which, in fact, was spyware-- and no amount of warning messages issued by Firefox is going to protect their information then. Don't use RED. Use YELLOW to indicate caution. The "Get me out of here!" button has to go. That makes it look like their computer is about to catch fire. Use something like: <img src="caution-triangle.png"> <h1>website.com is using a self-signed certificate</h1> <p>This could mean one of two things: The website operators have chosen to generate their own certificate rather than use a CA trusted by Firefox/Mozilla. It could also mean that an attacker is trying to intercept your communications. <p> <button>Ignore warning and continue</button> <button>Leave site</button> A self-singed certificate is pretty easy to determine. It usually lists the domain name as the COA For not trusted COAs, it should say "the certificate used by website.com not issued by a CA trusted by Firefox/Mozilla." It should be a 1-click bypass. That's it, done. If the user was an idiot enough to need more than 1 click to keep from making a stupid decision, then they've probably already downloaded and installed all kinds of spyware on their computer, so this extra level of "protection" (try annoyance) provided by Firefox isn't really going to help them. Now, malware and phising, yeah. that's a help. The world Invalid should only be used when a certificate was issued for somesite-blaba.com and was being used on stupidsite.com.
I am thinking of marking this "WONTFIX", because the drivers have decided on their wording and do not want to change it. As a model of how it could be and should be done: Google Chrome has a message that is not only simple and informative, but also accurate. "The site's security certificate is not trusted! You attempted to reach epsc.wustl.edu, but the server presented a certificate issued by an entity that is not trusted by your computer's operating system. This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications. You should not proceed, especially if you have never seen this warning before for this site. Buttons: |Proceed anyway |Back to safety And for good measure, the "https:" is highly visible, with bold red letters and crossed out.
I think that calling a self-signed certificate "invalid" is misleading. I propose changing the message from "www.example.com uses an invalid security certificate." to "www.example.com uses an untrusted security certificate." in the Technical Details. The term "untrusted" is more accurate and matches the wording on the rest of the dialog. I also think that the dire "Get me out of here!" button may mislead some users to think that urgent action is needed to stay safe. This message on the button should indicate the following three aspects of this choice: 1. This is the safe choice. 2. Choosing this option means that you will not proceed to the site. 3. There is no urgency about whether to proceed or not. Chrome's "Back to safety" seems to satisfy all three aspects. I propose changing the text on the button to "Do not continue to site" to match the wording on the rest of the dialog and indicate that there is no urgency.
It's absolutely sufficient to display a warning message and not this cumbersome "advanced" acceptance procedure. Self signed web sites are absolutely common setups, and, from a security perspective, simply better than an unsecured http:// website. If you drop such an alert for a normal thing, you should definitely BLOCK ALL http:// sites as they are insecure like hell! This is just rubbish alarmism where no issue exists at all. Please take that out as soon as possible.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 16 votes.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sgalich)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(sgalich)
Type: defect → enhancement
Attached image new.png —

This bug is being addressed in the new network error page designs (Bug 1990918), that is enabled Nightly-only for now (Bug 2011043) and will at some point ride the train (Bug 1990918). The new design is gated behind security.certerrors.felt-privacy-v1 pref being set to true. Attaching a screenshot of the new design. I think we can close this bug once the new design rides the train.

Be careful. Something doesn’t look right.
Nightly spotted a potentially serious security issue with self-signed.badssl.com. Someone pretending to be the site could try to steal things like credit card info, passwords, or emails.

Advanced

What makes the site look dangerous?
Because there’s an issue with the site’s certificate. Sites use certificates issued by a certificate authority to prove they’re really who they say they are. This site’s certificate is self-signed. It wasn’t issued by a recognized certificate authority – so we don’t trust it by default.
What can you do about it?
Not much. It’s likely there’s a problem with the site itself.
IMPORTANT NOTE: If you are trying to visit this site on a corporate intranet, your IT staff may use self-signed certificates. They can help you check their authenticity.

Attached image old.png —

Also adding current/old design as reference.

Warning: Potential Security Risk Ahead
Nightly detected a potential security threat and did not continue to self-signed.badssl.com. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.

self-signed.badssl.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: