Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

diffie-hellman group exchange: 2048 bit modulus #206

Open
thecliguy opened this issue Sep 12, 2023 · 5 comments
Open

diffie-hellman group exchange: 2048 bit modulus #206

thecliguy opened this issue Sep 12, 2023 · 5 comments

Comments

@thecliguy
Copy link
Contributor

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:

  • If this was deemed to be caused by OpenSSH's GEX fallback mechanism, then no warning is issued.
  • Else, a warning is issued.

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
Copy link
Owner

jtesta commented Nov 24, 2023

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
Copy link
Contributor Author

@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
Copy link

ecki commented Dec 23, 2023

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

@jtesta
Copy link
Owner

jtesta commented Feb 17, 2024

@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
Copy link

ecki commented Feb 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants