[Ach] Algorithm Check on Path Validation?

ianG iang at iang.org
Mon Jan 27 09:48:55 CET 2014

On 27/01/14 00:32 AM, Rainer Hoerbe wrote:
>>>>> A potential problem with weak CA signatures (using RSA 1024 and/or MD5) will remain for some time. According the the current cab policy RSA 1024 and MD5 have been banned only for certificates issued from 2011 onwards.
>>>> I think ordinary MD5 is already out.
>>> I became aware of that when I encountered it with a private CA. It is obviously being accepted by usual deployments such as apache and enterprise load balancing HW. What would stop someone to fake a cert exploiting an MD5 collision just claiming that a shiny comodo cert was created with rsa1024/md5, if the client does not reject it?
>> Well, if there are any roots that are signing with raw MD5, you would
>> have to generate a collision attack which would require a fair amount of
>> crunching, a lot of certs, and strange stuff in the keys.  The attack
>> that breached RocketSSL took a few months of attempts.  That of course
>> might come down...
> So we agree that a moderately potent adversary could actually fake an intermediate CA cert using MD5. That would be a quite valuable target, and could be cheaper than hacking, blackmailing or buying a (Sub-)CA. 

Yes.  It's even a documented attack.  It's a fact of history.

>> Certainly if someone is running a private CA they should specify SHA256
>> or SHA512 for signing.
> That particular MD5-issuing CA was configured in 2001 and had the fate of many deployments: never fix a running system.

Ah, I see.  Some private CAs may be vulnerable.

I'm not quite sure what to do here.  The noise about MD5 is deafening in
the PKI world.  Indeed, some software is deprecating its existence
entirely, or trying to.  Anyone using MD5 is likely to face problems
every time they upgrade their tools.

> I disagree thet SHA2 is certain in managed environments. In 2011 for European project, which is handling sensitive health data, we put together a PKI for some 100 users in 10 member states that had to be ECRYPT- Level 7 compliant. Agreeing everybody (CAs + deployers) on SHA2 was a real hassle and almost failed. I would even say that without regulatory pressure it is unlikely to upgrade algorithms.

Yes, I know, same thing happened to us with the CAcert roots, in 2009
there wasn't enough availability of SHA2 to in software.  Now there is,
but problems still exist.

>> The problem however is not a config problem, it's a software problem.
> Hmm, not sure about this, because deployers are caught between two stools. Some vendors (Mozilla, MS) protect against MD5 and RSA < 1024. But developers using generic toolkits (java, openssl) are on their own.

Oh, I absolutely agree.  Deployers are poorly served by the vendors who
are more interested in status quo than security.  Even Mozilla knew all
about the security problems for yonks and did nothing until they were
sufficiently embarrassed and scared by folks like NIST, who think PKI
can be addressed with a list of numbers, and over-reacted by forcing
everyone to 2048.  Deployers will lose in this, and users most of all.

> So the better crypto config should at least warn deployers about products that do not protect against weak signatures. 

The conclusion here is that Better Crypto can therefore help the PKI
mess.  I'm not sure, but we've been around this several times, and
serves little restate the arguments about scratching the surface and
looking like you've made a difference.

One way to solve this would be to have a general specification of what
algorithms are acceptable.

E.g., list RSA<1536 and MD5 as bad, SHA1 as deprecated.  The problem
with this is that we'll run into trouble with SSL which has RC4, 3DES
and MD5 in abundance...

Another way to deal with this is to point out that the smaller key sizes
may be at risk of an attack, and if the private CA protects a high value
target, they need to fix it.  That's a more business-oriented approach,
but it won't satisfy the numerologists.


More information about the Ach mailing list