Closed Bug 285361 Opened 16 years ago Closed 14 years ago

acceptance of wildcard certs makes MITM attacks easier for rogue proxy

Categories

(NSS :: Libraries, enhancement)

x86
Windows 2000
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mail, Unassigned)

Details

(Whiteboard: [sg:nse])

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).
Component: Security → Libraries
Product: Firefox → NSS
Whiteboard: [sg:fix]
Assignee: dveditz → wtchang
QA Contact: bishakhabanerjee
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.
Group: security
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: possible man-in-the-middle attack while using ssl-proxy due to acceptance of wildcard-certificates → acceptance of wildcard certs makes MITM attacks easier for rogue proxy
Whiteboard: [sg:fix] → [sg:nse]
QA Contact: bishakhabanerjee → jason.m.reid
see Bug 322661 for another MITM prevention that may make this less dangerous
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
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.  
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.