Server-side algorithms selection

Nicola Murino nicola.murino at gmail.com
Tue Feb 6 03:38:58 AEDT 2024


Hi,

according to RFC 4253

https://www.rfc-editor.org/rfc/rfc4253#section-7.1

for the selection of algorithms (ciphers, KEX, MAC etc.), the leftmost 
matching client algorithm is picked.

While this is fine in most cases, there are cases where it is not 
desirable, for example:

1) for compatibility with a single old client you enable an old cipher, 
say aes128-cbc, server side. A modern client due to misconfiguration or 
any other reason sets aes128-cbc as preferred even if it supports more 
modern alternatives, then aes128-cbc is used, for example:

ssh -c aes128-cbc,chacha20-poly1305 at openssh.com ...

2) if the server (but also the client) could inspect the algorithms 
before sending SSH_MSG_KEXINIT interesting things could be done, for 
example the server checks KEX and kex-strict-c-v00 at openssh.com is not 
found, it may not send chacha20-poly1305 at openssh.com

One common solution used in some servers is to associate algorithms to 
client's initial banner (see for example SFTPClientMatch in ProFTPD).
This means that over time we will have ever-increasing association 
lists, also the initial banner can be easily changed if you use one of 
the many SSH libraries available, so this does not seem like such a 
robust and easy to maintain solution.

Another option I have evaluated is to send SSH_MSG_KEXINIT from the 
server after receiving SSH_MSG_KEXINIT from the client. I tested this 
solution by modifying Golang x/crypto/ssh and although it works with all 
tested clients it seems rather fragile, if a client has the same idea 
the connection will hang.

Another way would be to immediately send a Key Re-Exchange

https://www.rfc-editor.org/rfc/rfc4253#section-9

after the initial SSH_MSG_KEXINIT if it is possible to select some 
better algorithms, for example, in the Key Re-Exchange, the server can 
advertise only the first algorithm, in its order of preference, 
supported by the client. This means having some potentially weak 
algorithms until the Key Re-Exchange.

Is there something obvious I'm missing? Do you have any other suggestions?

Thanks in advance.

Best Regards,

Nicola


More information about the openssh-unix-dev mailing list