if connection trottling is configured, diffie-hellman-group-exchange-sha256 warning about bit numbers disappear

[perkelix]

Reporting aginstt what's in Git up to commit 8124c8e4430c2d570cdff3773f1d9ead0ef2bb67:

If connection trottling is enabled as a mitigation against CVE-2002-20001, all warnings about diffie-hellman-group-exchange-sha256's risks disappear.

What's expected:

(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4 `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).

What we get:

(kex) diffie-hellman-group-exchange-sha256 -- [info] available since OpenSSH 4.4

What caused this was the addition of 3 lines to sshd_config:

MaxStartups 10:30:100 PerSourceMaxStartups 1 PerSourceNetBlockSize 32:128

[jtesta]

That result makes sense. The PerSourceMaxStartups 1 setting is interfering with ssh-audit's tests. On my test machine, updating it to 2 fixes the issue. This change might make you vulnerable to the DHEat attack with that, I think (tomorrow I'll be doing more tests on this situation, specifically).

[perkelix]

It doesn't make sense. Vulnerability to low bit number doesn't disappear just because we're also testing for something else.

Which gets us back to why diffie-hellman-group-exchange-sha256 hasn't been deprecated yet.

[jtesta]

Vulnerability to low bit number doesn't disappear just because we're also testing for something else.

When PerSourceMaxStartups is set to 1, only one client can connect to OpenSSH at a time from a particular IP. ssh-audit creates multiple connections to do the group exchange tests. These multiple connections are done sequentially, but I suppose they're done so rapidly the server considers them to be in parallel. Hence they're blocked and ssh-audit cannot complete the gex tests.

You'll notice that the tests complete as expected when PerSourceMaxStartups is set to 2, though like I mentioned before, this can possibly expose you to the denial-of-service condition.

[perkelix]

Vulnerability to low bit number doesn't disappear just because we're also testing for something else.

That point wasn't addressed in your reply.

You'll notice that the tests complete as expected when PerSourceMaxStartups is set to 2, though like I mentioned before, this can possibly expose you to the denial-of-service condition.

Which is why diffie-hellman-group-exchange-sha256 should result in a red flag and a recommendation to remove it from the configuration file, while the other diffie-hellman should result in a yellow flag.

[perkelix]

The logic for this is still broken. ssh-audit currently skips testing diffie-hellman-group-exchange-sha256's number of bits if any DHEat mitigation is in use.

[jtesta]

I can't reproduce that result. I scanned a clean Ubuntu 22.04 image with the ssh-audit v3.2.0 stable release. Then I applied the iptables & ip6tables commands I described in https://github.com/jtesta/ssh-audit/issues/263#issuecomment-2069810785 and scanned it again. The output in both is identical, except for the line that starts with (nfo) Potentially insufficient connection throttling detected [...].

[jtesta]

@perkelix : is this issue still valid? If so, I'm definitely confused. Thought I'd check before closing it.

[perkelix]

@jtesta I have removed diffie-hellman-group-exchange-sha256 from my configuration since it's an insecure kex that should no longer be recommended anyhow.

[jtesta]

Closing this, since I cannot reproduce the issue.