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

[Simon Valiquette <v.simon@ieee.org>]

> Affected keys include SSH keys [...] and session keys used
> in SSL/TLS connections.

  It seems that people are insisting quite a lot on the bad keys, but 
what worry me a lot more is that, apparently and very logically, past ssh 
connections and any SSL session keys are to be considered compromised.

  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.

  I think that most security knowledgeable people understood that part. 
For the others, then It is good that you understand It clearly now.


  But what still bother me a bit, is in the case that both host keys are 
not vulnerable, but one of the openssl implementation involved was.

  For example, I have many host keys that have been generated from 
Slackware or OpenBSD, and which are much longer than the default, so 
clearly not vulnerable (at least, not vulnerable to this specific bug).

  But even in that case, if one of the system involved in a SSL 
transaction have a buggy version of openssl, I wonder if the session key 
might still be guessed.  If the vulnerable host is A, then my 
understanding is that an attacker could guess "a" and "g exp(a)", so that 
if he can get either "b" or "g exp(b)", he can crack the session key.

  In other words, if host A and host B use a flawed openssl 
implementation, then the communication can be compromised even if both 
host keys are not vulnerable.

  Here are my questions:

1. If both host use a flawed openssl, but good host keys, about how much 
sessions keys the attacker will have to try?  I expect that would be the 
square of the number of probable values for "a", but I have no idea of the 
number of probable values for a.

2. About how much time would It takes to break one session key, let say 
using a small setup with 8 pentium IV at 2GHz just to give an idea.  My 
uneducated guess is that It could theorically takes significantly less 
than a week.

3. If only one of the computer involved have a flawed openssl, but none 
have a vulnerable host key, is It still practical to break the session 
key?  If yes, about how long could It takes?

  The Diffie-Hellman algorithm is far in my memory, including the exact 
way It is used in setting up an SSL transaction.  I think that the 
exchanged data are both signed *and* ciphered using RSA or DSA.  If I am 
right, all the "public" data are exchanged using the public host keys, so 
if they are not vulnerable, maybe there is not enough information known to 
the attacker easily crack the session key, even if the session key have 
obviously been significantly weakened.

  And a last question that came to my mind:

4. During the session key creation, do there is still some entropy left 
from the clock, or something other than the process id?  If you answered 
question 1, you can probably easily answer this one.

  I still need to change the passwords and host key of every possibly 
affected system (mostly done), but I would feel better by knowing exactly 
what to expect.

  Thank you,

Simon Valiquette