User-Agent: Mozilla/5.0 (X11; U; Linux i686; da-DK; rv:18.104.22.168) Gecko/20061201 Firefox/22.214.171.124 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; da-DK; rv:126.96.36.199) Gecko/20061201 Firefox/188.8.131.52 (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:
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.
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/>
No warning in step 3
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 184.108.40.206 Linux/FreeBSD, Firefox 220.127.116.11/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.
Association of certs with specific DNS names and ports was done as part
of the patch for bug 327181.
*** This bug has been marked as a duplicate of bug 327181 ***
> This is an old bug
> It is not an NSS bug, so I will correct the product/component before
> marking it fixed.
> 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
May somebody put me on CC of #308244 and #240261?
*** This bug has been marked as a duplicate of bug 240261 ***