Terrapin Mitigation: "strict-kex"
ecki opened this issue · comments
Description
Hello,
is Mina or any contributor planning to work on adding the new OpenSSH protocol extension "strict-KEX" for mitigating Terrapin attacks?
Also did somebody check for the counter overflow conditions mentioned in the advanced counter manupulation section of the paper?
BTW: when implementing config options, I would do it like jssh which allows to define a "required" mode, so you can set up a listener which rejects any handshakes without this protection. (if you want to make "supported" configurable I dont care, seems to be not a big compat problem if implemented correctly)
In addition to resetting the counters the strict mode probbaly also should reject the "filler" debug and ignore mesages - I hope PMC received detailed guidance from the Terrapin team?
Motivation
Users want to mitigate the new protocol attac which can only work if client and server are extended.
Alternatives considered
Turning off the ciphers is an interop problem.
Additional context
According to OpenSSH PROTOCOL - section 1.9 transport: strict key exchange extension
Ater sending or receiving a SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero
However, it does not specify which sequence number to reset - the incoming our outgoing. Bear in mind that the NEWKEYS message is "symmetrical" - if we sent one, then an incoming one is due any time and vice versa. Since the sequence number is part of the encryption (if this is not the 1st NEWKEYS) then we need to know whether we sent the request or are responding to it.
Working on it (trying to at least...)
According to OpenSSH PROTOCOL - section
1.9 transport: strict key exchange extensionAter sending or receiving a SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero
However, it does not specify which sequence number to reset - the incoming our outgoing. Bear in mind that the NEWKEYS message is "symmetrical" - if we sent one, then an incoming one is due any time and vice versa. Since the sequence number is part of the encryption (if this is not the 1st NEWKEYS) then we need to know whether we sent the request or are responding to it.
Strict key exchange resets the sequence number of the corresponding direction after it has received a SSH_MSG_NEWKEYS message. I. e. when receiving SSH_MSG_NEWKEYS from the remote peer reset the incoming sequence number, when sending SSH_MSG_NEWKEYS reset the outgoing sequence number. The SSH_MSG_NEWKEYS itself is handled under the old sequence numbers (sequence number 0 will be the first message after SSH_MSG_NEWKEYS).
I pretty much figured this out on my own - the comment was just a reminder for myself to figure the correct implementation. Thanks for your answer - it puts me more at ease to know that others have reached the same conclusion I did.
Yeah, I expected that kind of response, given that I replied 6 hours later. If any additional questions pop up during the implementation of "strict kex", just let me know. I'm most likely going to be able to answer them.
Lyle, let me know when you think I can have a look. We are using it heavily inside karaf, so we are happy to help.
Thx - will do
See #446 - still working on it (polishing it) but it seems promising
Is this to solve the CVE-2023-48795 vulnerability? When will the new patch version be released?
Is this to solve the CVE-2023-48795 vulnerability?
Yes.
When will the new patch version be released?
When it's ready.
Is this problem/fix on server side ? we are using only sshd clinet , do we need to do something to mitigate the problem ?
The fix (strict kex protocol extension) is required on both sides to be active, see the terrapin website for more details on mitigations. If you remove the affected ciphers this would be effective no matter on which side you do it.
Hello, I want to ask - is there any plan to backport the fix into the 2.9 branch?