Security team successfully cracks SSL using 200 PS3's and MD5

* Joe Greco:
> It seems that part of the proposed solution is to get people to move from
> MD5-signed to SHA1-signed. There will be a certain amount of resistance.
> What I was suggesting was the use of the revocation mechanism as part of
> the "stick" (think carrot-and-stick) in a campaign to replace MD5-based
> certs. If there is a credible threat to MD5-signed certs, then forcing
> their retirement would seem to be a reasonable reaction, but everyone here
> knows how successful "voluntary" conversion strategies typically are.

A CA statement that they won't issue MD5-signed certificates in the
future should be sufficient. There's no need to reissue old
certificates, unless the CA thinks other customers have attacked it.

That would seem to be at odds with what the people who documented this
problem believe.

> Either we take the potential for transparent MitM attacks seriously, or
> we do not. I'm sure the NSA would prefer "not." :slight_smile:

I doubt the NSA is interested in MITM attacks which can be spotted by
comparing key material. :sunglasses:

Doubting that the NSA might be interested in any given technique is, of
course, good for the NSA. Our national security people have been known
to use imperfect interception technologies when it suits the task at hand.
Do people here really so quickly forget things? There was a talk on
Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the
instigating causes of that talk was problems that Earthlink had experienced
when the FBI had deployed Carnivore there.

... JG

* Joe Greco:

[snip

> Either we take the potential for transparent MitM attacks seriously, or
> we do not. I'm sure the NSA would prefer "not." :slight_smile:

I doubt the NSA is interested in MITM attacks which can be spotted by
comparing key material. :sunglasses:

Doubting that the NSA might be interested in any given technique is, of
course, good for the NSA. Our national security people have been known
to use imperfect interception technologies when it suits the task at hand.
Do people here really so quickly forget things? There was a talk on
Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the
instigating causes of that talk was problems that Earthlink had experienced
when the FBI had deployed Carnivore there.

Naturally. The NSA isn't filled with theorists who want to get the
job done the "right" way. They have a mission to fulfill, and they'll
use whatever tool works to get it done.

Neil wrote:

Do people here really so quickly forget things? There was a talk on
Carnivore given in 2000 at NANOG 20, IIRC, and I believe that one of the
instigating causes of that talk was problems that Earthlink had experienced
when the FBI had deployed Carnivore there.

Naturally. The NSA isn't filled with theorists who want to get the
job done the "right" way. They have a mission to fulfill, and they'll
use whatever tool works to get it done.

Just a slight point of order, here. Carnivore (and its successor, DCS1000) were used by, and developed by, the FBI. The NSA use other stuff. Let's get back to reality, anyway.

I do not wish to be rude, so don't think that's my intent--however, clarification is required here I believe.

From section 7 of http://www.win.tue.nl/hashclash/rogue-ca/ :
"An interesting question is whether CAs should revoke existing certificates signed using MD5. One may argue that the present attack scenario has in principle been possible since May 2007, and that therefore all certificates (or all CA certificates) signed with MD5 that have been issued after this date may have been compromised. Whether they really have been compromised is not relevant. What is relevant is that the relying party who needs to trust the certificate does not have a proper way of checking whether the certificate is to be trusted or not. One may even argue that all older certificates based on MD5 should be revoked, as for an attacker constructing rogue certificates it is easy to backdate them to any date in the past he likes, so any MD5-based certificate may be a forgery. On the other hand, one may argue that the likelihood of these scenarios is quite small, and that the cost of replacing many MD5-based certificates may be substantial, so that therefore the risks of continued use of existing MD5-based certificates may be seen as acceptable. Regardless, MD5 should no longer be used for new certificates."

Note that they aren't actually recommending that all certs with MD5 signatures be replaced. The authors present two sides of the argument. The only absolute statement is that MD5 should not be used to sign _new_ certificates.

This is because the attack doesn't allow the impersonation of the vulnerable CA; the attack merely creates a new intermediate CA that maintains the "chain of trust", so that certificates issued by the rogue intermediate CA will be trusted by most browsers. The weakness isn't that the vulnerable CA root certificate is signed by MD5, the weakness is that it uses MD5 to sign CSRs. Since I'm probably not explaining this very well, a picture is worth a thousand words: http://www.win.tue.nl/hashclash/rogue-ca/images/certificate4.png

Additionally, from second 8:
"Question. Are all digital certificates/signatures broken?
Answer. No. When digital certificates and signatures are based on secure cryptographic hash functions, our work yields no reason to doubt their security. Our result only applies when digital certificates are signed using the hash function MD5, which is known to be broken. With our method it is only possible to copy digital signatures based on MD5 between two specially constructed digital certificates. It is not possible to copy digital signatures based on MD5 from digital certificates unless the certificates are specially constructed. Even so, our result shows that MD5 is NOT suited for digital signatures. Certification Authorities should stop using the known broken MD5 and move to the widely available, more secure alternatives, such as SHA-2."

and

"Question. What should websites do that have digital certificates signed with MD5?
Answer. Nothing at this point. Digital certificates legitimately obtained from all CAs can be believed to be secure and trusted, even if they were signed with MD5. Our method required the purchase of a specially crafted digital certificate from a CA and does not affect certificates issued to any other regular website."

My apologies if you were commenting on some other aspect, or if my understand is in some way flawed.

* Joe Greco:

A CA statement that they won't issue MD5-signed certificates in the
future should be sufficient. There's no need to reissue old
certificates, unless the CA thinks other customers have attacked it.

That would seem to be at odds with what the people who documented this
problem believe.

What do they believe? That the CA should reissue certificates even if
the CA assumes that there haven't been other attacks? Or that the CA
should not reissue, despite evidence of other attacks?

* Brian Keefer:

My apologies if you were commenting on some other aspect, or if my
understand is in some way flawed.

I don't think so.

There's a rule of thumb which is easy to remembe: Never revoke
anything just because some weak algorithm is involved. The rationale
is that that revocation is absolute and (usually) retroactive, but we
generally want a more nuanced approach. If certain algorithms are too
weak to be used, this is up to the relying party to decide whether
it's fine in a particular case. On the other hand, replacing
MD5-signed certificates in the browser PKI is costly, but the overhead
is very finely dispersed (assuming that reissuing certificates has
very little overhead at the CA). I think it's doable if the browser
vendors could agree on a flag date after which MD5 signatures on
certificates are no longer considered valid.

(The implicit assumptions in that rule of thumb do not always apply.
For instance, if weak RSA keys are discovered which occur with
sufficiently high probability as the result of the standard key
generating algorithms to pose a real problem, the public key may not
reveal this property immediately, it may only be evident from the
private key, or only after a rather expensive computation. In the
latter case, we would be in very deep trouble.)