full-disclosure - 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, 8 Aug 2008 13:04:16 -0400 (EDT)
From: "Leichter, Jerry" <leichter_jerrold@....com>
To: Dave Korn <dave.korn@...imi.com>
Cc: cryptography@...zdowd.com, 'Eric Rescorla' <ekr@...workresonance.com>,
	security@...nid.net, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com, 'OpenID List' <general@...nid.net>
Subject: Re: OpenID/Debian PRNG/DNS Cache poisoning
	advisory

On Fri, 8 Aug 2008, Dave Korn wrote:
| > Isn't this a good argument for blacklisting the keys on the client
| > side?
| 
| Isn't that exactly what "Browsers must check CRLs" means in this
| context anyway?  What alternative client-side blacklisting mechanism
| do you suggest?
Since the list of bad keys is known and fairly short, one could
explicitly check for them in the browser code, without reference to
any external CRL.

Of course, the browser itself may not see the bad key - it may see key
for something that *contains* a bad key.  So such a check would not be
complete.  Still, it couldn't hurt.

One could put similar checks everywhere that keys are used.  Think of it
as the modern version of code that checks for and rejects DES weak and
semi-weak keys.  The more code out there that does the check, the faster
bad keys will be driven out of use.

							-- Jerry

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/