search

jtesta / ssh-audit

SSH server & client security auditing (banner, key exchange, encryption, mac, compression, compatibility, security, etc)
MIT License
3.36k stars 176 forks source link

diffie-hellman group exchange: 2048 bit modulus #206

Closed thecliguy closed 2 days ago

thecliguy commented 1 year ago

Starting in ssh-audit 3.0.0, if the diffie-hellman group exchange test of a standard audit detects a modulus size of 2048, then:

So, if your server is found to have a modulus size of 2048 present but it's running OpenSSH, then don't worry about it, that's fine. However, if your server is running anything other than OpenSSH, then you need to take action.

There may well be sound logic behind this decision but it's not obvious to me what it is...

Why does the presence of 2048 on OpenSSH represent less of a "risk" than any other SSH server software?

jtesta commented 10 months ago

My apologies for the late response.

Your summary is accurate. The reason I added this logic was because OpenSSH has a special fall-back mechanism for GEX negotiation. It is hard-coded to use group14 (see https://github.com/openssh/openssh-portable/blob/V_9_5/dh.c#L477) when no other option is available.

For example, say an admin hardens their server and removes (from /etc/ssh/moduli) all DH moduli less than 3072. When ssh-audit tests that server, the min/desired/max modulus size is set to 512/512/512, then 768/768/768, etc, until the server responds. This will trigger the fallback mechanism, and ssh-audit would normally report a warning that a 2048-bit modulus is in use--even though the admin did everything in their ability to prevent it (short of re-compiling from source without the fallback mechanism). This leads to confusion.

My rationale for ignoring the case of OpenSSH + 2048-bit moduli is that this fallback mechanism isn't triggered in most normal use scenarios; it is only triggered in test scenarios. I've observed modern clients to request 2048/(something)/4096, or 2048/(something)/8192. So to eliminate the confusion and provide results that are more accurate under real-world use, I included this exception. Sure, a really old client could request 1024/1024/2048 and actually get that group14 modulus in a real scenario, but... in 2023, I think this would be quite rare.

We could add a note that says 2048-bit moduli are possible but rare in the UI. What do you think?

thecliguy commented 9 months ago

@jtesta - Thanks for answering this. I do have a bit more to say on this subject but I'm a bit busy with some things IRL at the moment. I've set myself a reminder to come back to this and provide a proper response.

ecki commented 9 months ago

its strange that openssh makes it so hard to harden service.. i think its good to call them out on that.

jtesta commented 7 months ago

@thecliguy : Ping. We're about a month away from the next release, so I thought I'd see if you had any feedback on this issue. No rush, though.

ecki commented 7 months ago

Btw this also affects rhel crypto policy, if you use -gex14 it won’t remove it, only if you specify the full order of ciphers. That alone makes it a good idea that audit complains about it.

jtesta commented 2 days ago

I suppose I'll close this issue due to inactivity in the last 9 months. That said, we can certainly resume the conversation at any time in the Discussions section (https://github.com/jtesta/ssh-audit/discussions), if there's any interest. Thanks!

ecki commented 2 days ago

Started a thread here https://github.com/jtesta/ssh-audit/discussions/299