SSL/TLS passive sniffing

Steven M. Bellovin smb at research.att.com
Tue Nov 30 23:36:00 EST 2004


In message <200412010322.iB13MTt1027228 at taverner.CS.Berkeley.EDU>, David Wagner
 writes:
>Ben Nagy wrote:
>>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).
>
>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?
>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.
>
>And it doesn't matter whether you use Diffie-Hellman or RSA with Verisign
>certs; either way, SSL should be secure against passive eavesdropping.
>
>I think you need to elaborate before we can give any sensible responses.
>

There are products out there that use their own CA certificate to 
create new certificates for any end point you try to connect to.  If 
the user accepts the certificate of an unknown CA -- or, in some cases, 
if the organization has preconfigured user systems to trust the 
firewall CA, which I've also seen -- there's a simple MITM attack.

		--Steve Bellovin, http://www.research.att.com/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           From owner-cryptography+cryptography-archive=metzdowd.com at metzdowd.com  Wed Dec  1 02:20:59 2004
Return-Path: <owner-cryptography+cryptography-archive=metzdowd.com at metzdowd.com>
X-Original-To: cryptography-archive
Delivered-To: cryptography-archive at metzdowd.com
Received: by red.metdow.com (Postfix, from userid 1002)
	id 15A54F2A3; Wed,  1 Dec 2004 02:20:58 -0500 (EST)
X-Original-To: cryptography at metzdowd.com
Delivered-To: cryptography at metzdowd.com
Received: from snark.piermont.com (snark.piermont.com [166.84.151.72])
	by red.metdow.com (Postfix) with ESMTP id 4C45DF2A0
	for <cryptography at metzdowd.com>; Wed,  1 Dec 2004 02:20:52 -0500 (EST)
Received: by snark.piermont.com (Postfix, from userid 1000)
	id AA8AAD990F; Wed,  1 Dec 2004 01:50:22 -0500 (EST)
X-Original-To: cryptography at metzdowd.com
Received: from wbm1.pair.net (wbm1.pair.net [209.68.3.41])
	by red.metdow.com (Postfix) with SMTP id A5213F294
	for <cryptography at metzdowd.com>; Wed,  1 Dec 2004 01:11:00 -0500 (EST)
Received: (qmail 82226 invoked by uid 65534); 1 Dec 2004 06:10:36 -0000
Received: from 82.70.142.134 ([82.70.142.134])
        (SquirrelMail authenticated user john at systemics.com);
        by webmail1.pair.com with HTTP;
        Wed, 1 Dec 2004 01:10:36 -0500 (EST)
Message-ID: <3922.82.70.142.134.1101881436.squirrel at 82.70.142.134>
In-Reply-To: <200412010325.iB13PQtJ027248 at taverner.CS.Berkeley.EDU>
References: <200412010325.iB13PQtJ027248 at taverner.CS.Berkeley.EDU>
Date: Wed, 1 Dec 2004 01:10:36 -0500 (EST)
Subject: Re: SSL/TLS passive sniffing
From: "Ian Grigg" <iang at systemics.com>
To: "David Wagner" <daw at cs.berkeley.edu>
Cc: cryptography at metzdowd.com
Reply-To: iang at systemics.com
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Sender: owner-cryptography at metzdowd.com
Precedence: bulk

> 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 majordomo at metzdowd.com



More information about the cryptography mailing list