Ken Johanson Reporter
	Description • 20 years ago

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.

	Nelson Bolyard (seldom reads bugmail)
	Comment 1 • 20 years ago

This is an enhancement request for PSM, not NSS.

	Kai Engert (:KaiE:)
	Comment 2 • 20 years ago

I agree user awareness should be increased.

See also my first comment in bug 276827.

	Ken Johanson Reporter
	Comment 3 • 20 years ago

All cert accept dialogs should prob also eneumerate all aubject-alt fields and
wildcards to the user, to spoof spoofing..

	Ken Johanson Reporter
	Comment 4 • 20 years ago

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"

	Duane
	Comment 5 • 20 years ago

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...

	David E. Ross
	Comment 6 • 20 years ago

This RFE should be implemented in conjunction with bug #276533.  

	Ken Johanson Reporter
	Comment 7 • 20 years ago

(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..

	Ken Johanson Reporter
	Comment 8 • 20 years ago

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.

	Duane
	Comment 9 • 20 years ago

(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...

	Ken Johanson Reporter
	Comment 10 • 20 years ago

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.

	Duane
	Comment 11 • 20 years ago

(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...

	Ken Johanson Reporter
	Comment 12 • 20 years ago

Duane, did you already bug this? If not, will you, or would you like me to?

	Gervase Markham [:gerv]
	Comment 13 • 20 years ago

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

	Duane
	Comment 14 • 20 years ago

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...

	Duane
	Comment 15 • 20 years ago

(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.

	David E. Ross
	Comment 17 • 8 years ago

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?

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 18 • 8 years ago

(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).