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/) for
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/) for
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 certainly not be checked, this
means the
* 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
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 of 2^{-48}
| 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 hashes -
[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
[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 compute
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 on
On Fri, Aug 8, 2008 at 8:27 PM, Eddy Nigg (StartCom Ltd.)
[EMAIL PROTECTED] wrote:
Ben Laurie:
On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.)
[EMAIL PROTECTED] wrote:
This affects any web site and service provider of various natures. It's not
exclusive for OpenID nor for any
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
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
| 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
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 that fails back
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
On Fri, Aug 08, 2008 at 11:20:15AM -0700, Eric Rescorla wrote:
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
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)
We have been following up on Ben Laurie's advisory and have replaced the
faulty certificate with a new one. In addition we created an advisory
for our users that outlines some general precautions they should take:
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
On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.)
[EMAIL PROTECTED] wrote:
This affects any web site and service provider of various natures. It's not
exclusive for OpenID nor for any other protocol / standard / service! It may
affect an OpenID provider if it uses a compromised key in
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
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
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 not be checked, this
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
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
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
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
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 CRLs in
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
29 matches
Mail list logo
