Weak DH primes and openssh

[David McBride]

On 27/05/15 10:58, Darren Tucker wrote:
> diffie-hellman-group-exchange-sha256 and diffie-hellman-group-exchange-sha1
> use the same message type defined in RFC4419 to request a group, and PuTTY
> up to 0.64 uses the same deprecated message type (30) for both.
> 
> See
>> https://anongit.mindrot.org/openssh.git/commit/?id=318be28cda1fd9108f2e6f2f86b0b7589ba2aed0
>>
>> + if ((datafellows & SSH_OLD_DHGEX) != 0) {
>> +         p = filter_proposal(p, "diffie-hellman-group-exchange-sha256");
>> +         p = filter_proposal(p, "diffie-hellman-group-exchange-sha1");
>> + }
>>
> The removal of the pre-RFC4419 message type in OpenSSH was made after the
> last release.   Please retry your test with a current development snapshot.

Ouch.  Thank you very much for chasing this down; while I haven't
compiled up a current development OpenSSH snapshot and re-run my
previous experiment, I assume you're correct.

Digging through the PuTTY git repository, the corresponding update that
adds SSH_MSG_KEX_DH_GEX_REQUEST (as opposed to _REQUEST_OLD) support is
here:

http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commit;h=62a1bce7cb3ecb98feb57c7f1fd5d55845ce1533

... and so should become available in the next PuTTY release, along with
elliptic-curve key-exchange and host key support.

The pragmatic consequence is that I should not disable both -group1-sha1
and -group14-sha1 key-exchange support on my servers, nor suggest others
to do the same, as this configuration will break compatibility with
current versions of PuTTY when the configuration is inherited by future
versions of OpenSSH.

(As you might expect, PuTTY is quite widely used within Cambridge.
Also, judging from some of the screenshots of other Windows SSH/SFTP
software, it appears that a fair amount of the PuTTY codebase can be
found in other tools as well.)

Pragmatically, the conclusion I've reached is that, while it would
involve violating an RFC MUST, disabling -group1-sha1 while leaving
-group14-sha1 support enabled should not significantly affect
interoperability, and would address concerns that users with antiquated
or misconfigured SSH clients would reveal sensitive data to state-level
passive observers.

I am conscious that I am not an expert, so please do correct me if any
of this appears to be wrong or foolish.

Would it be virtuous to postpone the application of the SSH_OLD_DHGEX
commit you reference above until after the new version of PuTTY has been
released and has time to enter circulation?

Kind regards,
David
-- 
David McBride <dwm37 at cam.ac.uk>
Unix Specialist, University Information Services