[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions



Micah Anderson un jour écrivit:
* Simon Valiquette <v.simon@ieee.org> [2008-05-14 16:36-0400]:

In other words, if a vulnerable key have been involved, and if someone was able to intercept and save the encrypted data, he/she can now decipher It, whether It is passwords, ssh sessions, secure pop/smtp sessions, ssl tunnels or even database transactions. So you need to change every passwords at risk (bothersome, but relatively easy), but also consider that secure/confidential information, including credit card transactions or whatever, have been disclosed, which is a much bigger problem.

SSH traffic cannot be compromised that way. Basically the encryption key
used for the SSH session is *not* the host key nor the client key
itself, but it is created on session initiation using a Diffie-Helman
key exchange

  I know, and I though It was obvious in my email that I was aware of that.

The problem is that, AFAIK, the encryption key generated for the session is also build by openssl. If the bug we talk about also affect DH, then I believe that the probable random number "a" and "b" could be limited to a much smaller group, and thus one could try to guess the shared session key "g exp(ab)" if the number of possibilities are small enough to make an exhaustive search.

and the host/client keys are just used to verify the
authenticity of the server.

In other words, ssh sessions are not
compromised just because an adversary has the host keys (unless a MITM
is setup, in which case you need bot the host key and the authentication
key to perform a mitm attack).

I insisted on the case where *none* of the host key where vulnerable (my case on many systems), but one or two of the host involved used a vulnerable openssl library. So, this is a different problem.

Generating good random number properly are difficult enough that I would expect them to came from the same function. I didn't have time to look at the code, and I would be more than happy to be proven wrong.

Simon Valiquette


Reply to: