I'll have to ask this since it's bothering me for quite a while…
If I connect to a server via WireGuard, would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? It's kinda pointless to double encrypt.
If I connect to a server via WireGuard, would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? It's kinda pointless to double encrypt.
It's likewise a bit silly that we had to add TLS support to Tailscale: https://tailscale.com/blog/tls-certs/
But we want to interoperate well with the clients people already have (browsers, their system ssh client, etc...)
> However, if your service doesn’t have a valid TLS certificate, despite the fact that your connection is encrypted using Tailscale, your browser will warn you that the connection is not secure (it’s doing the right thing—it doesn’t know about Tailscale!). So, to avoid confusing your users, you might want to provision a TLS certificate to validate your internal services.
Browser warnings and user confusion aren’t the only consequence of not using HTTPS. The more concrete impact is that you lose access to a large and growing number of web APIs that are restricted to secure contexts.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
echo "alias telnet=nc -v" >> ~/.zshrc && source ~/.zshrcFor the rest: brew install telnet
sudo port install inetutilsThe problem is that rsh is very stale and unmaintained - even those versions that have had releases in recent years (e.g. GNU Inetutils) are very old inside - even if they've kept up with patches, they have not kept up with features e.g. modern user session construction.
It also turns out that ssh the client, much more so than ssh the protocol, is really a key integration point and API that users end up needing. It has a broad feature set that turns up in use cases all over, many of which rsh does not handle.
This is unsurprising, because it is used for different purposes in different layers of the stack. It is not at all a black and white state of "encrypted" vs. "not encrypted".
For example, in one organiztion I've worked with, Wireguard (generally, including Tailscale) is approved for restricting connections only to authorized network devices/users and that data maintains integrity in transit, but is not approved for protecting the confidentiality of sensitive information. Connections which access specific resources are required to be encrypted at the application level using a mechanism which has been approved for that information type (given a specific threat model).
So you could transmit very small amounts of data over TCP/IP, over a Tailscale network, using a set of pre-shared, one-time pads. And you might actually want to do this! It's really not ridiculous, but you do need to assess whether you really do have a threat model that needs it.
ssh used to allow setting cipher=none, but that's not available anymore.
Think of it this way: you're paying the small overhead of double encryption, but you're gaining not fatfingering your way to a password compromise.
Forgetting to firewall services or accidentally exposing services to the internet is pretty common. ssh is more hardened than rsh, especially with key based auth, so the risk is lower.
> would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`?
We all need to be shifting to ROT-52 ASAP.
Unless you’re transferring large files the overhead of double encryption on ssh is totally blown away by waiting for human input.
IIRC There’s a fork of SSH that supports not encrypting things if you are trying to transfer large files.
CPU overhead for encryption is basically non existend.
To be clear I implicitly and explicitly trust tailscale not to tamper with my networks and if your threat model includes tailscale becoming a bad actor you should remember that in that case running their binary in the first place could already be game over.
Also for Linux, the Tailscale client is fully open source and I obtain the binary from the distro. I find that a bit reassuring.
1) Run tailscale --ssh on your server 2) A malicious SSO or tailscale add a new machine to your network and update your ACL such that the new machine can connect to your server 3) ssh from the new machine to run code on your server
The fact that the connection between the malicious machine and your server is double encrypted doesn't affect the attack here at all
It’s more likely that you’re gonna screw up and end up doing something you don’t intend to do for very little gain. SSH overhead in 2022 is really low.