User-Agent: Opera/7.54 (Windows NT 5.0; U) [de] Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0 Firefox 1.0 accepts wildcard-certificates where the cdertificate's common name is only the wildcard itself (e.g. CN=*). An SSL-Proxy sending it's own wildcard- certificate to Firefox and estabslishing a separate SSL-connection to the requested server can compromise end-to-end ssl-encryption this way. Reproducible: Always Steps to Reproduce: 1. Generated a self-signed certificate (CN=*) and imported it as root- certificate. 2. Installed the infamous achilles (http://www.indianz.ch/tools/attack/achilles. zip) on a second machine and used the self-signed certificate. 3. Configured the achilles-machine as SSL-proxy in firefox and opendes some HTTPS-sites. Actual Results: Firefox displayed the Sites without warning about the unusual and dangerous wildcard-certificate. Expected Results: Wildcard-certificates are quite unusual. An information-window should always be displayed. Wildcard-certificates must have a CN like *.domain.tld or something like that. A connection to a site with a certificate using CN=* must not be possible! I have been reported about a malware/spyware installing its own root-certificate and configure browsers to use a specific SSL-proxy. I am sure, You can imagine the rest... To exploit this vulnerability, some malware must be installed by the user or some arbitrary code must be executed by exploiting some other vulnerability. So this issue seems to be not very critical but should be fixed as well. I did not test, but maybe other mozilla products share this vulnerability.

We should reject not only "*", but also "*.TLD" wildcard certs. *.XX.ccTLD would be good, too, but there's no good way to cover all the bases with the different country registries (see discussions in the cookie bug 252342). If we attempt that we can only safely block two-char sub-domains plus maybe a hardcoded list of "com", "edu", etc (Austrailia and a few others use these: http://www.smh.com.au/). Anything else is problematic and might be a real domain (KABC.tv or KABC.fm for example).

mozilla won't trust a wildcard cert from just anyone. It must come from a trusted CA. So This report is only an issue provided that one of the trusted CAs ever issues such a WILD wildcard cert. I would think that issuance of such a cert would be immediate cause for removal of that CA from the list of trusted CAs. If a user chooses to trust a CA that mozilla foundation has not approved as a trusted CA, the user is responsible for his own actions.

(In reply to comment #2) > mozilla won't trust a wildcard cert from just anyone. [...] > So This report is only an issue provided that one of the > trusted CAs ever issues such a WILD wildcard cert. Note the original report specified malware that installs its own root certificate (this has been seen on IE, "Marketscore" being one). Since pure wildcards can't ever be valid would it hurt to block them as a bit of "belt and suspenders"? I suppose, though, if you've got the evil CA installed they could present fake site certs rather than a wildcard; blocking is ultimately pointless. WONTFIX, then?

(In reply to comment #3) Dan Veditz wrote: > if you've got the evil CA installed they could present fake site certs > rather than a wildcard; Yes. Exactly. And at least one MITM proxy has done exactly that. > blocking is ultimately pointless. The only point to blocking certs with such a totally wild wildcard is to raise the bar slightly for MITM attackers who are getting end users to install rogue CAs through social engineering. It requires them to present fake site certs for each site, rather than presenting a single cert for all sites. But I do not highly value such a solution, because it only raises the bar very slightly. Anyone willing to deploy a rogue CA cert will be willing to make the necessary site certs. > WONTFIX, then? Oh, maybe P3. No point in us refusing to ever make the requested change. It's merely not urgent. IMO, this bug report is not security sensitive. It does not disclose some hitherto unknown security vulnerability. It says no more than that if an end user accepts and trusts a rogue CA cert, thereafter the user is vulnerable to unlimited MITM attacks. But that's not news. We've always known that. Textbooks talk about it. I've written much about it during the debate about mozilla's CA cert policy. It is the nature of PKI. If the reporter has discovered an instance where this is actually being done, it would be MOST HELPFUL to the PKI community for that reporter to make that discovery public. The reason that MITM attacks have been historically rare is that SSL does such a good job of detecting them. Now there are people who are saying that MITM attacks have actually NEVER occured, and we should lower the bar in SSL, by no longer requiring good certs as a precondition to closing the lock. They are championing this view loudly in the n.p.m.crypto and n.p.m.security newsgroups. The strongest counter-argument to this silliness would be to document some of the actual MITM attacks.

I propose the following changes to this bug, to be made as one change: - remove security sensitive, - change summary to "trusting phony CA certs causes MITM vulnerability" - confirm it - make it an RFE - change priority to P3 - Indicate that the requested enhancement is to require at least two dots following the right-most asterisk in the cert's DNSname, or define some other algorithm for qualifying wildcards.

Confirming, removing security flag, updating title, etc: what Nelson said. "Marketscore" is an example of a MITM proxy (if you look at any certs details they will all be issued by Marketscore--more support for putting the CA's name or logo in the status bar). The folks behind it claim they are an opt-in market-data gathering group, but it's hard to imagine 1.5 million people opting-in to have all their SSL traffic readable by someone else.

see Bug 322661 for another MITM prevention that may make this less dangerous

This is not really an NSS bug. Setting the trust flags on a specific cert has a specific purpose and a specific meaning, and it is working as designed in NSS. Now, it may be that certain appliations that now mark bad certs as trusted should do something else with them instead, and not mark them trusted in NSS's cert DB. But that would be a change to the application, not to NSS, and the meaning of NSS's trust flags do not need to be changed to accomplish that change. I could change this bug to be a PSM bug, but instead I will resolve it as WONTFIX. There are plenty of other bugs about this same issue.