Closed Bug 267515 Opened 17 years ago Closed 5 years ago
User not prompted about the additional risk of installing/trusting a certificate from a un-authenticated site
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041101 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041101 Since there is an occasional need for users to install certificate (root or not) that are located on a remote server, it may be prudent for Mozilla to pop-up and additional warning (prior to the certificate-uses questionaire), in the case of certificates that are retrieved either from non-ssl sites or from ssl sites that are not already trusted. This thwartes hostname spoofing or man-in-the-middle attacks, when a nieve user is attempting to import a certifcate from a remote server. Reproducible: Always Steps to Reproduce: 1. Goto any non-ssl, or non-trusted ssl site that hosts a download-able certificate 2. Click on cert. 3. A uses/trust dialog is presented to the user without consideration for risk of downloading from an unauthenticated server. Expected Results: Perhaps an additional confirm-dialog could precede the "uses"-questionare, like: "Are you sure you want to trust this certificate to identify other sites/users? Since it is being downloaded from an authenticated server, it is possible that you may be downloading it from a site that is attempting to to trick you.\n\nTo download this certificate securely, try connecting to it with 'https' instead." Or, the above confirm dialog could auto-attempt to load the url (certificate) via https instead of advising that the user manually use https.
This is an enhancement request for PSM, not NSS.
Assignee: wtchang → kaie
Severity: normal → enhancement
Component: Libraries → Client Library
Product: NSS → PSM
QA Contact: bishakhabanerjee
I agree user awareness should be increased. See also my first comment in bug 276827.
Assignee: kaie → nobody
OS: Windows 2000 → All
Hardware: PC → All
All cert accept dialogs should prob also eneumerate all aubject-alt fields and wildcards to the user, to spoof spoofing..
One possible, but rough around the edges, certificate trust confirmation dialog: "WARNING! The certificate you have just opened is claiming to be an electronic identity validation tool [ala CA], but Mozilla does not have any prior knowledge nor trust of the individual or website who has supplied this file. This could be an attempt to trick you. Read the following directions or else click CANCEL now: [CA cert paragraph:] If you choose to accept this certificate for the purposes below [email, www, software checkboxes], you will give its issuer the power to 1) endorse the safety of software that you will run on your computer; 2) to validate digitally-signed email communications, 3) to validate website communcations with financial and other privacy based insitutions. [Non ca cert message, or CA with subject alts:] The certificate claims to be able to positivly identify the follwing websites/emails/software-signing, etc (subject alt fields) Click OK only if: -you are CERTAIN that you trust creator of this file to check the identity and trustworthiness of all of the above identities. -you have VERIFIED that the certificate's fingerprint[s, md5 or sha1] match the ones of its issuer, by dialing "[O goes here]'s" publicly listed telephone number and speaking with someone in the "[OU goes here]" department, or: -you should have recevied this file by hand-delivery from a person you trust. CLICK CANCEL if you do not fully understand the above warning or if you have any doubt whatsoever about the origins of this file"
Last time I tested firefox/mozilla it didn't properly honour subject alt fields, and a document I found about testing the DoD did, came to the same conclusion... Only MSIE actually accepted these fields properly...
This RFE should be implemented in conjunction with bug #276533.
(In reply to comment #5) > Last time I tested firefox/mozilla it didn't properly honour subject alt fields, Duane, Could you please elaborate? You must be descibing some incompatibility that I haven't noticed; I've been using subject alts for nearly two years in multiple sites and scenarios, and Moz does handle them in the fashion that I expect, and apprently the same as multiple other browsers and apis.. so some extra info would useful..
Bug #22183 's concerns about hostname discerpacies (user@pass encoding) could be intergrated into this same 'alert/advisory' architecture. Comment 228 there suggests creating a new user 'experince level' perference, wherein the user accepts more or less reponsibility in understanding their need to check SSL lock icons and user:pass@hostname encoding phishing tactics, etc. If they opt for or use the ship-default 'new user' mode, theyd get an alert on every discrepancy, which also describes in detail how to spot the 'trick', ala banksite.com:pass@badhost.
(In reply to comment #7) > (In reply to comment #5) > > Last time I tested firefox/mozilla it didn't properly honour subject alt fields, > > Duane, Could you please elaborate? You must be descibing some incompatibility > that I haven't noticed; I've been using subject alts for nearly two years in > multiple sites and scenarios, and Moz does handle them in the fashion that I > expect, and apprently the same as multiple other browsers and apis.. so some > extra info would useful.. Sorry been busy and couldn't find the doco I stumbled on before, I'm sure I posted it to the CAcert list, but too much email to little time etc... A simple example is the CAcert website itself. I have a certificate with the following subject: subject=/CN=*.cacert.org/CN=cacert.org using AltSubjectName didn't work last time I tested it either, but in any case going to https://cacert.org throws up an error message in firefox 1.0, but https://anything.cacert.org doesn't...
Interesting, that cert uses a comma delimited list in the subject/CN field!! I've never seen that before and I don't know if its legal. But it's definately is not a subject-alt entry though, which I have testing as working the same on IE and FF. Duane, would you like the honor of bug-ing Mozilla's differing treatment of CSV in the primary subject/CN field? Otherwise I can if your time doesn't permit. It will be interesting to see if the security/x509 guys say that CSV subjects are legal or not.
(In reply to comment #10) > Interesting, that cert uses a comma delimited list in the subject/CN field!! That was openssl output, the CRT actually has 2 commonName fields...
Duane, did you already bug this? If not, will you, or would you like me to?
I "independently" came up with this idea in a recent conversation with Frank Hecker; I think it's a good one. While it may irritate CACert.org to have to host their root cert on a server with a cert signed by e.g. Verisign, I think that installing new roots is an area of serious potential weakness that could be attacked, and we need to use transitive trust like this to secure it more. Gerv
If we'd been included as per Frank's original comments on our RFE this wouldn't be an issue for us, not to mention we do GPG key sign the finger print for the express purpose of out of band verification. Now having a certificate verified by another CA is like the fox guarding the hen house, well you guys are too popular now so we'll just accidently revoke this key...
(In reply to comment #12) > Duane, did you already bug this? If not, will you, or would you like me to? There is another way round the multiple commonName thing, and we're actually going to start modifing requests so that multiple commonNames are included as subjectAltNames instead.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1024871
Can someone explain why this bug report -- over 11 years old -- is closed as a duplicate in favor of a two-year-old bug report (bug #1024871)? Should not this be the other way around? Or is someone trying to hide the fact that a security bug remains open for over a decade?
(From bug 1024871 comment #28) > Hi David, > > This bug [i.e. bug 1024871] will fix bug 267515 by removing the feature entirely, which is why > I marked that one as a duplicate of this one. Sometimes it's beneficial to > mark an older bug as a duplicate of a newer one for various reasons (such as > in this case or if the newer one has more information or is more clear).
You need to log in before you can comment on or make changes to this bug.