Terrapin is a prefix truncation attack. That phrase does most of the work: an attacker who controls the network path can chop a controlled number of messages off the front of the encrypted stream so that both sides end up in a slightly different state than they agreed to. The research came from Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk at Ruhr University Bochum, and it is notable because SSH had spent two decades being treated as effectively unbreakable at the transport layer.
The attack does not recover your password or read your files. What it does is subtler, and understanding it is a good lesson in how real cryptographic protocols fail. They rarely fail because the cipher is broken. They fail at the seams between the parts.
How SSH keeps a session honest
When an SSH client and server connect, they run a handshake. They exchange version strings, negotiate which algorithms they will use, perform a key exchange, and then switch on encryption for everything that follows. To make sure nobody has tampered with any of the messages in transit, SSH uses a running sequence number. Every binary packet gets an implicit counter, starting from zero, and that counter feeds into the message authentication code that protects each packet.
The sequence number is the quiet guarantee that message number five really is the fifth message, in order, with nothing added and nothing removed. If an attacker drops a packet, the counters on the two sides drift apart, the authentication tags stop matching, and the connection tears down. That is the design working as intended.
SSH authenticates the order and count of messages using a shared sequence number. Terrapin's trick is to make the client and server disagree about that count before authentication starts protecting the stream, so the mismatch is invisible.
The gap Terrapin exploits
Here is the problem. During the handshake, before the secure channel is fully established, SSH allows certain unencrypted messages. One of them is SSH_MSG_IGNORE, a no-op message that exists so implementations can pad traffic or keep connections alive. There is also an optional SSH_MSG_EXT_INFO message that lets the two sides advertise protocol extensions right at the start of the encrypted phase.
The sequence counter starts ticking during the unencrypted portion of the handshake. That means an attacker can inject an extra ignorable message during the handshake, which bumps the counter on one side, and then later delete a real message to bring the counter back into apparent agreement. The two sides never notice, because the injection happened while the messages were not yet authenticated. By the time the authenticated encryption is running, both sides believe their counters are aligned, but the actual conversation has had a message silently removed from the front.
The most useful thing to delete is SSH_MSG_EXT_INFO. Removing it strips the extension negotiation, which can downgrade security features the client and server would otherwise have turned on. In particular, some servers use extension negotiation to enable stronger, more modern message authentication or to signal support for defenses against keystroke timing analysis. Delete the announcement and you delete the upgrade.
Which algorithms were affected
Terrapin is not a flaw in every SSH configuration. It depends on specific encryption modes that let the truncation go undetected. Two categories were vulnerable:
| Cipher / mode | Terrapin exposure |
|---|---|
| ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) | Vulnerable: the sequence number is used in a way that lets the truncation stay hidden |
| CBC with Encrypt-then-MAC (*-etm@openssh.com) | Vulnerable: the EtM construction combined with CBC allowed the same manipulation |
| AES-GCM | Not affected by the prefix truncation in the same way |
| CTR with Encrypt-and-MAC (older non-EtM modes) | Not the target: different construction, though these have their own reasons to avoid |
The awkward part is that ChaCha20-Poly1305 was, and remains, an excellent cipher. There is nothing wrong with the algorithm itself. The vulnerability lived in how SSH wired the sequence number into that particular packet construction. This is the recurring theme of authenticated encryption going wrong: the primitive is sound, the integration leaks.
The fix: strict key exchange
The repair was elegant and quick. It is called strict key exchange, or "strict kex," and OpenSSH shipped it in version 9.6 alongside the disclosure. The idea is simple. During the handshake, no unnecessary messages are tolerated. If a client or server receives an unexpected message like SSH_MSG_IGNORE before the key exchange completes, it aborts the connection instead of accepting it.
Strict kex also resets the sequence number to zero when encryption is switched on. That removes the attacker's ability to smuggle counter drift across the boundary between the unencrypted and encrypted phases. Both sides now start counting from the same clean baseline once the secure channel exists. The catch is that strict kex only protects a connection if both endpoints support it, since it is negotiated. An updated client talking to an old server gets no benefit.
Terrapin required an attacker positioned to intercept and modify traffic between client and server. That is a meaningful bar. But "on the network path" describes every public Wi-Fi router, every compromised ISP node, and every state actor with access to a backbone. It is not an exotic position. On the practical threat model
What Terrapin does and does not mean for you
It is worth being precise about severity, because Terrapin was reported with a range of headlines that oversold it. The attack does not let someone read your SSH session or steal your keys directly. Its real effect is downgrade: stripping the security extensions two modern endpoints would have negotiated, which in some configurations weakened defenses and, when chained with certain implementation bugs in specific SSH libraries, could enable more serious follow-on attacks.
For most administrators the response was undramatic and correct: update OpenSSH on both ends, confirm strict kex is negotiated, and if you cannot update immediately, temporarily prefer AES-GCM and disable the vulnerable ChaCha20-Poly1305 and CBC-EtM modes. The researchers published a scanner so operators could test their own servers.
Confirm both client and server are on OpenSSH 9.6 or later, or the patched build from your distribution. Strict key exchange only defends a session when both ends support it. Auditing your negotiated algorithms with a tool like ssh -vv or a Terrapin scanner tells you where you actually stand, rather than where you assume you stand.
The larger lesson for protocol design
Terrapin is a clean example of a class of failure that keeps appearing in secure protocols: the transcript is not fully authenticated. A handshake is only trustworthy if both parties can prove, after the fact, that they saw exactly the same sequence of messages, in the same order, with nothing added or removed. SSH authenticated most of that, but left a small unauthenticated window at the boundary, and that window was enough.
Newer protocols design against this from the start. TLS 1.3 binds the entire handshake into a transcript hash that both sides confirm before any application data flows, which is one reason TLS 1.3 closed off a whole family of downgrade attacks that plagued earlier versions. The Noise protocol framework takes the same discipline further, treating the running transcript as a first-class object that every step mixes into the keys. The lesson SSH learned the hard way is one these designs assume: authenticate the whole conversation, including its shape, not just its contents.
For anyone building or evaluating encrypted communication, Terrapin is a reminder that "it uses strong encryption" is the beginning of the security question, not the end. The interesting failures happen in the negotiation, the ordering, the state machine, and the seams. That is exactly where careful protocols like MLS spend most of their engineering budget, because a strong cipher wrapped in a sloppy handshake is only as good as the handshake.