And what about SSH?

Posted May 21, 2015 14:48 UTC (Thu) by cesarb (subscriber, #6266)
Parent article: Another crypto downgrade attack: Logjam

People seem to be talking mostly about TLS (where the break is more worrying), so I couldn't find enough information to answer the following question:

How much should we worry about SSH?

From my quick look at the "ssh -v" output, it seems to require at least a 1024-bit DH group when not using the newer elliptic curves. From what I have read, the DH group used comes from /etc/ssh/moduli, which doesn't seem to be regenerated on install at least on Ubuntu (I already found two machines with identical /etc/ssh/moduli files on a quick look). Would a state-level attacker have done the required precomputation for the /etc/ssh/moduli found in common Linux distributions?

And what about SSH?

Posted May 22, 2015 14:33 UTC (Fri) by robbe (guest, #16131) [Link]

https://weakdh.org/sysadmin.html (linked in the article) not only has instructions for a couple of webservers, but also for ssh, postfix, etc.

And what about SSH?

Posted May 22, 2015 14:59 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (3 responses)

Yes, it is reasonable to think that a resourceful state actor _might_ have pre-computed answers for this popular modulus. This would allow them to passively eavesdrop SSH sessions using conventional DH with the affected settings, and also of course if they have complete transcripts, to play back older sessions using those settings. Likewise someone who cannot afford the work today, but does keep transcripts of encrypted sessions, will know that in the future they may be able to afford to decode them.

Regenerating the values should be done very carefully, or else not at all, since erroneous inputs destroy the security of DH entirely. Switching towards Elliptic Curves may be a better choice.

And what about SSH?

Posted May 22, 2015 21:04 UTC (Fri) by wahern (subscriber, #37304) [Link] (2 responses)

In retrospect we would have been better off randomly generating primes for DH rather than using fixed ones. Yes, you may generate a non-strong prime. But the likelihood is extraordinarily low as long as you generate what's called a safe prime. Fortunately, OpenSSL generates safe primes. (See crypto/dh/dh_gen.c.) It's why `openssl dhparam 1024` takes so much longer than `openssl genrsa 1024`.

In other words, just use OpenSSL to generate new DH parameters and move on to improving the rest of your software and infrastructure.

And what about SSH?

Posted May 24, 2015 9:35 UTC (Sun) by reubenhwk (guest, #75803) [Link] (1 responses)

generating a new DH* in OpenSSL can be very slow, especially 1024+ bits. It's not something you really want to do on startup. Better to read the p & g params from a file, then fork off a new process to generate new p & g in the background then write them out when done...

And what about SSH?

Posted May 27, 2015 17:40 UTC (Wed) by flussence (guest, #85566) [Link]

Something seems off here: `openssl dhparam 3072` takes 3-4 minutes for me on a fairly high end Intel server CPU, which is in line with what you said, but the gnutls equivalent `certtool --generate-dh-params --sec-param=high` takes 1-2 *seconds*.