<story><title>Terrapin Attack for prefix truncation in SSH</title><url>https://terrapin-attack.com</url></story><parent_chain></parent_chain><comment><author>tptacek</author><text>This is wonderful.&lt;p&gt;Secure transport protocols all do some kind of handshake to set up a session, agree on keys, etc. Modern secure transport protocols (everything since SSL2) authenticate the handshake, so a MITM can&amp;#x27;t just edit the messages and, like, stick both sides on the NULL cipher (don&amp;#x27;t have a NULL cipher, though).&lt;p&gt;Ever since Kocher and SSL 3.0, the gold standard for handshake authentication has been to keep a transcript of all the handshake messages, and just hash them to fingerprint the entire handshake. You can look at Noise for a streamlined, slick version of the same concept.&lt;p&gt;SSH does something else: it looks at the handshake as a vehicle for setting up a DH-style key exchange; that&amp;#x27;s all it&amp;#x27;s for, everything else happens inside the secure transport that key exchange provides. So instead of doing a transcript hash, SSH picks out the handshake values that will end up being inputs to the key exchange, and hashes those.&lt;p&gt;The problem is: SSH also does implicit sequence numbers; receivers keep track of how many messages they&amp;#x27;ve received, senders keep track of how many they&amp;#x27;ve sent. Not only that, but SSH has (for reasons passing understanding) a NOP message (`IGNORE`). `IGNORE` carries no data used to do key generation, so it has no impact on the handshake authentication --- but it does impact sequence numbers.&lt;p&gt;Result: MITM attackers can set sequence numbers to arbitrary values (by injecting `IGNORE`s in the handshake), and then &lt;i&gt;edit out&lt;/i&gt; subsequent messages (by just not sending them). If you&amp;#x27;re using ChaPoly (and often if you&amp;#x27;re using CBC), the protocol will sync up and keep going. You can use this to, for instance, snipe out extension messages (for things like keystroke timing mitigation) from the beginning of an SSH session.&lt;p&gt;This is a pretty obvious problem! It&amp;#x27;s absolutely not something you can just accept from a secure transport protocol. And you could look at SSH and SSL3 and see &amp;quot;SSH is doing something really different and less sophisticated than SSL3&amp;quot;. But it took until 2023 for someone to do the legwork to figure out how broken it was.</text></comment>
<story><title>Terrapin Attack for prefix truncation in SSH</title><url>https://terrapin-attack.com</url></story><parent_chain></parent_chain><comment><author>colmmacc</author><text>This paper is the best protocol security research I&amp;#x27;ve seen in a while. Thankfully the consequences aren&amp;#x27;t too big - everyone should update ssh (which will be a pain!) - but it likely doesn&amp;#x27;t need to happen at breakneck pace. This issue isn&amp;#x27;t quite as serious as prior issues that impacted TLS&amp;#x2F;SSL.&lt;p&gt;Two things stand out to me;&lt;p&gt;1. That the SSH protocol lacked a robust transcript hash all along, this seems like a staggering decision, and even though I&amp;#x27;d read the RFCs, I&amp;#x27;d never put this together. Turns out it&amp;#x27;s to allow for injection of messages designed to defeat traffic analysis? Not the right way to do it.&lt;p&gt;2. The SSH handshake had been formally verified ... and the proofs are still &amp;quot;true&amp;quot;. But the researchers found non-obvious gaps between the environmental assumptions for the proofs and what is actually true in the real world. Formal verification is still the most comprehensive and exhaustive form of testing that we have, but gaps can really bite you. It is like relying Pythagoras&amp;#x27; theorem for a triangle, but then it turns out that your triangles are on the surface of a sphere, which isn&amp;#x27;t a plane. The math itself is right, but the environment
was different all along.</text></comment>