bugtraq - Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 08 Aug 2008 14:08:37 -0400
From: "Perry E. Metzger" <perry@...rmont.com>
To: "Ben Laurie" <benl@...gle.com>
Cc: "Eric Rescorla" <ekr@...workresonance.com>,
	"Dave Korn" <dave.korn@...imi.com>, bugtraq@...urityfocus.com,
	security@...nid.net, "OpenID List" <general@...nid.net>,
	cryptography@...zdowd.com, full-disclosure@...ts.grok.org.uk
Subject: Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

"Ben Laurie" <benl@...gle.com> writes:
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing
>> which servers have which cert...
>
> It also only fixes this single type of key compromise. Surely it is
> time to stop ignoring CRLs before something more serious goes wrong?

The problem is, the CRL mechanism itself is also dangerous.  Sadly,
clients are required to keep on going if they can't reach a CRL
server. That means that if you DoSing the CRL servers or use DNS
attacks to effectively take them offline, you've also effectively
eliminated the certificate revocation.

I'm not going to tell you that paying attention to CRLs wouldn't be
better than what happens now, but it will not eliminate the
problem. It is too hard to "prove a negative" (that is, to prove to
yourself that no revocation exists.)

The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal with such things, but it is far
from perfect and it could not be done for the ad-hoc certificate
system https: depends on -- the infrastructure for refreshing all the
world's certs every eight hours doesn't exist, and if it did imagine
the chaos if it failed for a major CA one fine morning.

One also worries about what will happen in the UI when a certificate
has been revoked. If it just says "this cert has been revoked,
continue anyway?" the wrong thing will almost always happen.

Perry
-- 
Perry E. Metzger		perry@...rmont.com