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@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@openssh.com is not
found, it may not send chacha20-poly1305@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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@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@openssh.com is not
found, it may not send chacha20-poly1305@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev