Re: IE SSL Vulnerability

[Mike Benham <moxie () thoughtcrime org>]

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