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.
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).
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.
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).
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.
> 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.
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.
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.
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
"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).
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).
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).
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.
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.
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! :)
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.
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?
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.
48 comments
[ 0.28 ms ] story [ 123 ms ] threadBy the logic of a headline, a person cured of a disease is weaker afterward.
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.
I think the title is far less sensational than you give credit.
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.
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.
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.
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
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.
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.
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.
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/
Hoo boy.
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.
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.
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! :)
* 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.
> 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/
[0] https://infosec.mozilla.org/guidelines/openssh
> 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