Open Bug 471802 Opened 16 years ago Updated 2 years ago

Location bar identity display ignores certified CN, always showing hostname or eTLD+1 depending on browser.identity.ssl_domain_display

Categories

(Firefox :: Security, defect, P3)

defect

Tracking

()

People

(Reporter: BenBE, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: 

When the location bar is set to show the SSL Identity Name by setting browser.identity.ssl_domain_display to 2 in about:config the Location Bar always shows the hostname part of the domain visited, instead of the Common Name the certificate is signed for.

In case of the URL https://bugzilla.mozilla.org/ the associated SSL cert is signed for Common Name CN=*.mozilla.org, but the additional Identity Field shows bugzilla.mozilla.org.

This can be abused by attackers by generating domain names quite simular to the original name of the domain you browsed to and presenting a certificate that certifies a shorter version of the Domain name (e.g. get a cert for *.org instead of *.mozilla.org). An enduser could not easily distinguish the legitimate cert from the fake one since in both cases he is presented the full bugzilla.mozilla.org domain name as being signed.

Reproducible: Always

Steps to Reproduce:
1. Set browser.identity.ssl_domain_display to 2 in about:config
2. Open up a SSL encrypted domain with a wildcard cert (e.g. bugzilla.mozilla.org

Actual Results:  
The Location Bar shows "bugzilla.mozilla.org"

Expected Results:  
The Location Bar shows the signed Common Name of the certificate (in this case *.mozilla.org)

Happy reading of the latest Certificate talks at:
https://blog.startcom.org/?p=145
https://events.ccc.de/2008/12/30/the-cat-is-out-of-the-bag/
Component: Location Bar and Autocomplete → Security
QA Contact: location.bar → firefox
First of all, can you tell my any validated CA that would sign a *.org cert?
Sure they might get mozlla.org or something but If you ask me I don't think the point is relevant in this matter.

A solution to your bug could be that Mozilla adds a new value token named '3' to display this.
0 = Just blue
1 = Blue with domain name only (mozilla.org)
2 = Blue with the full domain name your visiting (bugzilla.mozilla.org)
The new could be;
3 = Blue with the CN field (*.mozilla.org)

And if you are really looking at the certificates point here the normal (blue) is to secure you with the web server while speaking.
the extended validation (green) is to secure the identity of a website aswell as securing you with the web server while speaking to it.

By default the adress bars display of a normal certificate is to make the favicon and a bit more blue, nothing more.

So I think the point you have to identify a website is irrelevant when we got the extended validation certificates.
You are right on theEV certs, although I'm not fully sure there.

At least on the *.org cert question of yours: As presented in the talk held at 25C3 there are attacks possible that allow attackers to gain valid certificates for anything they want by creating MD5 collisions on the to-be-signed part of the certificate - and since the CN is part of this part, you can alter this, if you compute an MD5 collision for this altered to-be-signed part of your modified cert. Thus getting *.org signed is not impossible.

As for value 0 and 1 I see a use, but what advantages does repeating the FQDN for a domain have that make it needing to stay, instead of having it altered?
Those attacks aren't possible on any issuing CA anymore, but the point is sort of moot, it would arguably be better to use the cert content instead of eTLD+1, and would address one of the objections to turning the display on by default.  However, a couple of points:

1) We should arguably use dNSName (combined with subjectAltName) instead of CN, the latter being a not-defined-by-standards usage of a more generic field, whereas dNSName is specified to only be domain names, and can be used to enforce rules around which domains intermediate CAs can issue certs for.  I don't actually know the current state of dNSName deployment, so it could be a two-part bug, CN now, dNSName as a followup.

2) It would need to include sufficient smarts to
  - only show the "most-relevant" domain from the various dNSName+subjectAltName options
  - strip off any wildcard crap that users won't understand

I'd love to see a patch that did those things, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, regarding the first point:
As long as the basic meaning stays, i.e. showing which domain was certified, I'm not opposed to this.

But on the second point I disagree a bit: It's a difference whether the cert certifies *.mozilla.org to be safe or mozilla.org to be safe, thus the asterisk in the CN\dNSName\subjectAltName should belong to the displayed content.

I'm not fully sure about allowed usages of wildcards in the dNSName\CN fields though, but IMHO only wildcards at the beginning of the domain are allowed in wildcards, thus certifying mozilla.* should not be possible\allowed. So the only thing users might notice might be *.mozilla.org and mozilla.org which clearly distinguishes both cases (the one with wildcard and the one without). Only having a leading . (dot) as used in cookies is insufficient IMHO because of the lack of visual difference.

BenBE.
(In reply to comment #2)
> At least on the *.org cert question of yours: As presented in the talk held at
> 25C3 there are attacks possible

irrelevant, really. Yes, you can get anything you want so why would you want *.org? You could get a cert that matches your victim perfectly, or do what the researchers did and get a CA cert and generate your own perfect matches. (and as noted, the particular attack used by the attackers has been mitigated)

(In reply to comment #4)
> As long as the basic meaning stays, i.e. showing which domain was certified,
> I'm not opposed to this.

It has been argued elsewhere when this has come up that if the cert says *.bar.com then the host foo.bar.com _is_ a certified domain and it's OK to show that. It does not convey the "wildcardness" to the user, but a cert at a domain hosting shop could have dozens of explicit FQDNs in it and we don't convey that to the user either.

> I'm not fully sure about allowed usages of wildcards in the dNSName\CN fields
> though, but IMHO only wildcards at the beginning of the domain are allowed in
> wildcards, thus certifying mozilla.* should not be possible\allowed.

Mozilla follows Netscape precedent and supports a rich regexp syntax, which could arguably be more secure if it's something like (www|mail|blogs|support).foo.com as opposed to simply *.foo.com, but that use has been superseded by the alt-name feature. The official spec and what CA's will actually issue only allows leading * replacing a full domain part. (that is, a phisher could not get *-support.com and then stick a bunch of bank names in there). There's a bug on making NSS follow the spec.
 So the
> only thing users might notice might be *.mozilla.org and mozilla.org which
> clearly distinguishes both cases (the one with wildcard and the one without).
> Only having a leading . (dot) as used in cookies is insufficient IMHO because
> of the lack of visual difference.
> 
> BenBE.
Summary: Hostname instead of certified CN shown in Location bar → Hostname instead of certified CN (e.g. with wildcards) shown in Location bar
Summary: Hostname instead of certified CN (e.g. with wildcards) shown in Location bar → Location bar identity Hostname or eTLD instead of certified CN (e.g. with wildcards) shown in Location bar
I could see adding a new value for browser.identity.ssl_domain_display that makes Firefox show the matching CN (e.g. with wildcards).  But I don't think that's useful as a default.
Summary: Location bar identity Hostname or eTLD instead of certified CN (e.g. with wildcards) shown in Location bar → Location bar identity display ignores certified CN, always showing hostname or eTLD depending on browser.identity.ssl_domain_display
Blocks: 480357
Please also note that the CN field (all fields in the DN for that matter) isn't following standards. In reality the DNS names in the SAN  are authoritative, and there may be multiple ones including wild cards.

For EV that correct too, minus the wild card. But any entry in SAN is valid.

I would like to see the base domain name as in preference 1 on the visiting domain name, completely ignoring the CN field. Obviously the certificate must be valid.
As I said up in comment 2, I don't think it's valuable to show "*.mozilla.org" instead of "mozilla.org" when on bugzilla.mozilla.org.  I think the right thing to do here is to show the "thing in the cert we matched, as specifically as we matched it."

For a single, explicit CN/sAN, that's the domain name.
For a single wildcard CN/sAN, that's the post-asterisk domain portion (e.g. "mozilla.org" for a "*.mozilla.org" cert).
For a cert with multiple sANs, we should figure out which one we matched, and apply the same rules to that string.
Well, IMHO it's not important, what matched, but which rule matched. Otherwise
you'd just have the current behaviour. So if I create a cert with a CN\SAN of
*.example.com (and all the other tlds) and the user goes to
foo.bar.baz.example.com not the "foo.bar.baz" part is important, but the
*.example.tld part (the rule) used to match.

I agree on this not being first choice for Joe Average, but as an additional
option for the mentioned about:config value it's totally acceptable.
Flags: blocking-firefox3.1?
I don't think we can really make a decision on this until b3 is out there and we get wider feedback. Marking this blocking and assigning to johnath, we'll circle back after b3's been out there to see what people think.
Assignee: nobody → johnath
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Whiteboard: [decision to be made week of mar 23]
This was marked blocking for a decision, and I think only two options are useful ones:

1) Leave things as-is
2) Change to a mode (not identity.ssl_domain_display = 2) where we show the "correct" domain to whatever level of detail the cert specifies (so *.mozilla.org->mozilla.org but www.paypal.com->www.paypal.com)

#2 is more technically correct, but requires an API to get CN and sAN information from certs, which is currently not available (and no, I don't want to write my own ASN decoder in JS.  And yes, I know it's been done before.  :)

Even if it is more technically correct, I'm not entirely convinced that it's the unmitigated "better choice", but in any event, I don't think we should be changing cert APIs at this stage for compat reasons (plenty of addons use our cert APIs, though I don't know if any of them have binary components that would be hurt by this change) to say nothing of code risk and resource availability reasons.

Re-nominating to run this past drivers again, but also nominating for 3.6, because the reasons for not doing it in 3.5 don't apply to future versions, so we should nail down a decision (even if it is WONTFIX).
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Flags: blocking-firefox3.5+
If I happen to understand this correctly there should be an ASN-Decoder within the NSS library already, thus it should be possible to add that parser as native interface (if required). Thus I don't quite see the need to reinvent the wheel with JS ;-)

But this aside I'd like to add on your proposal #2 to show the wildcard, as I assume most people, even with little technical detail, should be able to recognize the asterisk as an wildcard (as it is common on most shells).

Anyways I'm voting for solution #2, if possible with the wildcard included.
Balancing the vote to #1. From experience it's sufficient and more convenient, even though technically less correct I agree.
Flags: blocking-firefox3.5? → blocking-firefox3.5-
Whiteboard: [decision to be made week of mar 23]
I don't think this blocks Firefox 3.6, but we'd take the patch if it came along with tests.
Flags: wanted-firefox3.6+
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
I firmly believe that the existing behavior is correct.

(In reply to comment #5)
> It has been argued elsewhere when this has come up that if the cert says
> *.bar.com then the host foo.bar.com _is_ a certified domain and it's OK to show
> that.

Indeed.  I'll amplify this point.  Firefox checks that the server is authorized to act for the requested hostname, i.e., the hostname matches the certificate.  All the security lies in this check.  Once it passes, it's irrelevant what the certificate says.  In fact, showing a field from one certificate is meaningless when the page can be manipulated by pages loaded under any other certificate Firefox will accept for the same hostname, according to the same origin policy.  (Few people seem to appreciate this last point.  It means that EV certs are still dependent on the integrity of the entire DV system.)

Furthermore, there's one case in which the existing behavior is clearly what we want.  Suppose I visit a site https://foo.com that presents a certificate with a bogus hostname bank.com .  That's pretty obnoxious, but I still want to talk to the site, so I verify out-of-band that the certificate is the right one and add a security exception.  At that point, I want to see foo.com and not bank.com in the site identity button.
Johnathan, you said option #2 is "more technically correct" but did not elaborate.  Do you accept my counterargument in comment #17?

Another argument for #1: The fact that the /front-end server/ is certified for a higher domain does not imply that the actual site is trusted to act for that domain.  Suppose Alice registers foo.com and sets up a front-end server with an SSL certificate for *.foo.com that gateways to multiple mutually untrusting sites on different subdomains.  When I visit bob.foo.com, the site I am seeing is not trusted by Alice, so I don't want to see simply foo.com in the SSL badge.

A possible argument for #2: Some CAs may refuse to issue a certificate containing a name confusingly similar to a popular high-value site, such as paypal.com.evil.com .  But if the attacker asks for a certificate for *.com.evil.com instead, the CA will see nothing wrong and the attacker can operate a site at paypal.com.evil.com .  In that case, we might like to show com.evil.com rather than paypal.com.evil.com in the SSL badge.  As a purist, I think users should learn to read domain names and am against granting special protection to sites that happen to be popular with the public, so I don't accept this argument myself, but I realize Mozilla folks may be more pragmatic.

Thoughts?  INVALID?
Summary: Location bar identity display ignores certified CN, always showing hostname or eTLD depending on browser.identity.ssl_domain_display → Location bar identity display ignores certified CN, always showing hostname or eTLD+1 depending on browser.identity.ssl_domain_display
(In reply to comment #18)
> A possible argument for #2: Some CAs may refuse to issue a certificate
> containing a name confusingly similar to a popular high-value site, such as
> paypal.com.evil.com .  But if the attacker asks for a certificate for
> *.com.evil.com instead, the CA will see nothing wrong and the attacker can
> operate a site at paypal.com.evil.com .

Now I see that there was an extensive discussion of this issue in the newsgroup:

https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/29b71f918eb3f51f/cd70db725a586059

And it is in the Problematic Practices:

https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Assignee: bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.