[Bug 3603] New: ssh clients can't communicate with server with default cipher when fips is enabled at server end

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3603

            Bug ID: 3603
           Summary: ssh clients can't communicate with server with default
                    cipher when fips is enabled at server end
           Product: Portable OpenSSH
           Version: 9.4p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: sshedi at vmware.com

Hi,

This seems like a regression at first but there is a way to work around
it.

When fips is enabled at server end and server has the following cipher
set,

```
root at phdev:~ $ sshd -T | grep ciphers
ciphers
chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com

root at phdev:~ $ rpm -q openssh
openssh-9.1p1-10.ph5.x86_64 (this happens with 9.4p1 as well)
```

The handshake with client starts with chacha20-poly1305 and this cipher
is not fips complaint.

I'm not sure what the intention was but in this commit:
https://github.com/openssh/openssh-portable/commit/a22b9ef21285e81775732436f7c84a27bd3f71e0

chacha20 cipher was promoted.

At the client end, "ssh user at IP" doesn't work and aborts almost
immediately.

To workaround this issue, we need to do:

"ssh -c aes128-ctr user at IP"

In place of aes128-ctr, we can use any other algo which is fips
complaint (aes256-ctr, aes192-ctr etc).

Expected result:
ssh server should handle this gracefully.

Possible solutions:

1. Change the cipher order in KEX_SERVER_ENCRYPT (myproposal.h)

2. Use the same order but tweak the cipher list at run time based on
fips status in the system.

We did something like in PhotonOS 3.0:
https://github.com/vmware/photon/blob/3.0/SPECS/openssh/openssh-7.8p1-fips.patch

But we are unsure about the issue this might cause.

3. Server should send a proper error message to client in this case
showing some details on what went wrong; currently client simply aborts
with zero info.

4. If fips is enabled and sshd_config has ciphers which are
incompatible in fips mode, sshd should throw a warning and use the next
available fips complaint cipher from the list.

Even now, we can do the following in sshd_config,

cipherlist
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com

But we have to do it in all the server instances. I think this should
be handled by server considering fips scenario.

Please feel free to correct me if I'm wrong here.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.