On Wed, 7 Aug 2002, Alex Loots wrote: > Hi Mike, > I visited your demo at https://www.thoughtcrime.org. It appears that Thawte is > the TTP instead of Verisign. Does this make any difference for example the > certificate extensions? First of all, https://www.thoughtcrime.org is NOT the demo site. Several people were confused by this email, and subsequently concluded that their browser isn't vulnerable because they got an alert that the "name on the certificate is invalid." If you would like to see a demo of this vulnerability, please email me offline. > Is that what you are saying here that you got a subordinate CA signing > certificate from Thawte (or Verisign according to your posting) for > thoughtcrime.org and used this to generate a end entity server certificate for > any domain you like? Or did you got an end entity server certificate from > Thawte for www.thoughtcrime.org and used this certificate to sign end entity > certificates? > > I ask this because in the basic constraints of www.thoughtcrime.org in your > example the "subject type" is "end entity" instead of "CA" which should be the > case for an intermediate CA according to RFC 2459. I think that you used a > end entity certificate as intermediate CA, but I am not sure. Thawte and Verisign aren't doing anything wrong. I received an end-entity certificate with the CA basic constraint set to FALSE from Thawte. According to RFC 2459, intermediate CAs in a certificate chain SHOULD have a CA basic constraint set to TRUE. According to that document, steps "h" through "m" should be applied to all certificates but the leaf certificate when verifying a certificate path. Step "i" is: (i) Verify that the certificate is a CA certificate (as specified in a basicConstraints extension or as verified out-of-band). ...so this is the point. I'm using my joe-schmoe end-entity certificate as an intermediate certificate, and IE is not doing step i. The vulnerability lies with IE. > > As the unscrupulous administrator of www.thoughtcrime.org, I can generate > > a valid certificate and request a signature from VeriSign: > > Is this a CA-signature or a end entity signature? It's a signature from an end-entity certificate, but IE treats it as a CA signature. > > [CERT - Issuer: VeriSign / Subject: VeriSign] > > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] > > > > Then I generate a certificate for any domain I want, and sign it using my > > run-of-the-mill joe-blow CA-signed certificate: > > The "name constraints extension" in the CA certificate should not allow this. > However in the case of a end entity certificate the name constraints extension > is not present so you used a end entity certificate for your run-of-the-mill > joe-blow CA-signed certificate? > > > [CERT - Issuer: VeriSign / Subject: VeriSign] > > -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] > > -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com] > > > Since IE doesn't check the Basic Constraints on the > > www.thoughtcrime.org > > certificate, it accepts this certificate chain as valid for > > www.amazon.com. > > > > Anyone with any CA-signed certificate (and the corresponding private > > key) can spoof anyone else. > > Not if the "name constraints extension" is properly defined by the TTP. See > section "4.2.1.11 Name Constraints" of RFC 2459. And the "pathLenConstraint > field" in the basic constraints is set to zero. > > So is IE really vulnerable or is it the TTP that messed up by not defining a > "name constraints extension"? IE is vulnerable. There's no reason to have a name constraints extension on an end-entity certificate at all. Anyone verifying the certificate path would trip over the absense of a CA basic constraint before even getting to name constraints. - Mike -- http://www.thoughtcrime.org
