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