SSH shaken, not stirred by Terrapin vulnerability A vulnerability in the SSH protocol can be exploited by a well-placed adversary to weaken the security of people's connections, if conditions are right. In a successful man-in-the-middle attack, the adversary may be able to force SSH clients to use weaker authentication methods and disable some defense mechanisms. It is hard …
This post has been deleted by its author
I don't understand what that means?
How is a defined protocol not deterministic? What makes you think you can less vaguely define your 'API' better than someone else can define a 'Protocol'?
(I'll be honest, not really sure what you're saying).
What has asynchronicity and streaming got to do with it?
Actually, SSH does this, but only partially. To ensure the authenticity of the handshake, both peers compute a so-called exchange hash over all cryptographically relevant parameters. The server signs the exchange hash to prove his possession of the host key. However, one key observation that we made that eventually led to the attack is that the exchange hash is not a complete transcript hash but a selective hash. It does not include messages like the ignore message, which we used to offset sequence numbers during handshake.
According to the specification, IGNORE is intended to harden SSH against traffic analysis. Also, not counting IGNORE messages is no good solution either. Theoretically, a secure channel should guarantee the integrity, authenticity, and confidentiality of the messages passed through. Not counting IGNORE would allow attackers to mess with the secure channel badly, allowing arbitrary removal and addition of these messages. Also, there are more than ignore messages that can be used for our attack ;) Basically, any ignored message not causing a response is suitable - other options are SSH_MSG_DEBUG or SSH_MSG_UNIMPLEMENTED.
The KEX protocol will be on automatically, as I understand it, and thus thwart an MITM attacker when both client and server are using it. See the OpenSSH release notes linked to and also the PROTOCOL file.
I guess it will be up to the client and server to complain to the user that one end isn't using KEX when it's expected or desired.
C.
Why, oh why are the messages being sent not numbered? Even if there is not an upper bound on the total number of messages, a one-byte prefix would require that some multiple of 256 messages be dropped in order for this attack to be effective.
Alternatively, why, oh is the signature not over all of the effective message contents?
I've never looked at the ssh protocol, but this just doesn't add up.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
