Re: SSL/TLS passive sniffing

[Werner Koch]

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, but I
> still don't understand how it is supposed to happen. If the PRNG uses a

It is a practical issue: Using /dev/urandom to avoid waiting for a
blocked /dev/random will let other processes wait infinitely on a
blocked /dev/random.

The Linux implementation of /dev/urandom is identical to /dev/random
but instead of blocking, (as /dev/random does on a low entropy
estimation) it continues to give output by falling back to a PRNG mode
of operation.

For services with a high demand of random it is probably better to
employ its own PRNG and reseed it from /dev/random from time to time.


Salam-Shalom,

   Werner




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Janusz A. Urbanowicz]

 
> [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
magnetometers based on properties of Josephson junction. For more info, see
. I guess a better reference, instead of
SQUIDs, in the threat model you discuss would be Van Eck phreaking or its
military incarnation i.e. TEMPEST. And moreover if TEMPEST is called into
view, there are many other ways the information can be leaked, than tapping
CPU's ALU.

Alex
-- 
mors ab alto 
0x46399138

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Enzo Michelangeli]

- 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 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 entropy periodically.
>
> 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, but I
still don't understand how it is supposed to happen. If the PRNG uses a
really non-invertible algorithm (or one invertible only with intractable
complexity), its output gives no insight whatsoever on its internal state.
As entropy is a measure of the information we don't have about the
internal state of a system, it seems to me that in a good PRNGD its value
cannot be reduced just by extracting output bits. If there is an entropy
estimator based on the number of bits extracted, that estimator must be
flawed.

Enzo


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Greg Rose]

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 wouldn't.
Not even for the public parameters?
Am I understanding correctly? Does SSL/TLS really generate a new P and G 
for each connection? If so, can someone explain the rationale behind this? 
It seems insane to me. And not doing so would certainly ease the problem on 
the entropy pool, not to mention CPU load for primality testing.

I must be misunderstanding. Surely. Please?
Greg.

Greg RoseINTERNET: [EMAIL PROTECTED]
Qualcomm Incorporated VOICE: +1-858-651-5733   FAX: +1-858-651-5766
5775 Morehouse Drivehttp://people.qualcomm.com/ggr/
San Diego, CA 92121   232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Andy Isaacson]

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 that it's
> >> not possible to use /dev/random on Linux, at least on servers.  The
> >> CPU cycles spent on bignum operations aren't a real problem.
> >> 
> >> 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, or is it better to
> >> generate them once per day and use it for several connections?
> >
> > 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 entropy periodically.

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.)

> > EGD, /dev/random and /dev/urandom don't produce bits fast enough.
> 
> Is this the only criticism of /dev/urandom (on Linux, at least)?  Even
> on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out
> of /dev/urandom, which is more than enough for our purposes.  (It's
> not a web server, after all.)

On my PIII/666 running 2.4.26, I get 1.4 MB/sec from /dev/urandom.
Seems plenty fast enough to me.  (Fast, of course, being orthogonal to
secure.)

> I'm slightly troubled by claims such as this one:
> 
>   
> 
> I know that Linux' /dev/random implementation has some problems (I
> believe that the entropy estimates for mouse movements are a bit
> unrealistic, somewhere around 2.4 kbps), but the claim that generating
> session keys from /dev/urandom is a complete no-no is rather
> surprising.

I'm baffled by the post you reference:

Andrew Suffield writes on Mon, 20 Dec 2004 06:11:08 -
> The security of the session is limited by the randomness of the
> weakest key used. If you're going to use /dev/urandom then you might
> as well just not encrypt the session at all. It wouldn't be massively
> less secure, and it would be quite a lot faster.

I *think* what that says is "generating a session key based on entropy
from /dev/urandom is security-equivalent to no encryption at all".
Which is so obviously false that I can't imagine that I'm not
misreading.  I will grant that *if* an attacker can reconstruct the
state of the entropy pool (which in theory is possible if the attacker
can gather N bits of information about the outputs, but would require a
significant advance over the state of the art in cryptanalysis of the
hash function, and probably about 2^N work) then a key generated from it
is insecure.  But the difficulty of extracting that much information
about the entropy pool is enormous, and the challenge of reconstructing
the state, given that information, is ... large.

It would be less work to build a SQUID [1] and snoop the operation of
your ALU from the white van parked across the street from the data
center.

So, I agree with you - while it would be preferable to generate session
keys using the most conservative entropy estimates, it's a perfectly
reasonable engineering compromise to use /dev/urandom.  I'd rather have
Good Enough encryption, universally deployed, than fall for the Purity of
Essence^H^H^H^H^H^H^HRandomness whackos' claims that "Everyone must plug
a Geiger counter into their serial port or We're All Going To Die".

BTW, the Linux kernel guys are actively working on improving the
security of /dev/*random and could benefit from experienced
cryptographers willing to review work and make suggestions.  Check out
the linux-kernel archives for the past few months for subjects
mentioning /dev/urandom and /dev/random.

[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.

-andy

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Victor Duchovni]

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 entropy periodically.
> >
> > EGD, /dev/random and /dev/urandom don't produce bits fast enough.
> 
> Is this the only criticism of /dev/urandom (on Linux, at least)?  Even
> on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out
> of /dev/urandom, which is more than enough for our purposes.  (It's
> not a web server, after all.)
> 
> I'm slightly troubled by claims such as this one:
> 
>   
> 

I think I made a mistake, my primary email servers don't have /dev/urandom
and the choice between EGD and PRNGD came down clearly on the PRNGD side,
but indeed /dev/urandom should suffice on Linux and other systems. Postfix
takes additional steps to reduce demand for raw entropy (in the tlsmgr
process, ...) but /dev/urandom works fine as an external entropy source.

I have not followed the debian issue, perhaps that really is just an
Exim+TLS design problem... 

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[John Denker]

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, as I explained:
Almost every computer sold on the mass market these days has a sound
system built in. That can be used to generate industrial-strength
randomness at rates more than sufficient for the applications we're
talking about.  
How many bits per second can you produce using an off-the-shelf sound
card?  Your paper gives a number in excess of 14 kbps, if I read it
correctly, which is surprisingly high.
1) You read it correctly.
  http://www.av8n.com/turbid/paper/turbid.htm#tab-soundcards
2) The exact number depends on details of your soundcard.  14kbits/sec
was obtained from a plain-vanilla commercial-off-the-shelf desktop
system with AC'97 audio.  You can of course do worse if you try (e.g.
Creative Labs products) but it is easy to do quite a bit better.
I obtained in excess of 70kbits/sec using an IBM laptop mgfd in
1998.
3) Why should this be surprising?
It's an interesting approach, but for a mail server which mainly sends
to servers with self-signed certificates, it's overkill.  
Let's see
 -- Cost = zero.
 -- Quality = more than enough.
 -- Throughput = more than enough.
I see no reason why I should apologize for that.
Debian also
supports a few architectures for which sound cards are hard to obtain.
And we would separate desktop and server implementations because the
sound card is used on desktops.  I'd rather sacrifice forward secrecy
than to add such complexity.
As the proverb says, no matter what you're trying to do, you can always
do it wrong.  If you go looking for potholes, you can always find a
pothole to fall into if you want.
But if you're serious about solving the problem, just go solve the
problem.  It is eminently solvable;  no sacrifices required.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Florian Weimer]

* 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?

>> or ...  generate them once per day and use it for several
>> connections?
>
> I wouldn't do that, either.

> If the problem is a shortage of random bits, get more random bits!

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.

> Almost every computer sold on the mass market these days has a sound
> system built in. That can be used to generate industrial-strength
> randomness at rates more than sufficient for the applications we're
> talking about.  

How many bits per second can you produce using an off-the-shelf sound
card?  Your paper gives a number in excess of 14 kbps, if I read it
correctly, which is surprisingly high.

It's an interesting approach, but for a mail server which mainly sends
to servers with self-signed certificates, it's overkill.  Debian also
supports a few architectures for which sound cards are hard to obtain.
And we would separate desktop and server implementations because the
sound card is used on desktops.  I'd rather sacrifice forward secrecy
than to add such complexity.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Florian Weimer]

* 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 servers.  The
>> CPU cycles spent on bignum operations aren't a real problem.
>> 
>> 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, or is it better to
>> generate them once per day and use it for several connections?
>> 
>
> 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 entropy periodically.
>
> EGD, /dev/random and /dev/urandom don't produce bits fast enough.

Is this the only criticism of /dev/urandom (on Linux, at least)?  Even
on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out
of /dev/urandom, which is more than enough for our purposes.  (It's
not a web server, after all.)

I'm slightly troubled by claims such as this one:

  

I know that Linux' /dev/random implementation has some problems (I
believe that the entropy estimates for mouse movements are a bit
unrealistic, somewhere around 2.4 kbps), but the claim that generating
session keys from /dev/urandom is a complete no-no is rather
surprising.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Victor Duchovni]

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-RSA-AES256-SHA (256/256 bits))
> > 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
> 
> 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 servers.  The
> CPU cycles spent on bignum operations aren't a real problem.
> 
> 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, or is it better to
> generate them once per day and use it for several connections?
> 

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 entropy periodically.

EGD, /dev/random and /dev/urandom don't produce bits fast enough. Also
Postfix internally seeds the built-in OpenSSL PRNG via the tlsmgr process
and this hands out seeds for smtp servers and clients, so the demand for
real entropy is again reduced.

Clearly a PRNG is a compromise (if the algorithm is found to be weak we
could have problems), but real entropy is just too expensive.

I use PRNGD.

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[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.
> or ...
generate them once per day and use it for several connections?
I wouldn't do that, either.

If the problem is a shortage of random bits, get more random bits!
Almost every computer sold on the mass market these days has a sound
system built in. That can be used to generate industrial-strength
randomness at rates more than sufficient for the applications we're
talking about.  (And if you can afford to buy a non-mass-market
machine, you can afford to plug a sound-card into it.)
For a discussion of the principles of how to get arbitrarily close
to 100% entropy density, plus working code, see:
  http://www.av8n.com/turbid/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Florian Weimer]

* 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-CBC3-SHA (168/168 bits))

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 servers.  The
CPU cycles spent on bignum operations aren't a real problem.

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, or is it better to
generate them once per day and use it for several connections?

(There's a second set of parameters related to the RSA_EXPORT mode in
TLS, but I suppose it isn't used much, and supporting it is not a top
priority.)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Anne & Lynn Wheeler]

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 it's a rant I
have.  
 

i just had went off on possibly similar rant in comp.security.ssh where 
a question was posed about "password
or certficate"
http://www.garlic.com/~lynn/2004p.html#60
http://www.garlic.com/~lynn/2004q.html#0

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: SSL/TLS passive sniffing

[Anton Stiglic]

>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.  Maybe if comes from crypto software sales people that oversimplify or
don't really understand the technology.  I don't know, but it's a rant I
have.  

>Now if I had a copy of the server's private key, that would help, but such
>private keys are supposed to be closely held.

>Or are you perhaps talking about some kind of active man-in-the-middle
>attack, perhaps exploiting DNS spoofing?  It doesn't sound like it, since
>you mentioned passive sniffing.

I guess the threat would be something like an adversary getting access to a
web server, getting a hold of the private key (which in most cases is just
stored in a file, allot of servers need to be bootable without intervention
as well so there is a password somewhere in the clear that allows one to
unlock the private key), and then using it from a distance, say on a router
near the server where the adversary can sniff the connections.  A malicious
ISP admin could pull off something like that, law authority that wants to
read your messages, etc.

Is that a threat worth mentioning?  Well, it might be.  In any case,
forward-secrecy is what can protect us here.  Half-certified (or fully
certified) ephemeral Diffie-Hellman provides us with that property.

Of course, if someone could get the private signature key, he could then do
a man-in-the-middle attack and decrypt all messages as well.  It wouldn't
really be that harder to pull off.

--Anton


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Dirk-Willem van Gulik]

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 both to the user their PC (usually
as part of a VPN or Single Sing on setup). I've seen situations more than
once where the 'CA' keeps a copy of both on file. Generally to ensure that
after the termination of an employeee or the loss of a laptop things 'can
be set right' again.

Suffice to say that this makes evesdropping even easier.

Dw

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Anne & Lynn Wheeler]

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 passive sniffing.
It is not uncommon to set this up for customers in the commercial/banking
sectors to help them comply with certain audit requirements.
Note however that in each case it requires violating the web servers
security realm and/or storing something in two places. So technically it
may make much more sense to plug a module into each webserver itself with
a sufficiently secure agregation backend to accomplish this.

the other attack is on the certification authorities business process 
... crook gets the issuing authority to give them a certificate with all 
the same information ... but their public key; the key-owner may have 
little control over the long term business process standards of the 
issuing certification authority

This is one of the attacks on SSL domain name server certificates.  
Supposedly the purpose for SSL domain name server certificates was some 
perceived vulnerabilities in the domain name infrastructure. Note, 
however, the authoritative agency(s) for domain name ownership is the 
domain name infrastructure. The current process has a SSL domain name 
server certificate applicant supplying some amount of identification 
information. The certification authority then has the error-prone and 
expensive job of contacting the domain name infrastructure 
(authoritative agency for domain name ownership) and comparing the 
supplied identification information (provided with the certificate 
application) with what is on file at the domain name infrastructure.

The attack isn't on the process that was used for the valid applicant 
... the issue is that at any time in the future, can an attacker 
compromise that process  using any recognized, valid, certification 
authority.

The side note is that the certification authority industry has somewhat 
pushed a business process where the domain name supplies their public 
key to the domain name infrastructure at the time they register the 
domain name. Then when somebody applies for a SSL domain name server 
certificate, they digitally sign the request. The certification 
authority then just has to retrieve the on-file public key from the 
domain name infrastructure and validate the digital signature. This 
turns an expensive and error-prone identification process into a much 
more reliable and less expensive authentication process.

The catch22 of course, is that if the certification authorities can 
retrieve public keys from the domain name infrastructure for 
authentication ... then just about anybody in the world could do the 
same thing  significantly reducing the need for any SSL domain name 
server certificates.

misc past postings:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
 
http://www.garlic.com/~lynn/subpubkey.html#certless


--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ 


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Eric Rescorla]

[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
>> 
>> "Ian Grigg" <[EMAIL PROTECTED]> writes:
> [...]
>> > However could one do a Diffie Hellman key exchange and do this
>> > under the protection of the public key? [...]
>> 
>> Uh, you've just described the ephemeral DH mode that IPsec
>> always uses and SSL provides.
>> 
>> Try googling for "station to station protocol"
>> 
>> -Ekr
>
> Right. And my original question was, why can't we do that one-sided with
> SSL, even without a certificate at the client end? In what ways would that
> be inferior to the current RSA suites where the client encrypts the PMS
> under the server's public key.

Just to be completely clear, this is exactly whatthey 
TLS_RSA_DHE_* ciphersuites currently do, so it's purely a matter
of configuration and deployment.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Dirk-Willem van Gulik]

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 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 passive sniffing.

It is not uncommon to set this up for customers in the commercial/banking
sectors to help them comply with certain audit requirements.

Note however that in each case it requires violating the web servers
security realm and/or storing something in two places. So technically it
may make much more sense to plug a module into each webserver itself with
a sufficiently secure agregation backend to accomplish this.

However due to widely varying workflow/bisprocesses at customers I have
found myself doing both.

As a closing note - the attitude of personal towards the confidentiality
of data gathered by IDS and Firewall running departments is often a lot
different than that of those directly resp. for the biz processes due to
their different roles and responsibilities ('everyone is bad' v.s.
'customers are sacret') - which is something you want to take into
account.

Dw.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: SSL/TLS passive sniffing

[ben]

> -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]> writes:
[...]
> > However could one do a Diffie Hellman key exchange and do this
> > under the protection of the public key? [...]
> 
> Uh, you've just described the ephemeral DH mode that IPsec
> always uses and SSL provides.
> 
> Try googling for "station to station protocol"
> 
> -Ekr

Right. And my original question was, why can't we do that one-sided with
SSL, even without a certificate at the client end? In what ways would that
be inferior to the current RSA suites where the client encrypts the PMS
under the server's public key.

Eric's answer seems to make the most sense - I guess generating the DH
exponent and signing it once per connection server-side would be a larger
performance hit than I first thought, and no clients care.

Thanks for all the answers, on and off list. ;)

Cheers,

ben



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Peter Gutmann]

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 preference cipher by default.

I was just about to point that out myself.  I'd expect for more usual TLS
usage (web browser/server) it'd be 99+% RSA-*.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: SSL/TLS passive sniffing

[Ben Nagy]

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?

Yes, sorry, what I _meant_ was the whole certificate file, PFX style, also
containing private keys. I assure you, I'm not confused, just perhaps guilty
of verbal shortcuts. I should, perhaps, have not characterised myself as
'bumbling enthusiast', to avoid the confusion with 'idiot'. :/

[...]
> 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 insecure if 
> the "private
> key" is revealed to the adversary.  The "private key" for 
> Diffie-Hellman
> is the private exponent.

No, I'm not talking about escrowing DH exponents. I'm talking about modes
like in IPSec-IKE where there is a signed DH exchange using ephemeral DH
exponents - this continues to resist passive sniffing if the _signing_ keys
have somehow been compromised, unless I have somehow fallen on my head and
missed something.

> Perhaps the distinction you had in mind is forward secrecy.

Yes and no. Forward secrecy is certainly at the root of my question, with
regards to the RSA modes not providing it and certain of the DH modes doing
so. :)

Thanks!

ben
  


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Ian Grigg]

> 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 insecure if the "private
> key" is revealed to the adversary.  The "private key" for Diffie-Hellman
> is the private exponent.  If you learn the private exponent that one
> endpoint used for a given connection, and if you have intercepted that
> connection, you can derive the session key and decrypt the intercepted
> traffic.

I wasn't familiar that one could think in those terms.  Reading
here:  http://www.rsasecurity.com/rsalabs/node.asp?id=2248 it
says:

In recent years, the original Diffie-Hellman protocol
has been understood to be an example of a much more
general cryptographic technique, the common element
being the derivation of a shared secret value (that
is, key) from one party's public key and another
party's private key. The parties' key pairs may be
generated anew at each run of the protocol, as in
the original Diffie-Hellman protocol.

It seems the compromise of *either* exponent would lead to
solution.

> Perhaps the distinction you had in mind is forward secrecy.  If you use
> a different "private key" for every connection, then compromise of one
> connection's "private key" won't affect other connections.  This is
> true whether you use RSA or Diffie-Hellman.  The main difference is
> that in Diffie-Hellman, "key generation" is cheap and easy (just an
> exponentiation), while in RSA key generation is more expensive.

Yes.  So if a crypto system used the technique of using
Diffie-Hellman key exchange (with unique exponents for each
session), there would be no lazy passive attack, where I
am defining the lazy attack as a once-off compromise of a
private key.  That is, the attacker would still have to
learn the individual exponent for that session, which
(assuming the attacker has to ask for it of one party)
would be equivalent in difficulty to learning the secret
key that resulted and was used for the secret key cipher.

iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Jerrold Leichter]

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
  information, security experts say

  News Story by Paul Roberts
  NOVEMBER 30, 2004 (IDG NEWS SERVICE) -
  U.S. universities are struggling with a flare-up of dangerous
  spyware that can snoop on information encrypted using
  Secure Sockets Layer (SSL). Experts are warning that the
  stealthy software, called Marketscore, could be used to
  intercept a wide range of sensitive information, including
  passwords and health and financial data.

  In recent weeks, IT departments at a number of
  universities issued warnings about problems caused by the
  Marketscore software, which promises to speed up Web
  browsing. The program, which routes all user traffic
  through its own network of servers, poses a real threat to
  user privacy, security experts agree.

  Columbia University, Cornell University, Indiana
  University, the State University of New York (SUNY) at
  Albany and Pennsylvania State University are among those
  noting an increase in the number of systems running
  Marketscore software in recent weeks. Each institution
  warned its users about Marketscore and posted instructions
  for removing the software.

  The software is bundled with iMesh peer-to-peer software,
  and may have made it onto university networks that way,
  said David Escalante, director of computer security at
  Boston College.

  The company that makes the software, Marketscore Inc., has
  headquarters in Reston, Va., at the same mailing address
  as online behavior tracking company ComScore Networks Inc.
  ComScore Networks did not respond to repeated requests for
  comment.

  Reports of infected systems on campuses ranged from a
  handful to as many as 200 on one large campus network,
  Escalante said.

  Marketscore is the latest incarnation of a spyware program
  called Netsetter, which first appeared in January, said
  Sam Curry, vice president of eTrust Security Management at
  Computer Associates International Inc.

  "Basically it takes all your Web traffic and forces it
  through its own proxy servers," he said.

  The redirection speeds up Web surfing, because pages
  cached on Marketscore's servers load faster than they
  would if they were served directly from the actual Web
  servers for sites such as Google or Yahoo. However, those
  performance benefits have been elusive.

  "People who have installed the software complain to us
  that they're not getting any improvement," Curry said.

  Richard Smith, an independent software consultant in
  Boston, is also skeptical of performance improvement
  claims made by Marketscore and others, especially since
  many Internet service providers already offer Web caching
  for their dial-up customers, he said in an e-mail message.

  Cornell's IT security office blocked connections between
  the university's network and the Marketscore servers,
  according to a message posted on the university's Web
  site. Administrators at SUNY Albany took similar steps,
  according to a message posted on that school's Web site.

  While other legal software programs make similar claims
  about improving Web browsing speed as Marketscore,
  Internet security experts are troubled that the software
  creates its own trusted certificate authority on
  computers. That certificate authority intercepts Web
  communications secured using SSL, decrypting that traffic,
  then sending it to the Marketscore servers before
  encrypting the traffic and passing it along to its final
  destination. That traffic could include sensitive
  information, including passwords, credit card and Social
  Security numbers, Curry said.

  Marketscore should be a big concern for companies, such as
  banks, with employees who handle sensitive data, Escalante
  said.

  "I don't know how good it is for parties on either end of
  a transaction to have a third party listening in

Re: SSL/TLS passive sniffing

[Jack Lloyd]

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))
> 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>  186(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>  117(using TLSv1 with cipher RC4-SHA (128/128 bits))
>   59(using SSLv3 with cipher RC4-SHA (128/128 bits))
>   40(using SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
>   28(using TLSv1 with cipher RC4-MD5 (128/128 bits))
>   16(using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>   14(using TLSv1 with cipher DES-CBC3-SHA (168/168 bits))
>1(using SSLv3 with cipher RC4-MD5 (128/128 bits))
>1(using SSLv2 with cipher DES-CBC3-MD5 (168/168 bits))

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 preference cipher by default.

I suspect you'd see about the same results for any other SSL service that's not
HTTP. I'm surprised to see that SSLv2 connection at the bottom... considering
that STARTTLS didn't exist until, well, TLS, I wonder what logic went into
supporting only SSLv2.

> it is my perhaps misguided impression that the both the EDH and the DHE
> cipher-suites provide PFS. Is there in fact a difference between EDH
> and DHE?

OpenSSL just calls them differently depending on the ciphers in use (an
artifact of the specifications, I think).

-Jack

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Victor Duchovni]

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 a signature and a key exchange operation.
> On the client it's *much* slower because RSA public-key encryption
> is very fast (private-key decryption is much slower). 
> 

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-CBC3-SHA (168/168 bits))
 186(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 117(using TLSv1 with cipher RC4-SHA (128/128 bits))
  59(using SSLv3 with cipher RC4-SHA (128/128 bits))
  40(using SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
  28(using TLSv1 with cipher RC4-MD5 (128/128 bits))
  16(using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
  14(using TLSv1 with cipher DES-CBC3-SHA (168/168 bits))
   1(using SSLv3 with cipher RC4-MD5 (128/128 bits))
   1(using SSLv2 with cipher DES-CBC3-MD5 (168/168 bits))

it is my perhaps misguided impression that the both the EDH and the DHE
cipher-suites provide PFS. Is there in fact a difference between EDH
and DHE?

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Ian Grigg]

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 sniffing 'attack'. Active 'attacks' will
> obviously still work. Bear in mind that we're talking about deliberate
> undermining of the SSL connection by organisations, usually against their
> website users (without talking about the goodness, badness or legality of
> that), so "how do they get the private keys" isn't relevant.

We have the dichotomy that DH protects against all passive
attacks, and a signed cert protects against most active attacks,
and most passive attacks, but not passive attacks where the
key is leaked, and not active attacks where the key is
"forged" (as a cert).

But we do not use both DH and certificates at the same time,
we generally pick one or the other.

Could we however do both?

In the act of a public key protected key exchange, Alice
generally creates a random key and encrypts that to Bob's
public key.  That random then gets used for further traffic.

However could one do a Diffie Hellman key exchange and do this
under the protection of the public key?  In which case we are
now protected from Bob aggressively leaking the public key.
(Or, to put it more precisely, Bob would now have to record
and leak all his traffic as well, which is a substantially
more expensive thing to engage in.)

(This still leaves us with the active attack of a forged
key, but that is dealt with by public key (fingerprint)
caching.)

Does that make sense?  The reason I ask is that I've just
written a new key exchange protocol element, and I thought
I was being clever by having both Bob and Alice provide
half the key each, so as to protect against either party
being non-robust with secret key generation.  (As a programmer
I'm more worried about the RNG clagging than the key leaking,
but let's leave that aside for now...)

Now I'm wondering whether the key exchange should do a DH
within the standard public key protected key exchange?
Hmmm, this sounds like I am trying to do PFS  (perfect
forward secrecy).  Any thoughts?

iang


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Ian Grigg]

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 around for a pure crypto person.  Which is
good, because only in the general security field can one
really make a difference, IMHO, because that's when starts
to understand what is needed, as opposed to what's cool.

> 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 purposes).

OK.  A nice challenge to assumptions!

> 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 sniffing 'attack'. Active 'attacks' will
> obviously still work. Bear in mind that we're talking about deliberate
> undermining of the SSL connection by organisations, usually against their
> website users (without talking about the goodness, badness or legality of
> that), so "how do they get the private keys" isn't relevant.

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...

( I had at first thought this would be related to the many
and various ways to acquire a "forged cert" but it is not.
You have to have access to the actual key in use at the
time, to conduct a passive attack.  Mind you, if you had
access to a forged cert then you could conduct an active
MITM.  But that then equates it to an active attack against
Diffie Hellman. )

> However, I was wondering why the implementors chose the construction used
> with the RSA suites, where the client PMS is encrypted with the server's
> public key and sent along - it seems to make this kind of escrowed passive
> sniffing very easy. I can't think why they didn't use something based on DH
> - sure you only authenticate one side of the connection, but who cares? Was
> it simply to save one setup packet?
>
> Anyone know?

Well.  I would say that "knowing" is rather difficult in
precise terms, even for the people who were involved in
the essential design of the first version of the PKI.  But,
for what it is worth, here are my impressions, derived from
a couple of years of (amateur) research into why SSL/PKI
is so ... obscure?  Well, pick your own term.



In the design of the SSL protocol and its associated PKI
using x.509 certs, there are a lot of decisions that are
questionable on security grounds.

There are a lot of ideas that simply don't make a lot of
sense if one is thinking from a pure security sense.  By
way of quick example, they were nominally trying to protect
credit cards from being sniffed, which would be a low value
attack.  But, they decided to downgrade things like Diffie
Hellman, which would easily have defeated a credit card
sniffing attack, by forcing in place an MITM, which would
have left easy tracks to follow.  And they downgraded the
self-signed cert, which properly employed defeats phishing
(they weren't to know that then, but clearly their view
of attacks was incomplete).  There is more and if you are
interested I'd invite you to spend an afternoon on the
rants at http://iang.org/ssl/ .

So, eventually, in searching for the driving forces behind
the protocol, one is directed away from "defeating the
threat" that was nominally on paper to other areas.  And the
goal that seems to come up most is "using CA-signed certs."

If one thinks in terms of a protocol designed to use lots of
certs, then SSL would fit that bill;  it explains in some
sense why the user cannot just create their own cert and
use that to talk to their bank.  Instead, the bank must
demand a cert, and thus demand a particular cert, one
which presumably came with specific requirements as okayed
by the bank.  It explains why email using the certs is a
dead duck;  because there is no button on people's mailers
to create a user cert.

Now, I always assumed that what was happening here was that
the original advisers to the SSL team were trying to set up
a franchise to sell certs.  There is quite a lot of evidence
to this effect.  The whole pre-crash history of Verisign is
basically that;  RSADSI had a *lot* to do with it, and they
had a financial interest in Verisign.  In the commentary of
the times, you will see repeated reference to "the search for
the revenue model."  If you recall, Netscape was caught
between a wildly successful IPO and a big barrel of cash,
and no way to return any investment to the shareholders ...

(a bit like google is now ;)

So my personal theory is that the emphasis was placed on
"the cert secures all" because "the cert wil

Re: SSL/TLS passive sniffing

[Eric Rescorla]

"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 purposes).
Yep. ssldump (http://www.rtfm.com/ssldump), for instance, will
do this.

> 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 sniffing 'attack'.
Client certificates and DH key exchange are orthogonal. Client auth
looks just like non client auth SSL except that the client signs
some data with its private key and provides its certificate. In general
it has no effect on the keying material. It's true that there is a mode
where the shared key is derived from the client and server's DH shares
in their certificates (static DH) but to a first order it's never used.

> However, I was wondering why the implementors chose the construction used
> with the RSA suites, where the client PMS is encrypted with the server's
> public key and sent along - it seems to make this kind of escrowed passive
> sniffing very easy. I can't think why they didn't use something based on DH
> - sure you only authenticate one side of the connection, but who cares? Was
> it simply to save one setup packet?

The environment in which SSL was designed to operate was one where 
in general only the server would have a certificate. In this environment,
there are approximately three different approaches:

1. Use RSA as in the current approach.
2. Have the server's DH key in its certificate and the client generates
   a random DH key for each connection. 
3. Have the server generate a new DH key for each connection and 
   sign it with its long-term key.

Now, modes (1) and (2) both have the property that someone with the
server's private key can recover the connection plaintext (you only
need one of the DH shares to recover the shared DH key). Only mode
(3) has the property (called Perfect Forward Secrecy) that having
the long-term key doesn't let you get access to the plaintext.

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 a signature and a key exchange operation.
On the client it's *much* slower because RSA public-key encryption
is very fast (private-key decryption is much slower). 

For obvious reasons, the server operators want to minimize costs
on their side and since they're the ones who would be in a position
to mount this kind of attack, they're probably not overly concerned
about it. And since the users don't demand it...

-Ekr









-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]