Likes: 0
At Fri, 8 Aug 2008 11:50:59 +0100,
Ben Laurie wrote:
> However, since the CRLs will almost certainly not be checked, this
> means the site will still be vulnerable to attack for the lifetime of
> the certificate (and perhaps beyond, depending on user
> behaviour). Note that shutting down the site DOES NOT prevent the
> attack.
>
> Therefore mitigation falls to other parties.
>
> 1. Browsers must check CRLs by default.
Isn't this a good argument for blacklisting the keys on the client
side?
-Ekr
Eric Rescorla wrote on 08 August 2008 16:06:
> At Fri, 8 Aug 2008 11:50:59 +0100,
> Ben Laurie wrote:
>> However, since the CRLs will almost certainly not be checked, this
>> means the site will still be vulnerable to attack for the lifetime of
>> the certificate (and perhaps beyond, depending on user
>> behaviour). Note that shutting down the site DOES NOT prevent the attack.
>>
>> Therefore mitigation falls to other parties.
>>
>> 1. Browsers must check CRLs by default.
>
> 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?
cheers,
DaveK
--
Can't think of a witty .sigline today....
At Fri, 8 Aug 2008 17:31:15 +0100,
Dave Korn wrote:
>
> Eric Rescorla wrote on 08 August 2008 16:06:
>
> > At Fri, 8 Aug 2008 11:50:59 +0100,
> > Ben Laurie wrote:
> >> However, since the CRLs will almost certainly not be checked, this
> >> means the site will still be vulnerable to attack for the lifetime of
> >> the certificate (and perhaps beyond, depending on user
> >> behaviour). Note that shutting down the site DOES NOT prevent the attack.
> >>
> >> Therefore mitigation falls to other parties.
> >>
> >> 1. Browsers must check CRLs by default.
> >
> > 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?
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...
-Ekr
On Fri, Aug 8, 2008 at 5:57 PM, Eric Rescorla <ekr@networkresonance.com> wrote:
> At Fri, 8 Aug 2008 17:31:15 +0100,
> Dave Korn wrote:
>>
>> Eric Rescorla wrote on 08 August 2008 16:06:
>>
>> > At Fri, 8 Aug 2008 11:50:59 +0100,
>> > Ben Laurie wrote:
>> >> However, since the CRLs will almost certainly not be checked, this
>> >> means the site will still be vulnerable to attack for the lifetime of
>> >> the certificate (and perhaps beyond, depending on user
>> >> behaviour). Note that shutting down the site DOES NOT prevent the attack.
>> >>
>> >> Therefore mitigation falls to other parties.
>> >>
>> >> 1. Browsers must check CRLs by default.
>> >
>> > 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?
>
> 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?
On 8-Aug-08, at 10:11 AM, Ben Laurie wrote:
>
> It also only fixes this single type of key compromise. Surely it is
> time to stop ignoring CRLs before something more serious goes wrong?
Clearly many implementors have chosen to *knowingly* ignore CRLs
despite the security implications, so my take away would be that the
current public key infrastructure is flawed.
-- Dick
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
Eric Rescorla wrote on 08 August 2008 17:58:
> At Fri, 8 Aug 2008 17:31:15 +0100,
> Dave Korn wrote:
>>
>> Eric Rescorla wrote on 08 August 2008 16:06:
>>
>>> At Fri, 8 Aug 2008 11:50:59 +0100,
>>> Ben Laurie wrote:
>>>> However, since the CRLs will almost certainly not be checked, this
>>>> means the site will still be vulnerable to attack for the lifetime of
>>>> the certificate (and perhaps beyond, depending on user
>>>> behaviour). Note that shutting down the site DOES NOT prevent the
>>>> attack.
>>>>
>>>> Therefore mitigation falls to other parties.
>>>>
>>>> 1. Browsers must check CRLs by default.
>>>
>>> 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?
>
> 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...
<scurries off to read CRL format in RFC>
Oh, you can't specify them solely by key, you have to have all the
associated metadata. That's annoying, yes, I understand your point now.
IIRC various of the vendors' sshd updates released in the immediate wake
of the Debian catastrophe do indeed block all the weak keys.
cheers,
DaveK
--
Can't think of a witty .sigline today....
Eric Rescorla <ekr@networkresonance.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...
You'd also end up with a rather large list for the client to carry around,
which would be especially problematic for lightweight clients. You'd need to
represent it as something like a Bloom filter to avoid this (given that most
users will just click OK on invalid certs, the small false positive rate
shouldn't have much effect either :-).
Peter.
Eric Rescorla wrote:
> At Fri, 8 Aug 2008 17:31:15 +0100,
> Dave Korn wrote:
>
>> Eric Rescorla wrote on 08 August 2008 16:06:
>>
>>
>>> At Fri, 8 Aug 2008 11:50:59 +0100,
>>> Ben Laurie wrote:
>>>
>>>> However, since the CRLs will almost certainly not be checked, this
>>>> means the site will still be vulnerable to attack for the lifetime of
>>>> the certificate (and perhaps beyond, depending on user
>>>> behaviour). Note that shutting down the site DOES NOT prevent the attack.
>>>>
>>>> Therefore mitigation falls to other parties.
>>>>
>>>> 1. Browsers must check CRLs by default.
>>>>
>>> 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?
>>
>
> 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...
Funnily enough I was just working on this -- and found that we'd end up
adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
curious about the feasibility of a large bloom filter that fails back to
online checking though. This has side effects but perhaps they can be
made statistically very unlikely, without blowing out the size of a browser.
Updating the filter could then be something we do on a 24 hour
autoupdate basis. Doing either this, or doing revocation checking over
DNS (seriously), is not necessarily a bad idea. We need to do better
than we've been.
"Ben Laurie" <benl@google.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@piermont.com
At Fri, 08 Aug 2008 10:43:53 -0700,
Dan Kaminsky wrote:
> Eric Rescorla wrote:
> > 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...
> Funnily enough I was just working on this -- and found that we'd end up
> adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
> curious about the feasibility of a large bloom filter that fails back to
> online checking though. This has side effects but perhaps they can be
> made statistically very unlikely, without blowing out the size of a browser.
Why do you say a couple of megabytes? 99% of the value would be
1024-bit RSA keys. There are ~32,000 such keys. If you devote an
80-bit hash to each one (which is easily large enough to give you a
vanishingly small false positive probability; you could probably get
away with 64 bits), that's 320KB. Given that the smallest Firefox
build (Windows) is 7.1 MB, this doesn't sound like a nonstarter to me
at all, especially since the browser could download it in the
background.
> Updating the filter could then be something we do on a 24 hour
> autoupdate basis. Doing either this, or doing revocation checking over
> DNS (seriously), is not necessarily a bad idea. We need to do better
> than we've been.
Yes, there are a number of approaches to more efficient CRL
checking, I think that's a separate issue.
-Ekr
On Fri, Aug 8, 2008 at 7:54 PM, Tim Dierks <tim@dierks.org> wrote:
> Using this Bloom filter calculator:
> http://www.cc.gatech.edu/~manolios/b...alculator.html , plus the
> fact that there are 32,768 weak keys for every key type & size, I get
> various sizes of necessary Bloom filter, based on how many key type / sizes
> you want to check and various false positive rates:
> * 3 key types/sizes with 1e-6 false positive rate: 2826759 bits = 353 KB
> * 3 key types/sizes with 1e-9 false positive rate: 4240139 bits = 530 KB
> * 7 key types/sizes with 1e-6 false positive rate: 6595771 bits = 824 KB
> * 7 key types/sizes with 1e-9 false positive rate: 9893657 bits = 1237 KB
>
> I presume that the first 3 & first 7 key type/sizes in this list
> http://metasploit.com/users/hdm/tools/debian-openssl/ are the best to
> incorporate into the filter.
>
> Is there any chance it would be feasible to get a list of all the weak keys
> that were actually certified by browser-installed CAs, or those weak
> certificates? Presumably, this list would be much smaller and would be more
> effectively distributed in Bloom filter form.
Or as a CRL :-)
On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
> 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.
The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
I understand most current browsers support OCSP.
> 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.
No doubt.
On Fri, Aug 08, 2008 at 12:35:43PM -0700, Paul Hoffman wrote:
> At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
> >On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
> >> 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.
> >
> >The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
> >
> >I understand most current browsers support OCSP.
>
> ...and only a tiny number of CAs do so.
Not that long ago nothing supported OCSP. If all that's left (ha) is
the CAs then we're in good shape. (OCSP services can be added without
modifying a CA -- just issue the OCSP Responders their certs and let
them use CRLs are their source of revocation information.)
At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
>On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
>> 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.
>
>The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.
>
>I understand most current browsers support OCSP.
....and only a tiny number of CAs do so.
--Paul Hoffman, Director
--VPN Consortium
Quote