Bill Gianopoulos [:WG9s] Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806 Firefox/0.9.1+

Int the case where the hostname from the URL does not mach the commonname of the
server certificate, Firefox displays the URL hostname next to the lock icon. 
Hovering over the lock icon displays a tool-tip saying "Signed by <CA name>". 
This implies that the Certificate Authority has certified that the site you are
visiting has the hstname lsited next to the lock icon when in fact this is not
the case.

Reproducible: Always
Steps to Reproduce:
1. vist https://www.rtn.com
2. Accept the ceritificate name error
3. Cancel out of the username/password dialog

Actual Results:  
The hostname www.rtn.com appears next to the security lock Icon.  Hovering over
the icon yeields "Signed by Entrust.net"

Expected Results:  
Displayed either the certificate hostname or no hostname rather than the url
hostname.  I am also not sure it might not be better to display a broken
security icon in this case.

	Bill Gianopoulos [:WG9s] Reporter
	Comment 1 • 20 years ago

Gerv asked me to submit this and assign it to him.  But alas  Bugzilla says I am
not sufficeintly empowered to do that.

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

This is indeed true. Example URL: https://mail.blackcatnetworks.co.uk displays
mail.blackcatnetworks.co.uk instead of tuschin.blackcatnetworks.co.uk, which the
cert belongs to. Of course, to get to this point, you've had to click OK on a
"this might be dodgy" popup. So one could argue that it's not massively serious.

Nominating for blocking-aviary1.0PR. Triage team: please assess severity of
problem, or request more info.

FWIW, the bug also exists in the "Security" pane of Page Info, from where I
copied the code to get the domain name. In order to do this right, we need to do
it like the certificate viewer (and display the cert CN instead of the domain
name.) The code for that is in viewCertDetails.js, although I don't understand
it completely.

Gerv

	Bill Gianopoulos [:WG9s] Reporter
	Comment 3 • 20 years ago

Something else I forgot about that kind of complicates this are wildcard
certificates.  Got to https://splash.teamport.raytheon.com as an example (that
ends up getting an error because there is no default page on the site but it
does get to the certificate name check which passes and you get to the lock
icon).  The server name is splash.teamport.raytheon.com, but the common name on
the certificate is *.teamport.raytheon.com.  So in this case the names are not
the same but there is no pop-up.  I'm not sure in this case if it should display
splash.teamport.raytheon.com, *.teamport.raytheon.com or just teamport.raytheon.com.

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

This is probably now moot; the new approach is "trusted URL bar" - see bug 22183.

Gerv

	Robert Parenton
	Comment 5 • 20 years ago

It sounds like the "Trusted Location Bar" is only for windows that request being
chromeless and have the readonly Location Bar, and that normal windows will
still use the regular location bar.

	chris hofmann
	Comment 6 • 20 years ago

minus now that this will be covered under bug 22183 - renominate if that is not
the case..

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

The status bar is now back to being always-on, so this bug needs reviving. 

William Gianopoulos: you've done a good job testing this feature so far. Would
you be willing to bang on it a bit more? As a security feature, we need to make
sure it's solid. Please file bugs as you find them.

Gerv

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

OK, I have a patch to fix this, but it has some possibly undesirable side
effects which need to be assessed by the aviary team.

The patch changes the status bar to display the CN from the server certificate
instead of the domain as read from the browser URL bar. For the majority of
sites, this is the same value - e.g. "www.paypal.com". 

But, in cases like https://mail.blackcatnetworks.co.uk, after you dismiss the
warning dialog, it displays the domain that the certificate is for, rather than
the domain displayed in the URL bar. While this is more correct, it's also
confusing for the user.

The second problem is that the CN value is not always just a straight domain name:
https://splash.teamport.raytheon.com  ->  *.teamport.raytheon.com
https://bugzilla.mozilla.org          ->  (bugzilla|despot).mozilla.org
This regular-expression/glob syntax is also more confusing for the user, who may
never have seen anything like it.

Now, these are fairly edge cases, where you have to dismiss a warning anyway -
and it might be considered that reading the name from the cert is more secure
against problems we haven't thought of yet, or URL bar compromises, or whatever.
But the assessment needs to be made.

Ger

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

Patch to change from using URL bar info to info from certificate.

	chris hofmann
	Comment 10 • 20 years ago

Comment on attachment 159032 [details] [diff] [review]
Patch v.1

lets get some reviews.

	Daniel Veditz [:dveditz]
	Comment 11 • 20 years ago

Comment on attachment 159032 [details] [diff] [review]
Patch v.1

>+    // Get the common name from the security cert, for display next to the

Could assume success and do something like this instead:
      var commonName = null;
      try {
	commonName = gBrowser.securityUI
		     .QueryInterface(nsISSLStatusProvider)
		     .SSLStatus.QueryInterface(nsISSLStatus)
		     .serverCert.commonName;
      } catch (e) {}

I'm ok with the code, but I'm not sure this is what we want to do. seeing
"(bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org" at the bottom isn't
going to help anyone much (and it'll probably truncate to boot). Even the
security tab of the page info dialog shows the location host, not the name
from the cert (unless you view the cert itself).

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

dveditz: indeed. 

My view is that in this case we have to do what the security tab does - i.e.
what we do now. OK, it can be totally wrong if the cert is wrong, but you only
get that far after you've dismissed a socking great security warning about
domain name mismatches anyway.

So I would say this would be a WONTFIX. But then, I may not have thought of some
security problem that might arise - hence the review requests.

Gerv

	Bill Gianopoulos [:WG9s] Reporter
	Comment 13 • 20 years ago

I think you are right.  Either it somehow needs to display the urlname if the
url name validates against the certificate name, and the certificate name only
in the name mismatch case (which would probably be difficult to implement) or
just continue doing what it is doing now.

I guess I didn't think this through enough before I reported the issue.

	Bill Gianopoulos [:WG9s] Reporter
	Comment 14 • 20 years ago

An alternative approach would be to just display the "mozilla.org" part if the
form of the common name on the certificate is either:

*.mozilla.org

  - or -

(bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org

I think either doing that or just leaving it displaying the URL name and
WONTFIXing this bug are the best 2 approaches.

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

William: interesting idea. That might fly, although I'd be concerned about
writing the parsing and munging code in a completely secure way. But it does
break the current matching where the value is exactly the same as the hostname
in the URL bar, which I think is good.

Gerv

	Bill Gianopoulos [:WG9s] Reporter
	Comment 16 • 20 years ago

well that is true, but for ceritificates of this type, the Certificate Authority
is really only guaranteeing that the the server you connected to belongs to
"mozilla.rog" and is relaly much beyond that, so, it kind of makes some sense.

	chris hofmann
	Comment 17 • 20 years ago

sounds like where we are now is good enough for 1.0.  will consider
imnprovements for a future release.

	Daniel Veditz [:dveditz]
	Comment 18 • 20 years ago

Could help with punycode spoofing

	Ken Johanson
	Comment 19 • 20 years ago

Any changes to show the cert's valid names should also take into account
displaying subjsctAltName entries in the cert, not just wildcards (example:
https://www.breezeway.tv has a CN that is www.upsessions.com).

I also agree, that even after the use clicks 'accept (name-mismatch or
root-authority-unknown or expired-cert) for session' messages, it would be
prudent to show a broken - but yellow - lock icon.

	Daniel Veditz [:dveditz]
	Comment 20 • 19 years ago

*** Bug 296110 has been marked as a duplicate of this bug. ***

	Daniel Veditz [:dveditz]
	Comment 21 • 19 years ago

We need to resolve this, but I don't think we want the old patch. "Encrypted but
unverified" pages should not get the standard SSL lock symbolism. Shouldn't get
the "mixed content" broken lock suggested in comment 19, either. A new state,
perhaps a non-yellow lock with a super-imposed question mark? Localizers might
not like the question mark.

	Daniel Veditz [:dveditz]
	Comment 22 • 19 years ago

Ian's comments from bug 296110 are worth incorporating here:

Steps to Reproduce:
1.  Find a web server that does multiple SSL sites on one IP. 
2.  Go to one of the secondary web sites. 
[ example from bug 296110 URL field was http://koalagold.com/ ]
3.  Click on OK when the warning occurs. 
4.  Examine the status bar. 
 
Actual Results:  
a. status bar shows the domain of the URL, not the domain in the cert. 
b. mouse-over shows "Signed by ThisCA" where the CA is taken from the cert and 
there is no cert for the URL that is applicable. 

Expected Results:  
The status bar should display the domain name taken from the cert (perhaps as  
modified to wildcard processing), and should list the CA, perhaps as done with  
the mouse-over. 
  
If any of these things are wrong, then these should not be listed.  It may be  
possible for the user to override the browser's protections, but it should not  
be possible for the browser then to make incorrect certificate statements about  
SSL connections, especially where PKI is used to authorise the connections. 

Any statement made should be true.  So if a statement about a CA is made it       
must reflect the domain in the cert;  anything else would be to challenge the 
use of PKI if a certificate was in use.  Under PKI assumptions, stating that a      
domain is connected to under SSL is only valid when the certificate names that      
domain.  Anything else must be treated as a potential attack, and even if the      
user instructs the browser to go ahead, the browser should not present false      
statements such as that there is a valid SSL session _to another domain_ in      
progress. 
     
IOW, even if the user overrides, the browser should fall back to displays and 
statements akin to self-signed certificates.      
       
The status bar indicator should operate as an independent check as distinct 
from the URL bar.  The status bar should say "this is what you got" and the URL 
bar should say "this is what you wanted."  Especially, when there is lots of 
URL processing, the cert information should be kept clean and honest.

	Asa Dotzler [:asa]
	Comment 23 • 19 years ago

not going to block the beta3 on this bug.

	Chris Beard
	Comment 24 • 19 years ago

dveditz, is someone going to reasonably going to be able to work on this over
the next week in order for this to make 1.5b1? e.g. the final entry point for
any feature change.  gerv is on holiday until august 5th or thereabouts.

/cb

	Chris Beard
	Comment 25 • 19 years ago

hello?

ok, gerv is now back but dveditz is on vacation until the 26th or thereabouts. 
who else can work on this? (and should we?) we're rapidly approaching the
deadline to get this into 1.5 at all. 

/cb

	Gervase Markham [:gerv]
	Comment 26 • 19 years ago

I don't think this is a high priority. At the moment, our position is: "if the
user accepts a "this might be dodgy!" popup, all bets are off". We maybe can and
should do better, but there are bigger fish to fry. The patch as attached isn't
a go-er anyway, according to comment 21, so I suggest de-nomination.

Gerv

	Gervase Markham [:gerv]
	Comment 27 • 16 years ago

This shouldn't be assigned to me.

Gerv

	Matt McCutchen
	Comment 28 • 15 years ago

I no longer see any domain name in the status bar in Firefox 3.5.8, but the same issue with the new site identity ("Larry") button is in bug 471802.

	Johann Hofmann [:johannh]
	Comment 29 • 7 years ago

Can anyone still get this to reproduce? Otherwise I'll close this bug...

	:Gijs (he/him)
	Comment 30 • 7 years ago

14 years old, seems pretty safe to close. :-)