Re: IE6 SSL Certificate Chain Verification

[Jason <security () brvenik com>]

----- snip -----
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.  
----- snip -----


The specific details are not here or there but this is related to the 
major CA cert expiration issues a while back.

The long and short of it is that the major CA players who had root certs 
expiring used the same keys to create new certificates with new expiry 
dates. This resulted in a seamless transition for expired root certs and 
compatibility.

The larger issue is that you could ultimately have keys with unlimited 
life.

Basic theory says that the longer the keys exist the greater the risk of 
compromise. This means that in the case of some major players a root key 
compromise could result in a total compromise of the trust chain. 40 
years of the same 1024 bit keypair is sure to be outpaced by commodity 
hardware, definately by government budgets with specialized hardware.

Jason

Zoltán Nochta wrote:

> 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 
>
>