Implement OpenSSH strict key exchange extension

[scott-xu]

The PR implements the algorithm described in section 1.10 of https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.

All integration tests passed, especially *-etm@openssh.com HMAC variants.

Resolves #1285

Terrapin Scanner report without this PR:

Terrapin_Scanner_Windows_amd64.exe --listen 2222
Listening for incoming client connection on 127.0.0.1:2222
================================================================================
==================================== Report ====================================
================================================================================

Remote Banner: SSH-2.0-Renci.SshNet.SshClient.0.0.1

ChaCha20-Poly1305 support:   false
CBC-EtM support:             true

Strict key exchange support: false

The scanned peer is VULNERABLE to Terrapin.

Note: This tool is provided as is, with no warranty whatsoever. It determines
      the vulnerability of a peer by checking the supported algorithms and
      support for strict key exchange. It may falsely claim a peer to be
      vulnerable if the vendor supports countermeasures other than strict key
      exchange.

For more details visit our website available at https://terrapin-attack.com

Terrapin Scanner report with this PR:

Terrapin_Scanner_Windows_amd64.exe --listen 2222
Listening for incoming client connection on 127.0.0.1:2222
================================================================================
==================================== Report ====================================
================================================================================

Remote Banner: SSH-2.0-Renci.SshNet.SshClient.0.0.1

ChaCha20-Poly1305 support:   false
CBC-EtM support:             true

Strict key exchange support: true

The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin. Glad to see this.
For strict key exchange to take effect, both peers must support it.

Note: This tool is provided as is, with no warranty whatsoever. It determines
      the vulnerability of a peer by checking the supported algorithms and
      support for strict key exchange. It may falsely claim a peer to be
      vulnerable if the vendor supports countermeasures other than strict key
      exchange.

For more details visit our website available at https://terrapin-attack.com

[Rob-Hague]

It looks good so far. I know that the integration tests are testing this in the positive case (i.e. they are using strict KEX), but it would make sense to add some tests in the negative cases assuming a bad actor, e.g.

• When we have strict KEX established, and we receive SSH_MSG_IGNORE (or other) during the key exchange. We should check that the connection fails.
• Conversely, when we don't have strict KEX established, we should not fail when receiving SSH_MSG_IGNORE (or other) during the key exchange
• When we have strict KEX established, and the peer does not reset the sequence number. We should check that the connection fails.
• Maybe some other cases?

test/Renci.SshNet.Tests/Classes/SessionTest_ConnectedBase.cs is probably a good starting point for simulating connections (either deriving from that or copying stuff out)

[Rob-Hague]

Thanks for all the tests. I will run this in production for a week or two

[Rob-Hague]

Thanks