A better approach to security

[Philipp Guehring <philipp AT cacert.org>]

Hi,
> I think I understood it. What I don't understand is why lists of
> trusted rootCA contained in browsers and some operating systems aren't
> yet purged of md5 certificates 
Because you don't know from a root certificate, whether the CA (or any
of it's Sub-CA's) ever issued (or better: are still issueing) MD5
certificates.
The hash-function that is used in the self-signature is independent of
the hash-function that is used in the certificates. Every single
certificate a CA issues can have a different hash-function.
> and why certificates using md5 as signature hash aren't flagged as
> invalid ? 
Because it's only a problem for non-root certificates, not for all
certificates.
> That's how it can be solved. The missing trusted rootCA will block
> derived certificates.
Yes, but every rootCA can issue MD5 certificates which could lead to a
compromise.
Even if every CA would issue new root certificates now, they still could
issue MD5 certificates tomorrow.
> After a second careful reading I can't find the list of md5
> signing/signed rootCA. Are we supposed to do it out ourselves ?
You would have to take a look at every single certificate of every
single Sub-CA of all the root CA's, to give a definitive statement. And
still they could start issueing MD5 certs tomorrow.

>> SSL _is_ broken. Or rather, one specific implementation of it. As a
>> result, the attackers are now in posession of a CA that is trusted by
>> every browser, with which they can sign any site they like.
>>   
> I'm sorry, but SSL is a protocol and the protocol is not broken. 
Well, the problem is that SSL is not based on an agreed
> The scope goes well beyond SSL and concerns TLS as well as mail and
> software signature.
Yes, nearly everything else that's based on X.509 that heavily relies on
the certificates is affected too.
(e.g. Closed-environments like some VPNs that run their own CA, and are
not using the general root certificate list and issue the certificates
manually are not affected, even if they use MD5)

> The problem is in fact "only" the capacity to generate a forged
> certificate when md5 is used as hash in the signature. Did I
> understood it correctly ?
It's a bit more complex, but yes.


>
>> While the certificate they demonstrate is only valid in august 2004, it
>> is theoretically possible that there are multiple CAs that have that
>> capability, in the hands of criminals.
>>
>> How much more breakage do you need before _you_ believe SSL is broken?
>>   
> It is the MD5 hash use for signature that is broken and this is known
> for more than a year now. Not SSL.
Well, some uses of SSL rely on the certificate, so since

> The right action is to remove all rootCA using md5 or less secure
> signatures 
That's independent, so it wouldn't help.
> and change the certificate signature checking code to consider
> signatures using md5 hash as invalid. 
That concept also has a high false-positive rate.
> If possible this should be extended to all signature checking (i.e
> mail and software).
Yes.
> I checked comodo CA in thunderbird and they are all using sha-1 for
> signing algorithm. Why suggesting to remove comodo CA ?
Because the algorithm they used for the root-certificate does not have
anything to do with the algorithms they used for all their other
certificates.
> But IPS Seguridad CA (provided with thunderbird and firefox on
> windows) for instance is using md5 hash and since it uses old version
> of x509 certificats as no limit on the number of intermediate CA.
Using MD5 for the self-signature of a root certificate is not a security
problem, according to the current threat.
(It could become one in the far future, though)
A limit on the number of intermediate CA's only helps if you know
upfront how many intermediate CA's you will need. Prediciations are
hard, especially for the future. So unless you have time-machine, it's
usually better not to define a limit for intermediate CA's.

And by the way: The attack model also works in case the upper CA's have
defined a limit for intermediate CA's. In that case, you wouldn't issue
an intermediate CA, but a end-certificate directly. (So instead of
issueing a Sub-CA, you would issue a certificate for e.g. mozilla.com)
It's just that Sub-CA's are a bit more flexible. According to the paper,
the attack to issue a end-certificate directly is even easier than
issueing a Sub-CA.
So demanding limits on intermediate CA's doesn't solve the problem at
all, it just gives the attacker and the CA less flexibility.

> I also found an RSA Data Security, Inc. : verisign/RSA Secure Server
> CA  (root CA) using MD2 hash (!!!)  algorithm and no limit in
> intermediate CA since it also uses a version 1. What a mess! (don't
> confuse with RSA Security, Inc. who use SHA-1). Found it in firefox
> and thunderbird !
Yes, that's not a problem at the moment. (Unless you find a
second-preimage attack against MD2 that isn't publically known yet)
> CACert root CA, class 3 and signing authority are also using MD5 and
> have no limit in intermediate CA. So these are exposed too.
They aren't affected by the actual attack, since we didn't issued any
MD5 certificate in the past 2 years, so they can't be used for an attack.

Now the problem is that the browsers (and other PKI software) do not
have a way to precisely detect rogue certificates. The only chance they
have is to declare all MD5 certificates invalid (except for the
self-signatures of root certificates). But the false-positive rate of
that mechanism is 99.99999% at the moment, since there is only one known
rogue certificate, and all other MD5 certificates are currently believed
to be secure.
If Microsoft changed CAPI tomorrow that it would see all MD5
certificates as invalid, then I think a lot of systems would fail in
various industries, that are still using MD5 certificates somewhere. I
don't think that Microsoft can afford to do that in the next few months.
Mozilla might be able to do it, since there isn't any critical
infrastructure operated with their software.

I think the best way out of it would be to declare a global expiration
date on MD5 for intermediate and end-certificates. That expiration date
could be something like 1.July 2009 (I don't think that the industry can
do it in less time).
We could then implement that date into all software, and warn the people
upfront that it will expire on that day whenever the software encounters
MD5 somewhere, and really enforce to have it invalidated on that
particular day.

Best regards,
Philipp Gühring