Re: IE6 SSL Certificate Chain Verification

From: Jason (security@brvenik.com)
Date: 09/24/02


Date: Tue, 24 Sep 2002 02:15:55 -0400
From: Jason <security@brvenik.com>
To: Zoltán Nochta <Zoltan.Nochta@cooperation-management.de>


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



Relevant Pages

  • Easiest way to test ssl keys/certs...
    ... Sorry for a newbie question, but I have been unable to find an answer for ... I have created the certs and keys necessary for SSL ... connections between a client and the servers of a MySQL database. ...
    (Ubuntu)
  • Re: ipsec lan: IKE: no private key found, ideas?
    ... Sorry for posting in German, ... Pre-shared keys does it respectively. ... But i need it running with certs. ... den mein Deutsch nicht guter der ist ...
    (microsoft.public.win2000.security)
  • Re: Multiple web hosts and SSL
    ... It is possible to create a "wildcard" cert using the name *.domain.com ... though there may be some limitations on which browsers [or servers?] can use ... packs had problems with wildcard certs, until service pack 1 or later was ... The price is not the same as non-wildcard certificates... ...
    (microsoft.public.inetserver.iis.security)
  • Re: Digital sigs, part III
    ... > to either store those certs or to gain access to those certs, ... then in theory communication using those protocols ... > could imho be said to provide pretty good authentication. ... so this seems to imply "if they generate their own keys using ...
    (microsoft.public.security)
  • Re: RSAKeyLength setting for EFS - XP or Vista only?
    ... Mike Smith-Lonergan ... it'll generate 1024-bit RSA keys by default. ... does this control the generation of keys only for self-signed certs, ... also for CA-enrolled certs (where the key length isn't specified in the cert ...
    (microsoft.public.windowsxp.security_admin)