[EMAIL PROTECTED] wrote:
John Ioannidis wrote:
| Does anyone know how this security questions disease started, and
why
| it is spreading the way it is? If your company does this, can you
find
| the people responsible and ask them what they were thinking?
The answer is Help Desk Call
From an article about WAN optimization appliances in Computerworld:
In some markets, such as health and finance, [hiring] a managed
provider [who will do the encryption outside your routers] isn't a
good option for another reason: Because data is optimized in an
unencrypted state,
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)
| | My theory is that no actual security people have ever been involved,
| | that it's just another one of those stupid design practices that are
| | perpetuated because nobody has ever complained or that's what
| | everybody is doing.
|
| Your theory is incorrect. There is considerable
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
Quoting:
New microchipped passports designed to be foolproof against
identity theft can be cloned and manipulated in minutes and
accepted as genuine by the computer software recommended for use
at international airports.
Tests for The Times exposed security flaws in the
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, 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
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
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
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
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
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
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
I just got called by an autodialer -- the Caller ID was faked (and in
any case didn't point at a real number since area codes don't start
with 0 -- probably a mistake by the scammers).
After I answered, a tape of a cheerful woman informed me this was my
last chance to lower the rate on my credit
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
| 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
[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
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,
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
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
| 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 -
* 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
[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
28 matches
Mail list logo
