Support strict KEX negotiation

[vcsjones]

CVE-2023-6918 identified a minor flaw in the SSH protocol that resulted in a new client and server extension for strict KEX negotiation (Terrapin attack).

This issue is to propose that this library should support it, and advertise the [email protected] extension. The extension is supported by most servers now, both openssh and libssh support it, so it has broad applicability.

I am willing to do the work to implement it, but wanted to raise an issue to see if the work would be accepted. In general, it would amount to

1. Advertise the client extension.
2. If there server also advertises the [email protected] extension, enable it for the client.
3. The extension changes a couple of behaviors
   1. The packet sequence is reset after new keys are received.
   2. Prohibits some packet types during negotiation.

In theory, since both the client and the server need to support it and advertise it with extensions, it should not break anyone to enable it. However, I suspect someone will want a flag to disable it, so it should be configurable, but defaulted to enabled.

[tmds]

@vcsjones thanks for raising the issue!

The packet sequence is reset after new keys are received.
Prohibits some packet types during negotiation.

I think either of these are sufficient to protect against Terrapin. So far, the library has been too strict about packets during negotiation. I've relaxed this in #216, but not during the initial exchange. So, I don't think the library is vulnerable.

That said. Better be safe than sorry.

I am willing to do the work to implement it, but wanted to raise an issue to see if the work would be accepted.

Definitely!

Here are some pointers that may help:

• CreateKeyExchangeInitMessage is probably a good place to include the client extension.
• SshConnectionInfo can be used to track if the session does strict kex (across negotiations)
• SetEncryptorDecryptor is probably where the sequence counters should reset (when strict kex)

If you want to try and see how your changes work, you can run the examples/ssh application and set the LOG/TRACE envvar to see what happens.

For testing: a simple test could be to check the boolean that tracks the strict kex on SshConnectionInfo.

I suspect someone will want a flag to disable it, so it should be configurable

I prefer to wait for someone to explicitly ask to make it configurable. For now, I think we can just always send the advertisement, and use strict kex when the server announces it too.

[tmds]

@vcsjones I'm working on a release towards the end of next week. If you have some time, it would be nice if we could include this. If you won't have time to work on this in the next month or so, please let me know.

[vcsjones]

@tmds I should be able to wrap this up over the next few days.