On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said:
>> That's basically what /dev/urandom does, no? (Except that it has the
>> undesirable side-effect of depleting the entropy estimate maintained
>> inside the kernel.)
> This "entropy depletion" issue keeps coming up every now and then, b
> [1] Superconducting QUantum Interference Device, the Gibsonian gizmo
> used by the dolphin in _Johnny Mnemonic_ to extract "80 *Gigabytes*!"
> of information from the courier's brain-mounted memory module.
SQUID-s are not a 'Gibsonian gizmo', they are a real device, superensitive
magne
- Original Message -
From: "Andy Isaacson" <[EMAIL PROTECTED]>
To: "Florian Weimer" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, December 25, 2004 4:56 AM
Subject: Re: SSL/TLS passive sniffing
> On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wr
At 22:51 2004-12-22 +0100, Florian Weimer wrote:
* John Denker:
> Florian Weimer wrote:
>
>> Would you recommend to switch to /dev/urandom (which doesn't block if
>> the entropy estimate for the in-kernel pool reaches 0), and stick to
>> generating new DH parameters for each connection,
>
> No, I w
On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wrote:
> * Victor Duchovni:
> >> The Debian folks have recently stumbled upon a problem in this area:
> >> Generating the ephemeral DH parameters is expensive, in terms of CPU
> >> cycles, but especailly in PRNG entropy. The PRNG part means
On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wrote:
> > Actually reasoning along these lines is why Lutz Jaenicke implemented
> > PRNGD, it is strongly recommended (at least by me) that mail servers
> > use PRNGD or similar. PRNGD delivers psuedo-random numbers mixing in
> > real entr
I wrote:
>>If the problem is a shortage of random bits, get more random bits!
Florian Weimer responded:
We are talking about a stream of several kilobits per second on a busy
server (with suitable mailing lists, of course). This is impossible
to obtain without special hardware.
Not very special, a
* John Denker:
> Florian Weimer wrote:
>
>> Would you recommend to switch to /dev/urandom (which doesn't block if
>> the entropy estimate for the in-kernel pool reaches 0), and stick to
>> generating new DH parameters for each connection,
>
> No, I wouldn't.
Not even for the public parameters?
>
* Victor Duchovni:
>> The Debian folks have recently stumbled upon a problem in this area:
>> Generating the ephemeral DH parameters is expensive, in terms of CPU
>> cycles, but especailly in PRNG entropy. The PRNG part means that it's
>> not possible to use /dev/random on Linux, at least on serv
On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote:
> * Victor Duchovni:
>
> > The third mode is quite common for STARTTLS with SMTP if I am not
> > mistaken. A one day sample of inbound TLS email has the following cipher
> > frequencies:
> >
> > 8221(using TLSv1 with cipher DHE-R
Florian Weimer wrote:
Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection,
No, I wouldn't.
> or ...
generate them once per day and use it for several connections?
* Victor Duchovni:
> The third mode is quite common for STARTTLS with SMTP if I am not
> mistaken. A one day sample of inbound TLS email has the following cipher
> frequencies:
>
> 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> 6529(using TLSv1 with cipher EDH-RSA-DES-CB
Anton Stiglic wrote:
I found allot of people mistakenly use the term certificate to mean
something like a pkcs12 file containing public key certificate and private
key. Maybe if comes from crypto software sales people that oversimplify or
don't really understand the technology. I don't know, but
>This sounds very confused. Certs are public. How would knowing a copy
>of the server cert help me to decrypt SSL traffic that I have intercepted?
I found allot of people mistakenly use the term certificate to mean
something like a pkcs12 file containing public key certificate and private
key.
On Wed, 1 Dec 2004, Anne & Lynn Wheeler wrote:
> the other attack is on the certification authorities business process
Note that in a fair number of Certificate issuing processes common in
industry the CA (sysadmin) generates both the private key -and-
certificate, signs it and then exports bot
At 02:53 AM 12/1/2004, Dirk-Willem van Gulik wrote:
Access to the private key of the server cert gives you the ability to do
active sniffing and in some subset of cases passive sniffing. Access to
the session key (which requires the right permissions and access to the
httpd server) gives you passiv
[EMAIL PROTECTED] writes:
>> -Original Message-
>> From: Eric Rescorla [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, December 01, 2004 7:01 AM
>> To: [EMAIL PROTECTED]
>> Cc: Ben Nagy; [EMAIL PROTECTED]
>> Subject: Re: SSL/TLS passive sniffing
On Tue, 30 Nov 2004, Ben Nagy wrote:
> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise. Recently a discussion came up on firewall-wizards about
> passively sniffing SSL traffic by a third party, using a copy of the server
Access to the private key
> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 01, 2004 7:01 AM
> To: [EMAIL PROTECTED]
> Cc: Ben Nagy; [EMAIL PROTECTED]
> Subject: Re: SSL/TLS passive sniffing
>
> "Ian Grigg" <[EMAIL PROTECTED]>
Jack Lloyd <[EMAIL PROTECTED]> writes"
>Looking at my logs, about 95% of all STARTTLS connections are DHE-RSA-AES256-
>SHA; I'm guessing this is because most STARTTLS-enabled SMTP servers (ie
>Postfix, Sendmail, Qmail) use OpenSSL, and recent versions of OpenSSL have
>DHE-RSA-AES256-SHA as the top
OK, Ian and I are, rightly or wrongly, on the same page here. Obviously my
choice of the word certificate has caused confusion.
[David Wagner]
> This sounds very confused. Certs are public. How would
> knowing a copy
> of the server cert help me to decrypt SSL traffic that I have
> intercepted
> Ian Grigg writes:
>>I note that disctinction well! Certificate based systems
>>are totally vulnerable to a passive sniffing attack if the
>>attacker can get the key. Whereas Diffie Hellman is not,
>>on the face of it. Very curious...
>
> No, that is not accurate. Diffie-Hellman is also insecu
By an interesting coincidence, the article below appeared in the on-line
Computerworld today.
-- Jerry
Universities grapple with SSL-busting spyware
Marketscore could be used to intercept sensitive
in
On Tue, Nov 30, 2004 at 01:39:42PM -0500, Victor Duchovni wrote:
> The third mode is quite common for STARTTLS with SMTP if I am not
> mistaken. A one day sample of inbound TLS email has the following cipher
> frequencies:
>
> 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>
On Tue, Nov 30, 2004 at 07:15:44AM -0800, Eric Rescorla wrote:
> SSL has all three of these modes, actually, so perhaps the question
> you want to ask is why noone uses #3. The main argument against it is
> that it's about half as fast (on the server) in the best case because
> you need to do both
Ben raises an interesting thought:
> There was some question about whether this is possible for connections that
> use client-certs, since it looks to me from the spec that those connections
> should be using one of the Diffie Hellman cipher suites, which is obviously
> not vulnerable to a passive
Hi Ben,
> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise.
That's what most of us really are, to be fair. Crypto is
such a small part of security that most all crypto people
move across to general security once they realise there
isn't much work ar
"Ben Nagy" <[EMAIL PROTECTED]> writes:
> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise. Recently a discussion came up on firewall-wizards about
> passively sniffing SSL traffic by a third party, using a copy of the server
> cert (for, eg, IDS purpos
28 matches
Mail list logo
