Full Disclosure mailing list archives
IE SSL Vulnerability
From: full-disclosure () lists netsys com (Clark, Bill W.)
Date: Fri, 9 Aug 2002 16:32:55 -0500
This is a multi-part message in MIME format.
------=_NextPartTM-000-16420657-abce-11d6-a2fa-00508b4fb63b
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C23FEC.531B8495"
------_=_NextPart_001_01C23FEC.531B8495
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Internet Explorer SSL Vulnerability 08/05/02=20
Mike Benham <moxie () thoughtcrime org>=20
http://www.thoughtcrime.org <http://www.thoughtcrime.org/>
<http://www.thoughtcrime.org <http://www.thoughtcrime.org/> > =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Abstract=20
Internet Explorer's implementation of SSL contains a vulnerability that=20
allows for an active, undetected, man in the middle attack. No dialogs=20
are shown, no warnings are given.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Description=20
In the normal case, the administrator of a web site might wish to
provide=20
secure communication via SSL. To do so, the administrator generates a=20
certificate and has it signed by a Certificate Authority. The generated
certificate should list the URL of the secure web site in the Common
Name=20
field of the Distinguished Name section.=20
The CA verifies that the administrator legitimately owns the URL in the
CN=20
field, signs the certificate, and gives it back. Assuming the=20
administrator is trying to secure www.thoughtcrime.org, we now have the=20
following certificate structure:=20
[CERT - Issuer: VeriSign / Subject: VeriSign]=20
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]=20
When a web browser receives this, it should verify that the CN field=20
matches the domain it just connected to, and that it's signed using a=20
known CA certificate. No man in the middle attack is possible because
it=20
should not be possible to substitute a certificate with a valid CN and a
valid signature.=20
However, there is a slightly more complicated scenario. Sometimes it is
convenient to delegate signing authority to more localized authorities.=20
In this case, the administrator of www.thoughtcrime.org would get a
chain=20
of certificates from the localized authority:=20
[Issuer: VeriSign / Subject: VeriSign]=20
-> [Issuer: VeriSign / Subject: Intermediate CA]=20
-> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org]=20
When a web browser receives this, it should verify that the CN field of=20
the leaf certificate matches the domain it just connected to, that it's=20
signed by the intermediate CA, and that the intermediate CA is signed by
a=20
known CA certificate. Finally, the web browser should also check that
all=20
intermediate certificates have valid CA Basic Constraints.=20
You guessed it, Internet Explorer does not check the Basic Constraints.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=20
Exploit=20
So what does this mean? This means that as far as IE is concerned,
anyone=20
with a valid CA-signed certificate for ANY domain can generate a valid=20
CA-signed certificate for ANY OTHER domain.=20
As the unscrupulous administrator of www.thoughtcrime.org, I can
generate=20
a valid certificate and request a signature from VeriSign:=20
[CERT - Issuer: VeriSign / Subject: VeriSign]=20
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]=20
Then I generate a certificate for any domain I want, and sign it using
my=20
run-of-the-mill joe-blow CA-signed certificate:=20
[CERT - Issuer: VeriSign / Subject: VeriSign]=20
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]=20
-> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com]=20
Since IE doesn't check the Basic Constraints on the www.thoughtcrime.org
certificate, it accepts this certificate chain as valid for=20
www.amazon.com.=20
Anyone with any CA-signed certificate (and the corresponding private=20
key) can spoof anyone else.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Severity=20
I would consider this to be incredibly severe. Any of the standard=20
connection hijacking techniques can be combined with this vulnerability=20
to produce a successful man in the middle attack. Since all you need is
one constant CA-signed certificate (and the corresponding private key),
an=20
attacker can use that to generate spoofed certificates for other domains
as connections are intercepted (on the fly). Since no warnings are
given=20
and no dialogs are shown, the attacker has effectively circumvented all=20
security that an SSL certificate provides.=20
There is some level of accountability, though, since a user who randomly
chooses to view the certificate of the web site she's visiting will see=20
the attacker's certificate in the chain. However, by that point the=20
damage has already been done. All "secure" data has already been=20
transmitted.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=20
Affected Browsers=20
Netscape 4.x and Mozilla are NOT vulnerable.=20
IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable.=20
When VeriSign issues certificates, usually they leave out the CA Basic=20
Constraint information all together. Thawte tends to explicitly put in
a=20
Basic Constraint CA =3D FALSE with the critical bit set to TRUE.=20
When the CA Basic Constraint on the middle certificate is explicitly set
to false and marked as critical, IE 6 does not follow the chain. When=20
it's not mentioned at all, IE 6 follows the chain and is vulnerable.=20
This just means that an attacker needs to use a VeriSign-issued=20
certificate to exploit IE 6.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=20
Working Exploit=20
I've set up a URL to demonstrate this problem. If you want to test=20
browsers not listed above or need proof of this vulnerability, contact
me=20
and I'll give you the information.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=20
Vendor Notification Status=20
Last week I saw Microsoft downplay and obfuscate the severity of the=20
IE vulnerability that Adam Megacz reported. After seeing that, I don't=20
feel like wasting time with the Microsoft PR department.=20
- Mike=20
--=20
http://www.thoughtcrime.org <http://www.thoughtcrime.org/>
<http://www.thoughtcrime.org <http://www.thoughtcrime.org/> > =20
------_=_NextPart_001_01C23FEC.531B8495
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=20
</FONT><BR><FONT size=3D2>Internet Explorer SSL Vulnerability 08/05/02=20
</FONT><BR><FONT size=3D2>Mike Benham <moxie () thoughtcrime org>=20
</FONT><BR><FONT size=3D2><A=20
href=3D"http://www.thoughtcrime.org/";>http://www.thoughtcrime.org</A> =
<<A=20
href=3D"http://www.thoughtcrime.org/";>http://www.thoughtcrime.org</A>>=
=20
</FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=20
</FONT><BR><FONT size=3D2>Abstract </FONT></P>
<P><FONT size=3D2>Internet Explorer's implementation of SSL contains a=20
vulnerability that </FONT><BR><FONT size=3D2>allows for an active, =
undetected, man=20
in the middle attack. No dialogs </FONT><BR><FONT size=3D2>are =
shown, no=20
warnings are given. </FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=20
</FONT><BR><FONT size=3D2>Description </FONT></P>
<P><FONT size=3D2>In the normal case, the administrator of a web site =
might wish=20
to provide </FONT><BR><FONT size=3D2>secure communication via SSL. =
To do so,=20
the administrator generates a </FONT><BR><FONT size=3D2>certificate and =
has it=20
signed by a Certificate Authority. The generated </FONT><BR><FONT=20
size=3D2>certificate should list the URL of the secure web site in the =
Common Name=20
</FONT><BR><FONT size=3D2>field of the Distinguished Name section. =
</FONT></P>
<P><FONT size=3D2>The CA verifies that the administrator legitimately =
owns the URL=20
in the CN </FONT><BR><FONT size=3D2>field, signs the certificate, and =
gives it=20
back. Assuming the </FONT><BR><FONT size=3D2>administrator is =
trying to=20
secure www.thoughtcrime.org, we now have the </FONT><BR><FONT =
size=3D2>following=20
certificate structure: </FONT></P>
<P><FONT size=3D2>[CERT - Issuer: VeriSign / Subject: VeriSign] =
</FONT><BR><FONT=20
size=3D2>-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] =
</FONT></P>
<P><FONT size=3D2>When a web browser receives this, it should verify =
that the CN=20
field </FONT><BR><FONT size=3D2>matches the domain it just connected to, =
and that=20
it's signed using a </FONT><BR><FONT size=3D2>known CA =
certificate. No man=20
in the middle attack is possible because it </FONT><BR><FONT =
size=3D2>should not=20
be possible to substitute a certificate with a valid CN and a =
</FONT><BR><FONT=20
size=3D2>valid signature. </FONT></P>
<P><FONT size=3D2>However, there is a slightly more complicated =
scenario. =20
Sometimes it is </FONT><BR><FONT size=3D2>convenient to delegate signing =
authority=20
to more localized authorities. </FONT><BR><FONT size=3D2>In this case, =
the=20
administrator of www.thoughtcrime.org would get a chain </FONT><BR><FONT =
size=3D2>of certificates from the localized authority: </FONT></P>
<P><FONT size=3D2>[Issuer: VeriSign / Subject: VeriSign] =
</FONT><BR><FONT=20
size=3D2>-> [Issuer: VeriSign / Subject: Intermediate CA] =
</FONT><BR><FONT=20
size=3D2> -> [Issuer: Intermediate CA / Subject:=20
www.thoughtcrime.org] </FONT></P>
<P><FONT size=3D2>When a web browser receives this, it should verify =
that the CN=20
field of </FONT><BR><FONT size=3D2>the leaf certificate matches the =
domain it just=20
connected to, that it's </FONT><BR><FONT size=3D2>signed by the =
intermediate CA,=20
and that the intermediate CA is signed by a </FONT><BR><FONT =
size=3D2>known CA=20
certificate. Finally, the web browser should also check that all=20
</FONT><BR><FONT size=3D2>intermediate certificates have valid CA Basic=20
Constraints. </FONT></P>
<P><FONT size=3D2>You guessed it, Internet Explorer does not check the =
Basic=20
Constraints. </FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=20
</FONT><BR><FONT size=3D2>Exploit </FONT></P>
<P><FONT size=3D2>So what does this mean? This means that as far =
as IE is=20
concerned, anyone </FONT><BR><FONT size=3D2>with a valid CA-signed =
certificate for=20
ANY domain can generate a valid </FONT><BR><FONT size=3D2>CA-signed =
certificate=20
for ANY OTHER domain. </FONT></P>
<P><FONT size=3D2>As the unscrupulous administrator of =
www.thoughtcrime.org, I can=20
generate </FONT><BR><FONT size=3D2>a valid certificate and request a =
signature=20
from VeriSign: </FONT></P>
<P><FONT size=3D2>[CERT - Issuer: VeriSign / Subject: VeriSign] =
</FONT><BR><FONT=20
size=3D2>-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] =
</FONT></P>
<P><FONT size=3D2>Then I generate a certificate for any domain I want, =
and sign it=20
using my </FONT><BR><FONT size=3D2>run-of-the-mill joe-blow CA-signed =
certificate:=20
</FONT></P>
<P><FONT size=3D2>[CERT - Issuer: VeriSign / Subject: VeriSign] =
</FONT><BR><FONT=20
size=3D2>-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] =
</FONT><BR><FONT size=3D2> -> [CERT - Issuer: =
www.thoughtcrime.org=20
/ Subject: www.amazon.com] </FONT></P>
<P><FONT size=3D2>Since IE doesn't check the Basic Constraints on the=20
www.thoughtcrime.org </FONT><BR><FONT size=3D2>certificate, it accepts =
this=20
certificate chain as valid for </FONT><BR><FONT size=3D2>www.amazon.com. =
</FONT></P>
<P><FONT size=3D2>Anyone with any CA-signed certificate (and the =
corresponding=20
private </FONT><BR><FONT size=3D2>key) can spoof anyone else. =
</FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=20
</FONT><BR><FONT size=3D2>Severity </FONT></P>
<P><FONT size=3D2>I would consider this to be incredibly severe. =
Any of the=20
standard </FONT><BR><FONT size=3D2>connection hijacking techniques can =
be combined=20
with this vulnerability </FONT><BR><FONT size=3D2>to produce a =
successful man in=20
the middle attack. Since all you need is </FONT><BR><FONT =
size=3D2>one=20
constant CA-signed certificate (and the corresponding private key), an=20
</FONT><BR><FONT size=3D2>attacker can use that to generate spoofed =
certificates=20
for other domains </FONT><BR><FONT size=3D2>as connections are =
intercepted (on the=20
fly). Since no warnings are given </FONT><BR><FONT size=3D2>and no =
dialogs=20
are shown, the attacker has effectively circumvented all =
</FONT><BR><FONT=20
size=3D2>security that an SSL certificate provides. </FONT></P>
<P><FONT size=3D2>There is some level of accountability, though, since a =
user who=20
randomly </FONT><BR><FONT size=3D2>chooses to view the certificate of =
the web site=20
she's visiting will see </FONT><BR><FONT size=3D2>the attacker's =
certificate in=20
the chain. However, by that point the </FONT><BR><FONT =
size=3D2>damage has=20
already been done. All "secure" data has already been =
</FONT><BR><FONT=20
size=3D2>transmitted. </FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
</FONT><BR><FONT size=3D2>Affected Browsers </FONT></P>
<P><FONT size=3D2>Netscape 4.x and Mozilla are NOT vulnerable. =
</FONT></P>
<P><FONT size=3D2>IE 5 and 5.5 are vulnerable straight-up, and IE 6 is =
mostly=20
vulnerable. </FONT></P>
<P><FONT size=3D2>When VeriSign issues certificates, usually they leave =
out the CA=20
Basic </FONT><BR><FONT size=3D2>Constraint information all =
together. Thawte=20
tends to explicitly put in a </FONT><BR><FONT size=3D2>Basic Constraint =
CA =3D FALSE=20
with the critical bit set to TRUE. </FONT></P>
<P><FONT size=3D2>When the CA Basic Constraint on the middle certificate =
is=20
explicitly set </FONT><BR><FONT size=3D2>to false and marked as =
critical, IE 6=20
does not follow the chain. When </FONT><BR><FONT size=3D2>it's not =
mentioned=20
at all, IE 6 follows the chain and is vulnerable. </FONT></P>
<P><FONT size=3D2>This just means that an attacker needs to use a =
VeriSign-issued=20
</FONT><BR><FONT size=3D2>certificate to exploit IE 6. </FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
</FONT><BR><FONT size=3D2>Working Exploit </FONT></P>
<P><FONT size=3D2>I've set up a URL to demonstrate this problem. =
If you want=20
to test </FONT><BR><FONT size=3D2>browsers not listed above or need =
proof of this=20
vulnerability, contact me </FONT><BR><FONT size=3D2>and I'll give you =
the=20
information. </FONT></P>
<P><FONT=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
</FONT><BR><FONT size=3D2>Vendor Notification Status </FONT></P>
<P><FONT size=3D2>Last week I saw Microsoft downplay and obfuscate the =
severity of=20
the </FONT><BR><FONT size=3D2>IE vulnerability that Adam Megacz =
reported. =20
After seeing that, I don't </FONT><BR><FONT size=3D2>feel like wasting =
time with=20
the Microsoft PR department. </FONT></P>
<P><FONT size=3D2>- Mike </FONT></P>
<P><FONT size=3D2>-- </FONT><BR><FONT size=3D2><A=20
href=3D"http://www.thoughtcrime.org/";>http://www.thoughtcrime.org</A> =
<<A=20
href=3D"http://www.thoughtcrime.org/";>http://www.thoughtcrime.org</A>>=
=20
</FONT></P><BR></DIV></BODY></HTML>
=00
------_=_NextPart_001_01C23FEC.531B8495--
------=_NextPartTM-000-16420657-abce-11d6-a2fa-00508b4fb63b--
Current thread:
- IE SSL Vulnerability Clark, Bill W. (Aug 09)