"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]