[Bug 2302] New: ssh (and sshd) should not fall back to deselected KEX algos

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2302

            Bug ID: 2302
           Summary: ssh (and sshd) should not fall back to deselected KEX
                    algos
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.net

Hi.

In a recent discussion[0], Christian Weisgerber pointed me to the fact
that ssh/sshd fall back to diffie-hellman-group14-sha1 if client and
server couldn't agree on parameters for DH GEX,... even when client
and/or server intentionally removed diffie-hellman-group14-sha1 from
their KEX preference list (which is like explicitly/intentionally
disabling it).

It seems that this is not exactly correct - I made some tests and it
seems that this fallback only happens if /etc/ssh/moduli is completely
empty... as long as a single entry is in the moduli file, than no
fallback seems to be performed, even if client and server couldn't
agree.
But this put all control in the hand of the server, and while one can't
protect against "evil" servers one may want to protect against servers
that are just weakly configured (without any malicious intent).


Even with the ECDH algos in places now mostly replacing the plain DH
algos, it would be nice if this fallback would no longer happen or if
it could at least be disabled (e.g. if the RFC would mandate it for a
conforming implementation).

If a user/admin removes it from his KEX algo preference list, then he
probably does so by intention and thus this shouldn't be silently
reverted again by ssh/sshd.

Further, according to e.g. the ECRYPT II recommendations,... a 2048bit
group as in group14 is only suggested for something between "legacy
standard level" and "Medium term protection",... which may not be
enough for some people.
Since its typically those people who try to disable the algo by
removing it from their preference lists, that fallback behaviour is
even more of a problem.


Of course, any such fallback mechanisms should be disabled on both
sides, ssh and sshd,... and if it happens with other algos than
diffie-hellman-group14-sha1, than that should be stopped as well.


Cheers,
Chris.

[0]
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-October/033056.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.