Subscribe

Atom feed – Twitter Blog/Full

E-mail:

Jethro Beekman on
Technology & Policy

On OpenSSH and Logjam

by Jethro Beekman – May 20, 2015 . Filed under: English, Technology, Security, SSH.

Recent work showing the feasibility of calculating discrete logarithms on large integers has put the Diffie-Hellman key exchange parameters we use every day in the spotlight. I have looked at what this means for SSH key exchange. In short, on your SSH server, do the following:

awk '{ if ($5 <= 2000) printf "#"; print }' /etc/ssh/moduli > /tmp/large_moduli
mv /tmp/large_moduli /etc/ssh/moduli

And put the following in your sshd_config:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
              ecdh-sha2-nistp384,ecdh-sha2-nistp521,
              diffie-hellman-group14-sha1,
              diffie-hellman-group-exchange-sha1,
              diffie-hellman-group-exchange-sha256

Note that curve25519-sha256@libssh.org is only supported in OpenSSH 6.5 and up, and only works reliably in OpenSSH 6.7 and up. On your SSH client, put the following in your ssh_config:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
              ecdh-sha2-nistp384,ecdh-sha2-nistp521,
              diffie-hellman-group14-sha1

If with this configuration you are unable to connect to some SSH servers, and you need to add diffie-hellman-group-exchange-sha1 or diffie-hellman-group-exchange-sha256 to the supported list of algorithms, you should recompile your SSH client with a DH_GRP_MIN of 2048, so that a server can’t force your client to use a weak group.

Technical details

Now follows a detailed explanation of these recommendations. The following key exchange mechanisms are supported in the current version (6.8) of OpenSSH:

  • curve25519-sha256@libssh.org
  • ecdh-sha2-nistp256
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • diffie-hellman-group1-sha1
  • diffie-hellman-group14-sha1
  • diffie-hellman-group-exchange-sha1
  • diffie-hellman-group-exchange-sha256

The first four mechanisms, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, do not use prime-field Diffie-Hellman and are not affected. Previous work shows that these mechanisms are much faster when used at the same security level, so you should use them!

The diffie-hellman-group1-sha1 mechanism uses the fixed 1024-bit Oakley Group 2 (not the 768-bit group 1, as the name of the mechanism might suggest). This group is within the range of being a viable target for nation-state attackers, and should not be used.

The diffie-hellman-group14-sha1 mechanism uses the fixed 2048-bit Oakley Group 14, which should be secure enough for now.

The diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256 mechanisms let the client and server negotiate a custom DH group. The client sends a tuple «min, n, max» to the server, indicating the client’s minimum, preferred and maximum group size. According to the RFC,

Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.

The OpenSSH server selects a suitable group from a pre-generated set of groups, installed system-wide in /etc/ssh/moduli (falling back to /etc/ssh/primes), using the choose_dh function in dh.c. In case no suitable group is found, the code defaults to Oakley Group 14, which is safe. A pre-generated set is distributed with the OpenSSH source and many binary distributions and is infrequently changed. The group sizes distributed with OpenSSH are 1024, 1536, 2048, 3072, 4096, 6144, and 8192 bits, with about 30 groups per size. The OpenSSH-distributed 1024-bit groups are well-known and within the range of being a viable target for nation-state attackers, and as such should not be used.

It is possible to generate your own set of groups, in which case it would be safer to use a 1024-bit group, but you might as well go for larger groups. The ssh-keygen man page mentions that “It is important that … both ends of a connection share common moduli.” That statement should not be interpreted as “both server and client need to have the same moduli configured”, as the server sends the chosen modulus to the client. As a case-in-point, the OpenSSH client does not access the system-wide moduli file at all during connection setup.

Speaking about the client, it usually offers the RFC-specified minimum of 1024 bits. There is nothing preventing a server from using that value and offering a well-known (and thus weak) group. So, a standard client shouldn’t use the custom group key exchange mechanisms, unless there is a way to change the minimum group size.