Just in time for the holidays, security researchers from Ruhr University Bochum have published details on Terrapin (CVE-2023-48795), a novel attack against the SSH protocol that affects virtually every SSH implementation in existence. When I first read the paper, my reaction was a mix of admiration for the research and that familiar sinking feeling you get when a protocol you’ve trusted implicitly for decades turns out to have a subtle flaw.
What Is Terrapin?#
Terrapin is a prefix truncation attack that targets the SSH handshake. By manipulating sequence numbers during the initial key exchange, an attacker performing a man-in-the-middle can effectively delete messages from the beginning of the encrypted channel without either side detecting the manipulation. The attack exploits the way SSH handles sequence numbers in combination with certain encryption modes.
The critical insight is that during the handshake, before the encrypted channel is fully established, there’s a window where an active attacker can inject and delete packets. By carefully truncating specific messages, the attacker can downgrade the security of the connection — for example, disabling keystroke timing obfuscation in OpenSSH or forcing a fallback to weaker authentication mechanisms.
To be clear: this isn’t a “decrypt all your SSH traffic” attack. It requires an active man-in-the-middle position, and its impact varies depending on the specific SSH implementation and configuration. But the fact that it works at the protocol level, not due to an implementation bug, means every SSH client and server is potentially affected.
The Technical Details#
The attack specifically targets encryption modes that use the encrypt-then-MAC approach or the ChaCha20-Poly1305 cipher. These are, ironically, some of the more modern and generally recommended cipher configurations. The older encrypt-and-MAC mode is also vulnerable, though through a slightly different mechanism.
What makes this particularly clever is the exploitation of SSH’s Binary Packet Protocol. SSH assigns sequence numbers to packets, but these sequence numbers aren’t cryptographically protected during the handshake transition. The attacker can inject a carefully crafted SSH_MSG_IGNORE message during the handshake, which increments the sequence number on the server side. When the encrypted channel begins, the client and server have different views of the sequence number state, allowing the attacker to delete a specific number of messages from the beginning of the encrypted stream.
The researchers found that roughly 77% of SSH servers on the internet support a vulnerable encryption mode, making this a widespread concern even if the practical exploitability has significant constraints.
Impact Assessment#
Let’s be practical about severity. The Terrapin attack requires:
- An active man-in-the-middle position on the network
- The connection must use a vulnerable cipher suite
- The actual impact depends on what those truncated initial messages contained
For most SSH usage — connecting to servers, running remote commands, transferring files — the practical impact is limited. The attacker can’t read or modify the content of your session. What they can do is strip certain security features that are negotiated at the start of the connection.
The most concrete impact is against OpenSSH’s [email protected] cipher and the keystroke timing countermeasures introduced in OpenSSH 9.5. An attacker could disable these countermeasures, potentially making keystroke timing analysis attacks viable again. For most server administration tasks, this is a modest risk. For high-security environments, it’s worth taking seriously.
What To Do About It#
OpenSSH 9.6, released alongside this disclosure, introduces a strict key exchange mode that prevents the attack. Both client and server need to support the new extension for it to be effective. The mitigation adds a [email protected] and [email protected] extension that resets sequence numbers after key exchange, closing the manipulation window.
For immediate practical steps:
- Update OpenSSH to 9.6 on both clients and servers
- If you can’t update immediately, consider disabling ChaCha20-Poly1305 and encrypt-then-MAC ciphers in your SSH configuration, falling back to AES-GCM which is not affected
- Audit your cipher configurations — this is a good time to review what your SSH config actually allows versus what you need
- Check the Terrapin vulnerability scanner released by the researchers
Other implementations are also releasing patches. PuTTY, libssh, Paramiko, and others have all been coordinated on this disclosure.
The Bigger Picture#
What fascinates me about Terrapin is what it reveals about the assumptions we make about mature protocols. SSH has been scrutinized by security researchers for over two decades. It’s one of the protocols we trust most implicitly — I use it dozens of times a day without thinking twice. And yet, a subtle interaction between sequence number handling and the handshake transition created a vulnerability that went unnoticed for years.
This pattern repeats throughout security history. TLS had BEAST, CRIME, POODLE, and Heartbleed. DNS had the Kaminsky attack. Now SSH has Terrapin. The lesson isn’t that these protocols are broken — it’s that cryptographic protocol security is extraordinarily difficult, and our tools for reasoning about protocol composition and state transitions still have gaps.
My Take#
As someone who’s been using SSH since its early days as a replacement for telnet and rsh, Terrapin is a humbling reminder. The practical risk for most of us is low — you need an active MITM, and the impact is limited to feature downgrade rather than content compromise. But “low practical risk” isn’t the same as “no action needed.”
Update your SSH implementations over the holiday break. Review your cipher configurations. And take a moment to appreciate the researchers who found this — responsible disclosure of protocol-level vulnerabilities is the kind of security work that makes the entire ecosystem stronger. ‘Tis the season for patching, apparently.