4 ms·

> 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

> 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.

gh02t 3y ago
Same here, running Wireguard on the gateway (pfSense) really streamlined a lot of my needs on the go.
Suffocate5100 3y ago
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.
xoa 3y ago
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.
- jvanderbot 3y ago
  > 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.
- rsync 3y ago
  "'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 https://john.kozubik.com/pub/NetworkSlug/tip.html [2] https://john.kozubik.com/pub/NetworkSlug/body.html https://john.kozubik.com/pub/NetworkSlug/body.html
  - xoa 3y ago
    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.
hedora 3y ago
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.
- jvanderbot 3y ago
  > 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.

gh02t 3y ago

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

Suffocate5100 3y ago

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.

xoa 3y ago

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.

jvanderbot 3y ago
> 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.
rsync 3y ago
"'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 https://john.kozubik.com/pub/NetworkSlug/tip.html [2] https://john.kozubik.com/pub/NetworkSlug/body.html https://john.kozubik.com/pub/NetworkSlug/body.html
- xoa 3y ago
  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.

hedora 3y ago

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.

jvanderbot 3y ago
> 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.