SSL/TLS passive sniffing

[Eric Rescorla]

"Ben Nagy" <bnagy at eeye.com> 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 majordomo at metzdowd.com