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