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):
Steps to Reproduce:
1. Set machine to FIPS mode
2. ssh -vv -o "Ciphers 3des-cbc" -o "KexAlgorithms=diffie-hellman-group-exchange-sha1" localhost
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.
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.
(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
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.
I don't see it as "significant violation of FIPS mode" at all.
I raised the issue with upstream and they don't consider this to be an issue or willing to fix.
This probably should be closed as won't fix.