SSH protects the most sensitive networks. It just got a lot weaker | Hacker News Reader

SSH protects the most sensitive networks. It just got a lot weaker

arstechnica.com

115 pointsisaacfrond48 comments

That's quite the sensationalist title for something that was recently patched.

Agreed. Also, "just got a lot weaker" is misleading, as the vulnerability already existed, it was just discovered. "was weaker than we thought" is a bit less exciting, but more accurate.

The headline is the opposite of the truth: it is now stronger than ever.

By the logic of a headline, a person cured of a disease is weaker afterward.

going through a long sickness usually leaves one weaker afterward, even if one is cured, no? and in some cases there might be a slight upside in acquiring a certain degree of protection from future illnesses from that disease through various immunity mechanisms (which are of course far from perfect).

Okay, yes, that's one way the analogy breaks down.

It's more like you always had a disease and just didn't know it. Celiac comes to mind as a common example. I know people who improved a lot once they got diagnosed, and just never realized the symptoms meant anything before that.

yep, but that's not curable (yet!)

Also while the attack is novel it is hard to launch in practice (requires MITM) and even if you manage to pull that off, there isn't much to be gained (even with the downgrade for authenticated data to use SHA1 as it isn't practical to attack an interactive session).

Patched by how many of the 80% mentioned?

The patch was just released two days ago.

I wouldn't get too excited; it requires a MITM so abusing it at scale would be difficult.

Big targets should be wary, people's Hetzner servers and VMs are probably safe. They're not worth the effort to get a MITM on.

Interesting choice of example, two months ago an organization found their Hetzner server was MITMed https://news.ycombinator.com/item?id=37955264

There are hundreds of thousands of devices out there running older versions of SSH that can't or won't ever be patched. Sure, for folks running a modern full OS that can just patch at will, they're great.

I think the title is far less sensational than you give credit.

these devices should not be directly reachable ovee internet to begin with

But they are, which is why this is an issue. Posting on HN "don't do that" isn't going to change the reality we live in.

> For Terrapin to be viable, the connection it interferes with also must be secured by either "ChaCha20-Poly1305" or "CBC with Encrypt-then-MAC," both of which are cipher modes added to the SSH protocol (in 2013 and 2012, respectively). A scan performed by the researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.

At this point, I don't even open any ports except whatever required for wireguard, and all services connect on that interface. For the rare times that breaks, all cloud venders have a "virtual" terminal I use.

EDIT: services includes ssh. Not sure that was clear from context.

Same here, running Wireguard on the gateway (pfSense) really streamlined a lot of my needs on the go.

Exactly. I keep everything off the public internet unless it's a website meant to be accessed by millions of people. Nebula is all I use now.

Completely agreed, and that seems like best practice even at home let alone "the most sensitive networks" which should be running zero trust. Text traffic or even most web interfaces at this point are so lightweight and Noise-based VPNs so performant that even if theoretically there are inefficiencies in running it through other layers of tunnels in practice it's zero issue outside of extreme edge cases. Seems like everything non-public should just be tunneled by default at this point, even when the protocol itself is supposed to be secure. I can't see any downside to adding another layer to the onion in this case, and indeed there are some bonuses IME in terms of ease of routing/NAT hole punch etc to boot.

Of course on top is the whole galaxy of gear running never-updated stacks, from UPSs and PDUs to even core stuff like network switches which I've seen linger on completely obsolete cipher choices for ages. Or web GUIs doing the same with HTTPS (if they even support HTTPS(!)). Some stuff arguably should just be airgapped entirely, but if/when that's not possible stuff it behind a lot of layers of protection would be nice. I'd love to see an in-line form factor PoE ultra minimal dongle whose only job in life is to run Wireguard or Nebula or Tailscale or something, translating from that to an ethernet port that any ancient device can talk into and insuring 100% of traffic will go via that or not at all at the hardware level. Then could effectively mediate all traffic even to ancient stuff via that without it ever needing to even hit a switch.

> PoE ultra minimal dongle

I believe this is the future as envisioned by tailscale. Where some kind of key-exchange server is used alongside DNS, and DNS itself uses something like wireguard encryption.

"'d love to see an in-line form factor PoE ultra minimal dongle whose only job in life is to run Wireguard ..."

This is a type of "network slug"[1][2] and it is a very good idea.

An immutable, two-port (in and out) hardware "slug" that enforces your network policy no matter what form of misconfiguration lies behind it is a tool I hope more people will avail themselves of.

[1] https://john.kozubik.com/pub/NetworkSlug/tip.html

[2] https://john.kozubik.com/pub/NetworkSlug/body.html

That's definitely interesting too, but despite the increased risk of more power, what I'd like would be more complex then that. I want clients that were made long before the noise protocol framework even existed to still be able to get all traffic forced into a virtual network over it, which means effectively to dispense with layer 2 entirely as something for more then physical bit moving and move all traffic and traffic management/auth into L3 or higher. That's certainly becoming more cheaply possible on a technical level with modern SBCs, but I don't know of any really elegant turnkey product yet. Feels like one of those situations where you can see a lot of pieces of the puzzle scattered about but not quite pieced together.

Would you still call that a "network slug"? Might be a decent name regardless, but the description there sounds much, much simpler and more focused on layer 2.

The reference has been lost in the mists of time, but before snowden, and the NIST backdoors, there were accusations that a member of the SSL standardizations committee was an NSA plant that intentionally sabotaged the protocol.

Since their actions were done in public, researchers went back, and found that their main contribution to the spec was blocking anything that would simplify the implementation, and fast tracking as much needless complexity as possible.

From what I can tell, Wire Guard is based on that story, since it doesn't include any session-time negotiation of ciphers, etc.

tl;dr: Runtime negotiation of encryption algorithms considered harmful.

> From what I can tell, Wire Guard is based on that story, since it doesn't include any session-time negotiation of ciphers, etc.

Wireguard exchanges keys prior using well trusted implementations, and common "wireguard-implemented-tools" facilitate key generation and exchange on top of that. This is sane, and only vulnerable to supply-chain attacks in libsodium, or key leaks at either:

a) compromised host (so that host can decrypt incoming traffic) or

b) the key-exchange mechanism, for which open source implementations exist e.g., Nebula / Tailscale.

Regardless ...

Given that it is in addition to ssh (it's ssh over wireguard, not ssh or wireguard), I find any arguments against a wide class of encryption standards to be not very compelling.

With ssh + wireguard you need state-level hacks on libsodium and ssh vulnerabilities to have a general-purpose attack like you see with the Snowden stuff

However, this is important context.

"Terrapin can also override an older extension parameter specifying the use of the SHA2 cryptographic hash function. As a result, SSH will instead use the weaker SHA1."

I'm curious if Tinyssh is immune to this attack, since it doesn't implement sha1 (especially as I'm using it in several places).

"State-of-the-art crypto: ssh-ed25519, curve25519-sha256, chacha20-poly1305@openssh.com"

https://tinyssh.org/

if you think you're exposed to MITM, then disabling the chacha cipher probably makes sense. there are others that are widely implemented (depends on your clients, really).

Tinyssh doesn't implement any other cipher.

Dupe of https://news.ycombinator.com/item?id=38684904

its not the same link, how is it a dupe

This article is reporting on the attack that GP's link is the authoritative source for.

Even the security researcher that reported this doesn't think so.

> I am an admin, should I drop everything and fix this?

> Probably not.

> The attack requires an active Man-in-the-Middle attacker that can intercept...

[1] https://terrapin-attack.com/

For anyone who wants to disable the vulnerable primitives, I just made a bash function:

  #!/bin/bash

  # Function to apply Terrapin Mitigation to SSH configurations
  terrapin_mitigation() {
    echo "Applying Terrapin mitigation to SSH client and daemon config..."

    # Function to filter algorithms, reading from stdin
    filter_algorithms() {
      while read -r alg; do
        if [[ "$alg" != *"chacha20-poly1305@openssh.com"* ]] && [[ "$alg" != *"-cbc"* ]] && [[ "$alg" != *"-etm@openssh.com"* ]]; then
          echo "$alg"
        else
          echo "Removing vulnerable $alg" >&2
        fi
      done
    }

    # Ensure .d directories exist
    sudo mkdir -p /etc/ssh/sshd_config.d
    sudo mkdir -p /etc/ssh/ssh_config.d

    # Get and filter algorithms
    kex_algorithms=$(ssh -Q kex | filter_algorithms)
    ciphers=$(ssh -Q cipher | filter_algorithms)
    macs=$(ssh -Q mac | filter_algorithms)

    # Create configuration lines
    kex_line="KexAlgorithms $(echo "$kex_algorithms" | tr '\n' ',')"
    cipher_line="Ciphers $(echo "$ciphers" | tr '\n' ',')"
    mac_line="MACs $(echo "$macs" | tr '\n' ',')"

    # Remove trailing commas
    kex_line=${kex_line%,}
    cipher_line=${cipher_line%,}
    mac_line=${mac_line%,}

    # Output to sshd.d and ssh.d files
    echo ""
    echo "*** /etc/ssh/sshd_config.d/terrapin-mitigation: ***"
    { echo "$kex_line"; echo "$cipher_line"; echo "$mac_line"; } | sudo tee /etc/ssh/sshd_config.d/terrapin-mitigation
    echo ""
    echo "*** /etc/ssh/ssh_config.d/terrapin-mitigation: ***"
    { echo "$kex_line"; echo "$cipher_line"; echo "$mac_line"; } | sudo tee /etc/ssh/ssh_config.d/terrapin-mitigation
    echo ""

    echo "Terrapin mitigation configuration updated!"
  }

  terrapin_mitigation

Because of the way SSH resolves its config (first of CLI, user local, system wide), in some cases you may prefer to alias ssh to configure this at the command line.

Also disabling some algorithms might bar you from connections that are limited to those. I'm not an expert, this is just what I threw together now. You're welcome to use it unless you know a better way. Please suggest improvements if you see them and use at your own discretion otherwise! :)

    # Ensure .d directories exist
    sudo mkdir -p /etc/ssh/sshd_config.d
    sudo mkdir -p /etc/ssh/ssh_config.d

Note that this was added in OpenSSH 8.2, released 2020-02-14:

* https://bugzilla.mindrot.org/show_bug.cgi?id=2468

* https://www.openssh.com/txt/release-8.2

If you have an older version this will not work.

Cool. Might be good to add a workaround in that case, maybe appending to the actual user local client config, and global daemon config with grep for a comment block to check if it's already been added.

Note that if you're using Red Hat, you probably should not do this; you should instead make the temporary change through the crypto-policies tool (see https://access.redhat.com/security/cve/cve-2023-48795 ).

These files had to be named terrapin-mitigation.conf to work for me.

Thanks! Yeah, I think that's right.

"adversary-in-the middle, also known as man-in-the-middle"

Hoo boy.

right, so if you already have a huge security problem, there are a narrow set of cases where this might allow fairly minor weakening of your ssh sessions (if you don't perform the straightforward mitigation).

> if you already have a huge security problem,

Maybe? If you include "use a third-party hoster" into the idea of "have a huge security problem".

From a different comment (https://news.ycombinator.com/item?id=38710214) , two months ago an organization found their Hetzner server was MITMed https://news.ycombinator.com/item?id=37955264 . The source article says "We believe this is lawful interception Hetzner and Linode were forced to setup."

tl;dr: People's assumptions about SSH enabling a secure tunnel are not necessarily valid.

Newspeak 101: it’s sexist to assume that a malicious actor is male. Women can be malicious too! Other acceptable terms are: Woman-in-the-Middle and Man-or-Woman-or-Non-binary-In-the-Middle. Add that to your allow list.

Yeah that's what I was hoo-boying about. The subtle shift in term.

Alice, Bob, Eve, Mallory, Trent, and so on. https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...

not a lot.

first need MITM, and that's not trivial. next need to be running to asyncssh (which has a straight-up bug in its state machine). next need to be running specific ciphers which use the ssh packet sequence number in their IV.

it is a moderate big deal because it's a protocol flaw, not just a bug. so the openssh "patch" actually introduces a new protocol option, which doesn't help unless both sides select it.

I wonder what impact this will have on Mozilla's OpenSSH configuration guide[0], which currently specifies `chacha20-poly1305@openssh.com` as its primary cipher. Should that be dropped to rely solely on AES ciphers?

[0] https://infosec.mozilla.org/guidelines/openssh

Good old RSA once again proves it can be trusted, whereas these newer crypto systems made in the last decade disappoint over and over again. Yet people keep using them because they're told they are fashionable, without really knowing the full implications.

As far as I can tell, this has nothing to do with the public key cryptography used in the protocol.

From the original paper:

> ChaCha20-Poly1305 [30] directly uses the sequence number in its key derivation, which makes it vulnerable to our prefix truncation attack...

> Note that the fault is not with ChaCha20-Poly1305 as an AEAD encryption scheme, but with its integration into the SSH secure channel construction.

See here: https://terrapin-attack.com/TerrapinAttack.pdf

Reply on news.ycombinator.com