DH Group Exchange Fallback

Joseph S Testa II jtesta at positronsecurity.com
Sun Sep 24 03:21:49 AEST 2017


On 09/22/2017 06:10 PM, Mark D. Baushke wrote:
 > I suppose you want to be more paranoid:
 >
 > DH *
 > dh_new_group_fallback(int max)
 > {
 >          debug3("%s: requested max size %d", __func__, max);
 >          if (max <= 2048) {
 >                  debug3("using 2k bit group 14");
 >                  return dh_new_group14();
 >          } else if (max <= 4096) {
 >                  debug3("using 4k bit group 16");
 >                  return dh_new_group16();
 >          }
 >          debug3("using 8k bit group 18");
 >          return dh_new_group18();
 > }

This wouldn't fix the underlying issue.  I'm interested in having the 
code respect the admin's wishes.  If the admin edits out entries in 
/etc/ssh/moduli, the server should follow that 100%, and not sometimes 
make decisions on its own, against what the admin told it point-blank. 
Both the existing code, and the above change results in unexpected behavior.

It seems like removing the fallback mechanism entirely is the way to go. 
  If the server and client can't agree on a group-exchange, then the 
attempt should fail.  And after all, the client is free to try again 
with another kex.

FYI, the OpenSSH client (v6.6) in Linux Mint 17 (which is a couple years 
old) requests a range of 1024 - 8192 bits by default.  I can look into 
what PuTTY does, if anyone is interested.  I strongly suspect, though, 
that modern clients aren't going to be impacted by removing the fallback.

    - Joe


More information about the openssh-unix-dev mailing list