[nycbug-talk] [ccc related] MD5 considered harmful today

[Dan Colish]

On Wed, Dec 31, 2008 at 2:45 AM, Miles Nordin <carton at ivy.net> wrote:

> >>>>> "jc" == Jesse Callaway <bonsaime at gmail.com> writes:
>
>    jc> man that sucks... so even if this issue in the paper is
>    jc> addressed, it won't matter until the browsers fix the
>    jc> revocation mechanism.
>
> i don't think revocation is part of the fix.  The revocation problem
> is just funny because it adds to the feeling of powerlessness the
> incompetently-run CA, and makes me happy because they've been milking
> us all for cash all along.  Their first thoughut must have been
> ``Rogue cert?!  oh no.  quick, revoke it!''  nope.  PWNTx2!
>
> This attack would be foiled if the CA's would simply stop using MD5
> tomorrow.  They can't invalidate any fake signing certificates out
> there already, but there probably aren't any unless this same group
> made a working cert secretly.  Because the collision blocks are in the
> keys, AIUI an attacker needs to get a new key signed to pull it off.
> If the CA switches to SHA from now on, someone holding an honest MD5
> cert from before the switch can't use the same trick because there are
> no collision blocks hidden in his honest RSA key.
>
> The revocation mechanism isn't broken or underimplemented in FF3/IE7
> according to the authors---rather it's badly designed in X.509, so
> there is no improvement to that hilarious revocpwnage planned, not
> even an unimplemented one.
>
> The GnuPG revocation mechanism has neither problem they mention.  All
> revocations are signatures, but GnuPG revocations are signatures on
> whole keys, not on serial numbers like X.509, so you cannot manipulate
> me into revoking a key I don't want to by setting your serial number
> the same as the target.  And the revokee doesn't have to consent to
> the mechanism by publishing a URL in their key---it is possible in
> GnuPG to revoke your signature on someone else's key without their
> consent by simply uploading it:
>
> pub   1024D/6E9400D6 2004-07-11
> uid                  amber fechko (xi) <xi at telekinetic.net>
> rev          DA5BFE1D 2004-12-20  Miles Nordin <carton at ivy.net>
>
> It's not very nice, but I think she deserved it.
>
> Amber disappeared and set her MX record for telekinetic.net to
> 127.0.0.1 (that is, to the domain name 127.0.0.1, in text.  not the IP
> address 127.0.0.1.  foolio.).  In GnuPG signatures and revocations
> represent the binding or lack thereof, of key material to a uid, so
> when she shut down her email address clearly on purpose I decided she
> might like me to warn people that the binding wasn't valid any more.
> I guess no one else agreed with me, but I stand by my revocation.  not
> that I have a choice---i can't unrevoke.
>
>
> I think it would be funny if these guys made a real CA cert with their
> exploit and started selling certs signed by their fake key for $2 each
> or something.  not illegitimate certs, like, email-contact-verified
> certs, the regular legitimate kind, just cheaper.  Why not?  It's
> probably even legal in some jurisdiction if not in most.  and most
> webmasters just want to turn the browser bar green.  It works now, so
> for $2 why not?  I'd buy one.  If it starts turning browser bars red
> some day, buy a more expensive cert _some day_, not now. The whole
> cert thing was such a racket to begin with, i wish they'd start
> selling fake ones.
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>
>

This whole issue made me curious about what root CA's I had in Firefox,
remember these are hard coded in. Well it turns out that you absolutely
cannot remove them from your system. Also, as it has been pointed out, a CRL
for a CA that is cracked would be pointless. The only approach I see is to
modify the trust given to the CA's that are know to be broken. If you check,
you'll see the Firefox has not accepted certs signed by a number of MD5 CAs.
So I'm not sure this is really an issue if you are careful about CA
management. Also, if you read the paper, actually creating the fake Root CA
can take months due to timing issues and a fairly decent computing cluster
(200 ps3's). This is hardly the same level of oops as the Kandinsky DNS bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20081231/c3f9420d/attachment.htm>