Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When connecting to embedded SSH server the connection is dropped by other side.
It happens when the other side supports only Diffie Hellman key exchange but can't handle all DH key sizes (over 4096 bit in particular).
Version-Release number of selected component (if applicable):
openssh-6.4p1-7.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Set machine to FIPS mode
2. ssh -vv -o "Ciphers 3des-cbc" -o "KexAlgorithms=diffie-hellman-group-exchange-sha1" localhost
Actual results:
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192)
Expected results:
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<2048<8192)
Additional info:
According to NIST SP 800-57, 3DES should be used with 2048 bit DH. Strict FIPS guideline is to never use DH keys over 3072 bit.
Marking as regression since OpenSSH in RHEL 6 does not negotiate DH over 4096 bit in any configuration.
This report only describes the 3rd party software bug. According to RFC:
The server should return the smallest group it knows that is larger
than the size the client requested. If the server does not know a
group that is larger than the client request, then it SHOULD return
the largest group it knows.
Described server drops the connection instead of providing the largest group it knows.
SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) says, that the client prefers 7680bits group but it will accept a group of size 2048 bits at minimal. So there's no conflict with any specification given that it's the server who choose the group.
This should be really fixed on the other side.
I'm not saying that the other side is RFC compliant. Far from it. Not only it does not support grooup14 DH exchange (which is secure and acceptable in FIPS mode) but also, as you pointed out, doesn't select the highest DH group size it supports.
That being said, our side may propose parameters that meet NIST recommendations, FIPS limits and limitations of the other side *without* compromising security when connecting to other, RFC compliant, servers.
(In reply to Tomas Mraz from comment #5)
> I'm sorry, but I do not see as blocker at all. Also the FIPS mode
> limitations are not something that we would expect "broken" client to work
> with.
I'd argue that openssh by suggesting 7k DH breaks FIPS mode. The problem is that normally openssh negotiated md5 based hmac, so it uses DH sizes for 128 bit ciphers. In FIPS mode the smallest HMAC it can use is SHA-1. Because of that, it uses the DH group sizes for 160 bit ciphers (7k or 8k bit).
But if you don't consider it significant violation of FIPS mode, we can leave it as is for now.