[27153] in bugtraq

home help back first fref pref prev next nref lref last post

IE6 SSL Certificate Chain Verification

daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Zolt=E1n_Nochta?=)
Mon Sep 23 12:48:25 2002

Message-ID: <4655E16C8DB3D311A91A0050047A92E033B7A1@i71ms02.cm-tm.uni-karlsruhe.de>
From: =?ISO-8859-1?Q?Zolt=E1n_Nochta?= <Zoltan.Nochta@cooperation-management.de>
To: bugtraq@securityfocus.com
Date: Mon, 23 Sep 2002 13:43:26 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"

Name: SSL Certificate Chain Verification
Systems Affected:  Win2K SP3 with IE6 (Not tested on other platforms yet)
Severity:  Low Risk (?)
Contibutor:   Zoltan Nochta
Date:   23/9/2002
 
Description:
***********
During SSL/TLS handshake, the webserver can optionally send the complete certificate chain to the client containing its own SERVER-CERT and one or more CA-CERT(s) with which the signature on SERVER-CERT can be verified. In some cases, IE6 does not warn the user when the certificate chain sent by the server is invalid. (So far I tested this only on win2k SP3 and IE6.)
 
Details:
*******
If (one of) the CA-CERT(s) sent by the server is invalid, (e.g., expired), IE6 first seeks for valid (newer) CA-CERT(s) in its own local repository (under Trusted Root Certification Authorities and in other lists) and tries to verify SERVER-CERT with it. If such a "better" CA-CERT was found the SSL-handshake continues and the browser does not warn the user. 
 
Note, that this works only if old_ca_public_key == new_ca_public_key AND issuer_old_ca_cert == issuer_new_ca_cert. Otherwise the signature on SERVER-CERT would not match, or the issuing CA would not be trusted.  

Comments:
********

I don't think that this behaviour could lead to a serious man-in-the-middle attack. But, maybe others can find an attack based on this.
 
However, I think the user should get at least a warning if the certificate chain presented by the server is invalid, before searching for better certificates on the local machine. TLS-RFC#2246 says (in section 7.2) that the verifier (in this case the browser) should come up with  a 'certificate_expired' error alert, which CAN be a fatal error and CAN lead to drop the connection to the server.
 
Such a warning could also help to detect servers that send expired certificate chains, like https:\\www.verisign.com and https:\\verisign.com
did. The chain you got there ended in a self-signed root-certificate expired on 01.01.2000. This mistake was not found by others, since the browsers seem not to care about the chain actually sent by the server. Therefore, I think other browsers also do not warn the user in such a case.
 
I'm sure there are many many other servers on the net sending expired certificate chains.

Vendor Status:
*************

Microsoft was notified (9/3/2002), but does not respond.
Verisign has responded and updated its both servers mentioned above.


Cheers,
Zoltan 

home help back first fref pref prev next nref lref last post