mkj
release request (terrapin)
Please make a release that includes the fix for the terrapin vulnerability, for easier packaging. Thank you!
Not sure if I'll get the release made in the next week, otherwise it'll be after mid-January.
Note that Terrapin doesn't reduce the security of Dropbear at all, it doesn't implement [email protected] extension.
server-sig-algs is mentioned by the Terrapin authors as security-related, but I think that's incorrect - it's used for compatibility, not security.
For reference, this commit can be cherrypicked if desired
https://github.com/mkj/dropbear/commit/6e43be5c7b99dbee49dc72b6f989f29fdd7e9356 Implement Strict KEX mode
With description in https://github.com/mkj/dropbear/commit/66bc1fcdee594c6cb1139df0ef8a6c9c5fc3fde3 https://github.com/mkj/dropbear/blob/66bc1fcdee594c6cb1139df0ef8a6c9c5fc3fde3/CHANGES#L12-L23
server-sig-algs is mentioned by the Terrapin authors as security-related, but I think that's incorrect - it's used for compatibility, not security.
The reason why we considered server-sig-algs to be security-related is given in RFC8332 Section 3.3:
When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an "ssh-rsa" signature to avoid authentication penalties. When the new rsa-sha2-* algorithms have been sufficiently widely adopted to warrant disabling "ssh-rsa", clients MAY default to one of the new algorithms.
While it is true that not sending server-sig-algs does not prevent the client from trying SHA2-based RSA signatures, we observed the suggested behavior (preferring SHA-1 over SHA-2 when server-sig-algs is missing) in a wide variety of SSH clients. Also, the order of algorithms in server-sig-algs is used by some clients in case multiple private keys are present, potentially leading to downgrades as well.
However, we do not consider this application of the Terrapin attack to have a significant impact. Instead, our main concern is the combination of Terrapin with implementation bugs, as seen in AsyncSSH. We evaluated only a handful of SSH implementations, where one already allowed for in-session man-in-the-middle attacks. Given the wide variety of SSH implementations, one can estimate with sufficient probability that other implementations face similar issues.
