The default bug view has changed. See this FAQ.

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

RESOLVED DUPLICATE of bug 240261

Status

()

Core
Security: PSM
--
major
RESOLVED DUPLICATE of bug 240261
10 years ago
10 months ago

People

(Reporter: Nils Toedtmann, Assigned: kaie)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 327181
(Reporter)

Comment 3

10 years ago
> 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 ...
(Assignee)

Comment 4

10 years ago
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.
(Reporter)

Comment 5

10 years ago
> 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 → ---
(Reporter)

Comment 7

10 years ago
May somebody put me on CC of #308244 and #240261?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 240261

Comment 9

10 months ago
je peux enlevé les pinalitél,sur google ,si mon domaine et spammy ??
http://www.bourse-apprentissage-fc.fr/debouchage-canalisation/debouchage-canalisation-94.html
You need to log in before you can comment on or make changes to this bug.