User: Password:
Subscribe / Log in / New account

SSL certificates and MD5 collisions

SSL certificates and MD5 collisions

Posted Jan 18, 2009 21:49 UTC (Sun) by jd (guest, #26381)
In reply to: SSL certificates and MD5 collisions by dlang
Parent article: SSL certificates and MD5 collisions

Yeeees, except that if SSL has a fundamental flaw (and I admit that is a big if) because of inadequate validation, it will be necessary to have an SSL 4.0, which means that code is still going to have to be changed to support the new version.

The problem arises because, in my earlier post asking about the safety of SASL, it was pointed out that SSL doesn't do a whole lot of validation. If SSL is, as was claimed, taking short-cuts on validation and/or ignoring some fields entirely, you have no guarantees that the fields are being correctly populated in the first place. In fact, you can be certain that errors will exist because nobody QAs for things that aren't actual errors.

It would follow that any tightening up of SSL would expose any such coding flaws, which should be assumed to be common-place unless shown otherwise. But if SSL isn't tightened up, you don't necessarily buy a whole lot by phasing out MD5. If a SHA-1 hash trivially replaces an MD5 hash, the argument of the other reply noting problems with n-way collisions applies and finding a SHA-1 collision from a pre-existing MD5 collision would then be much easier. Worse, since both use the same underpinnings, it is theorised that the issues with MD5 mean SHA-1 might easily fall sooner rather than later - a big reason for the SHA-3 challenge.

In the end, postponing the problem might make it easier to fix, though as Y2K demonstrated, everyone waits until the last moment anyway, even when the problem is well-documented and agreed-upon. You're therefore left with the conclusion that code will (at some point) change and that the change will be painful. That suggests you're better off changing code as early as possible. The longer you wait, the more bad code will exist and the more painful the changes will be.

(Log in to post comments)

SSL certificates and MD5 collisions

Posted Jan 18, 2009 23:57 UTC (Sun) by dlang (subscriber, #313) [Link]

there are several issues here

1. SSL is not fundamentally broken here, one of the hashes that it can optionally use is broken enough that it could be exploited in one case.

2. switching from SSLv3 to SSLv4 would be a simple library change (if it was ever needed), much less invasive than a switch to something completely different like SASL

3. why would you assume that SSL would be broken and SASL wouldn't? swiching form one technology to another based on the fear that someone may break the first one some time in the future is not a very good use of time

4. where did you pick anything up that said that software wasn't verifying fields in the certs, and this is a security problem?

most of the fields in the cert are informational only, they don't matter (unless combined with other knowledge external to the cert)

5. SSL allows for different encryption and hash algorithms to be used. this is how AES has been added to SSL without most of the applications that use it even knowing about it (they just use the openssl libraries, which added a new encryption type). so when SHA-3 is defined, it will be added and people will have the option to start using it.

the issue that another poster mentioned of it being desirable to be able to have multiple signatures to one cert is the reflection of a desire to fundamentally change the basis of trust for the system.

the SSL cert trust model is based on the theory that the signers are trusted absolutly. If they vouch for the identity of someone (or a site), that identity can be trusted.

unfortunantly, in the scale of the Internet today this is a very questionable thing to do. how can you really verify if a person is allowed to get a cert for

and the economic incentives push exactly the other way. A Cert signer who does extensive verification not only spends more to do so (meaning they need to charge more), but it takes longer to fill the customer order, the customer has to spend more time providing the proof that the vendor asks for, and then (to add insult to injury) the resulting cert isn't treated any differently by anyone using it (so there really isn't any benifit from the extra checking)

but if you want to change this you need to define a new approach to solve many problems.

One major problem is that the Internet is just too big for any one entity to really know who is who. but if you try and segment the trust, how do you know when to trust a particular signer and when not to.

if you go to,
is this a personal site?
is it a banking site?
is it a government site?
is it a store?
is it a business?
is it several of these?

since nobody wants any one country/entity to control the Internet, this means that there will be several entities who could sign for each category. how do you know which ones to trust for this site? it may be that verisign issues the cert that uses, bu there is nothing that would prevent a russian or chinese certificate authority from signing a different certificate for the name, and if you trust those certificate authorities you would accept either cert. In theory you only want to check the certificate authority that the company has decided to use, but how can you know who that is?

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds