5 ms·

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

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.

Helitico 4y ago
Stay secure by default. CPU overhead for encryption is basically non existend.
dsr_ 4y ago
Yes and no. You shouldn't have rsh on your system at all -- there's a case for telnet to test connections (though netcat is better), but there's no case for rsh. 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.
- throwaway894345 4y ago
  I'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?
  - xgbi 4y ago
    Somebody listening on local connections can sniff your password.
    - throwaway894345 4y ago
      How does that work? First of all, I would expect that rsh-over-tailscale doesn't use password authentication, and secondly can a local user sniff traffic before it hits tailscaled?
  - 8organicbits 4y ago
    I suspect they mean that if you have rsh installed for tailscale you need to be very careful with how you run it. If you accidentally let rsh listen on 0.0.0.0 and don't firewall it then you've given attackers a way to guess passwords. 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.
    - throwaway894345 4y ago
      Isn't this true of SSH as well? What's stopping someone from letting sshd listen on 0.0.0.0 with password auth? Anyway, I would expect that whether you're using ssh or rsh/telnet/etc that you're not configuring it for password auth, but rather using tailscale authentication. Specifically, I would expect (perhaps naively) that tailscaled handles the ssh/telnet/rsh/whatever connections rather than passing them off to another process (sshd, telnetd, etc) and thus allowing it to handle the authentication and daemon configuration (e.g., what address it listens on).
bradfitz 4y ago
Yeah, but e.g. no rsh (or telnet!) on macOS. It's likewise a bit silly that we had to add TLS support to Tailscale: https://tailscale.com/blog/tls-certs/ https://tailscale.com/blog/tls-certs/ But we want to interoperate well with the clients people already have (browsers, their system ssh client, etc...)
- throwaway894345 4y ago
  Is there an option to avoid double encryption on systems that do have e.g. rsh?
  - dangerlibrary 4y ago
    I might be misunderstanding the question but ... just use rsh?
    - throwaway894345 4y ago
      I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally we don't need to doubly-encrypt).
      - structural 4y ago
        Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones. 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.
runjake 4y ago
> would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? No, because ssh has evolved to be so much more than "rsh with encryption".
ben174 4y ago
Double encryption is twice as effective. I use double ROT-13 for double the security.
- efunneko 4y ago
  I find it more efficient to just use ROT-26
  - Shared404 4y ago
    ROT-26? Hasn't that been broken for a few years now? We all need to be shifting to ROT-52 ASAP.
- deleted 4y ago
  [deleted]
fragmede 4y ago
Is it pointless? SSH doesn’t send the password out over the wire but instead uses a challenge-response cryptographic system so even if one of the interim machines is compromised, they don’t have access to the clear text password. You shouldn’t be raising passwords (or even passwords in the first place with ssh) but practice defense in depth. 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.
Spooky23 4y ago
Not really. Who knows what you’re connecting to once you connect to the tailscale endpoint. 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.
soraminazuki 4y ago
In this case, double encryption is a good idea though. Tailscale is a great way to reduce exposure of your infrastructure from the public internet, but it’s not without flaws. In theory, it should be possible for Tailscale and your SSO provider to add new nodes to your Tailnet. Though I don’t believe this is something that they’re actually willing to do, it’s definitely something to keep in mind if you’re planning on delegating SSH/sudo authentication to Tailscale.
- jgeralnik 4y ago
  Double encryption doesn't actually help in that case though - if tailscale (maliciously) added nodes to your network the ssh session being encrypted wouldn't change the fact that they can run commands on your machines. And if they wanted to actively MITM you they could do so (by redirecting your wireguard connection to a server owned by them) even with encryption (presuming they can fake the host key, which they could do at worst by running code on your server to steal it). 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.
  - soraminazuki 4y ago
    Double encryption should help as long as the Tailscale client installed on your own machines is safe. Without double encryption for SSH, Tailscale and your SSO provider can theoretically run commands on your machines without involving malicious client software. But that's not possible if you encrypt your SSH connection with your own keys. Also for Linux, the Tailscale client is fully open source and I obtain the binary from the distro. I find that a bit reassuring.
    - jgeralnik 4y ago
      But that's the thing - even with double encryption tailscale and your SSO can run commands on your machines 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

Helitico 4y ago

Stay secure by default. CPU overhead for encryption is basically non existend.

dsr_ 4y ago

Yes and no. You shouldn't have rsh on your system at all -- there's a case for telnet to test connections (though netcat is better), but there's no case for rsh. 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.

throwaway894345 4y ago
I'm not following. How does double encryption help to avoid a password compromise if everything is authed with tailscale in the first place?
- xgbi 4y ago
  Somebody listening on local connections can sniff your password.
  - throwaway894345 4y ago
    How does that work? First of all, I would expect that rsh-over-tailscale doesn't use password authentication, and secondly can a local user sniff traffic before it hits tailscaled?
- 8organicbits 4y ago
  I suspect they mean that if you have rsh installed for tailscale you need to be very careful with how you run it. If you accidentally let rsh listen on 0.0.0.0 and don't firewall it then you've given attackers a way to guess passwords. 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.
  - throwaway894345 4y ago
    Isn't this true of SSH as well? What's stopping someone from letting sshd listen on 0.0.0.0 with password auth? Anyway, I would expect that whether you're using ssh or rsh/telnet/etc that you're not configuring it for password auth, but rather using tailscale authentication. Specifically, I would expect (perhaps naively) that tailscaled handles the ssh/telnet/rsh/whatever connections rather than passing them off to another process (sshd, telnetd, etc) and thus allowing it to handle the authentication and daemon configuration (e.g., what address it listens on).

bradfitz 4y ago

Yeah, but e.g. no rsh (or telnet!) on macOS. It's likewise a bit silly that we had to add TLS support to Tailscale: https://tailscale.com/blog/tls-certs/ https://tailscale.com/blog/tls-certs/ But we want to interoperate well with the clients people already have (browsers, their system ssh client, etc...)

throwaway894345 4y ago
Is there an option to avoid double encryption on systems that do have e.g. rsh?
- dangerlibrary 4y ago
  I might be misunderstanding the question but ... just use rsh?
  - throwaway894345 4y ago
    I think for the same reasons I wouldn't "just use ssh" over tailscale--I don't want to have to manage an sshd that doesn't require key or password auth but listens over tailscale (and nothing else!). Basically, what I want is for tailscaled to be my rshd (appropriately configured for connections over tailscale network only, etc) or in other words to avoid double-encryption (it's not the end of the world, but ideally we don't need to doubly-encrypt).
    - structural 4y ago
      Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones. 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.

runjake 4y ago

> would it make more sense to run simpler & unencrypted `rsh` instead of `ssh`? No, because ssh has evolved to be so much more than "rsh with encryption".

ben174 4y ago

Double encryption is twice as effective. I use double ROT-13 for double the security.

efunneko 4y ago
I find it more efficient to just use ROT-26
- Shared404 4y ago
  ROT-26? Hasn't that been broken for a few years now? We all need to be shifting to ROT-52 ASAP.
deleted 4y ago
[deleted]

fragmede 4y ago

Is it pointless? SSH doesn’t send the password out over the wire but instead uses a challenge-response cryptographic system so even if one of the interim machines is compromised, they don’t have access to the clear text password. You shouldn’t be raising passwords (or even passwords in the first place with ssh) but practice defense in depth. 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.

Spooky23 4y ago

Not really. Who knows what you’re connecting to once you connect to the tailscale endpoint. 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.

soraminazuki 4y ago

In this case, double encryption is a good idea though. Tailscale is a great way to reduce exposure of your infrastructure from the public internet, but it’s not without flaws. In theory, it should be possible for Tailscale and your SSO provider to add new nodes to your Tailnet. Though I don’t believe this is something that they’re actually willing to do, it’s definitely something to keep in mind if you’re planning on delegating SSH/sudo authentication to Tailscale.

jgeralnik 4y ago
Double encryption doesn't actually help in that case though - if tailscale (maliciously) added nodes to your network the ssh session being encrypted wouldn't change the fact that they can run commands on your machines. And if they wanted to actively MITM you they could do so (by redirecting your wireguard connection to a server owned by them) even with encryption (presuming they can fake the host key, which they could do at worst by running code on your server to steal it). 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.
- soraminazuki 4y ago
  Double encryption should help as long as the Tailscale client installed on your own machines is safe. Without double encryption for SSH, Tailscale and your SSO provider can theoretically run commands on your machines without involving malicious client software. But that's not possible if you encrypt your SSH connection with your own keys. Also for Linux, the Tailscale client is fully open source and I obtain the binary from the distro. I find that a bit reassuring.
  - jgeralnik 4y ago
    But that's the thing - even with double encryption tailscale and your SSO can run commands on your machines 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