On Fri, August 8, 2008 8:37 pm, Forrest J. Cavalier III wrote:
> Eric Rescorla wrote:
>>
>> To be concrete, we have 2^15 distinct keys, so, the
>> probability of a false positive becomes (2^15)/(2^b)=2^(b-15).
>> To get that probability below 1 billion, b+15 >= 30, so
>> you need about 45 bits. I c
You could use the SSL Blacklist plugin
(http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
Guardian
(http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
1039/) for IE to do this. If presented with a Debian key the show a
warning.
The blacklists are implemented
On Tue, Aug 12, 2008 at 9:55 AM, Clausen, Martin (DK - Copenhagen)
<[EMAIL PROTECTED]> wrote:
> You could use the SSL Blacklist plugin
> (http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
> Guardian
> (http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
> 1039
On Tue, Aug 12, 2008 at 9:55 AM, Clausen, Martin (DK - Copenhagen)
<[EMAIL PROTECTED]> wrote:
> You could use the SSL Blacklist plugin
> (http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL
> Guardian
> (http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11
> 1039
Hal Finney wrote:
> I thought of one possible mitigation that can protect OpenID end users
> against remote web sites which have not patched their DNS. OpenID
> providers who used weak OpenSSL certs would have to change their URLs
> so that their old X.509 CA certs on their old URLs no longer work
Eric Rescorla wrote:
>
> To be concrete, we have 2^15 distinct keys, so, the
> probability of a false positive becomes (2^15)/(2^b)=2^(b-15).
> To get that probability below 1 billion, b+15 >= 30, so
> you need about 45 bits. I chose 64 because it seemed to me
> that a false positive probability o
[I feel a little uncomfortable replying with such a wide distribution!]
Getting browsers, or OpenID installations, to check CRLs or use OCSP to
check for freshness is likely to be slow going. At this point I think
the momentum still favors fixing the remaining DNS systems that are
vulnerable to ca
Dan Kaminsky wrote:
>
>
> 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 certain
| > You can get by with a lot less than 64 bits. People see problems
| > like this and immediately think "birthday paradox", but there is no
| > "birthday paradox" here: You aren't look for pairs in an
| > ever-growing set, you're looking for matches against a fixed set.
| > If you use 30-bit has
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 w
At Fri, 8 Aug 2008 15:52:07 -0400 (EDT),
Leichter, Jerry wrote:
>
> | > > 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 tha
[Sorry for duplicates, but I got multiple requests for a non-HTML
version, and I didn't want to fork the thread. Also sorry for
initially sending HTML; I didn't realize it was so abhorrent these
days. ]
On Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <[EMAIL PROTECTED]> wrote:
>>
>> It's easy to comp
| > > 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 pe
On Fri, Aug 08, 2008 at 11:20:15AM -0700, Eric Rescorla wrote:
> At Fri, 08 Aug 2008 10:43:53 -0700,
> Dan Kaminsky wrote:
> > 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 f
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
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 Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <[EMAIL PROTECTED]> 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 th
* Eric Rescorla:
> Why do you say a couple of megabytes? 99% of the value would be
> 1024-bit RSA keys. There are ~32,000 such keys.
There are three sets of keys, for big-endian 32-bit, little-endian
32-bit and little-endian 64-bit. On top of that, "openssl genrsa"
generates different keys depen
On Fri, Aug 8, 2008 at 7:54 PM, Tim Dierks <[EMAIL PROTECTED]> wrote:
> Using this Bloom filter calculator:
> http://www.cc.gatech.edu/~manolios/bloom-filters/calculator.html , plus the
> fact that there are 32,768 weak keys for every key type & size, I get
> various sizes of necessary Bloom filter
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 t
Eric Rescorla <[EMAIL PROTECTED]> 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
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
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
Note ripped code by ZMDA.
It was recently discovered that a 'member of the underground' released an
exploit, which exploits a vulnerability in the ADNS resolver.
Apparently, he didn't write this exploit, nor did he do much modification to
the exploit he leached.
This is the real exploit, written
"Ben Laurie" <[EMAIL PROTECTED]> 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
*cough* http://codefromthe70s.org/sslblacklist.asp *cough*
--
Dan Guido
On Fri, Aug 8, 2008 at 12:57 PM, Eric Rescorla <[EMAIL PROTECTED]> 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,
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
mea
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 th
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
On Fri, Aug 8, 2008 at 5:57 PM, Eric Rescorla <[EMAIL PROTECTED]> 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 n
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 D
Security Advisory (08-AUG-2008) (CVE-2008-3280)
===
Ben Laurie of Google's Applied Security team, while working with an
external researcher, Dr. Richard Clayton of the Computer Laboratory,
Cambridge University, found that various OpenID Providers (OPs) h
32 matches
Mail list logo
