Closed Bug 402347 Opened 17 years ago Closed 17 years ago

Not binding X.509 certificate to originating domain name allows certificate spoofing

Categories

(Core :: Security: PSM, defect)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 240261

People

(Reporter: bugzilla.mozilla.org-mail, Assigned: KaiE, NeedInfo)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; da-DK; rv:1.8.1.8) Gecko/20061201 Firefox/2.0.0.8 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; da-DK; rv:1.8.1.8) Gecko/20061201 Firefox/2.0.0.8 (Ubuntu-feisty)

Mozilla based browsers do not bind a user-approved webserver certificate to the originating domain name. This make the user vulnerable to certificate spoofing by "subjectAltName:dNSName"-extensions. Scenario:

(1) Assumed a phisher could redirect a user's browser to his prepared spoofing webserver (by MITM or DNS spoofing or domain hijacking or ...). But the spoofed webserver "www.paypal.com" uses a webserver cert signed by a browser-accredited CA, such that the user's browser would raise a "unknown CA" warning (that's what X.509 and TLS is all about!), so the phisher defers this step.

(2) The phisher creates a website "www.example.com" and a home brewed X.509 cert:

  DN="CN=www.example.com"
  subjectAltName:dNSName=www.example.com
  subjectAltName:dNSName=www.paypal.com

and lures the user to https://www.example.com/. The user gets a "unknown CA" warning, but the "subjectAltName:dNSName" extensions are not shown to him (see bug #238142). As he does not plan to enter any relevant information, he accepts the cert (temporarily or permanently) and proceeds to download some pics.

(3) Any time later (if the cert got accepted temporarily this has to happen within the same session), the phisher lures the user to his spoofed https://www.paypal.com/, using the very same self-signed certificate. NO WARNING.

I consider this a severe cert-spoofing issue. Mozillas "match any wildcard"-behaviour (bug #159483) makes it worse.

Reproducible: Always

Steps to Reproduce:
1. Create a X.509 cert with DN="CN=www.example.com", subjectAltName:dNSName="www.example.com" and subjectAltName:dNSName="www.example.net". Configure (virtual) https-hosts "www.example.com" and "www.example.net" using this cert.
2. Go to <https://www.example.com/>
3. Go to <https://www.example.net/>
Actual Results:  
No warning in step 3

Expected Results:  
Raise a warning like 'The webserver "www.example.net" presents a certificate issued by an unknown CA. You have already accepted this certificate, but for the domain name(s) "www.example.com". It is possible, though unlikely, that someone may be trying to intercept your communication with this web site. Do you want to accept this certificate for "www.example.net", too?'

Demonstration at <http://test.eonis.net/>
More details at <https://nils.toedtmann.net/pub/subjectAltName.txt> (sorry, home made CA again ;)

Bug #159483: "cert name matching: RFC 2818 vs. backwards compatibility"
Bug #238142: "server mismatch dialog doesn't show subject alt names"

Tested: Firefox 2.0.0.8 Linux/FreeBSD, Firefox 2.0.0.9/Windows, Firefox 3.0a8 Linux/Windows, SeaMonkey 1.1.5/Windows and some more.
This is an old bug, already fixed in the forthcoming FireFox 3
It is not an NSS bug, so I will correct the product/component before
marking it fixed.
Assignee: nobody → kengert
Group: security
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries → psm
Association of certs with specific DNS names and ports was done as part 
of the patch for bug 327181.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
> This is an old bug

Obviously ;-)

> It is not an NSS bug, so I will correct the product/component before
> marking it fixed.

Thx.

> This bug has been marked as a duplicate of bug #327181

Bug #327181 tracks the new PSM for FF3 (not yet part of 3.0a8). So this is a WONTFIX for FF2?

Check demo at <http://test.eonis.net/> before you answer ...
Yes, this is a wontfix for FF 2, because FF 2 has been released a year ago, and only gets fixes for critical issues. The fixes around bug 327181 are too big for a stable release.

While this bug is marked fixed for FF 3, please note the following:

If a user used FF 2 (or earlier) to import a certificate and accepted it permanently, this old decision will still apply when updating to FF 3.

FF 3 will not delete the old cert and stored trust.

In order to remove the global trust, users will have to take action and manually delete the old certificates, and use the new mechanism of FF 3 to create a new exception.
> Yes, this is a wontfix for FF 2, because FF 2 has been released a year ago, 
> and only gets fixes for critical issues.

I'm astonished this issue is known for some time (at least to some moz devs) but considered non-critical (i strongly disagree).

So you won't mind me pushing this to the usual vuln-MLs, right?
bug 327181 may have contained a fix, but it's a confusing bug to dupe this to. This is really bug 308244 and bug 240261
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
May somebody put me on CC of #308244 and #240261?
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → DUPLICATE

You're probably going to have better results on our support forum: https://support.mozilla.org

Flags: needinfo?(jessicabrite)
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.