5 ms·

Ah… I really could not disagree more with that statement. I know we don’t want to trust BigCorp and whatnot, but a single exposed port and an incomplete underst

Ah… I really could not disagree more with that statement. I know we don’t want to trust BigCorp and whatnot, but a single exposed port and an incomplete understanding of what you’re doing is really all it takes to be compromised.

SchemaLoad 9mo ago
Even if you understand what you are doing, you are still exposed to every single security bug in all of the services you host. Most of these self hosted tools have not been through 1% of the security testing big tech services have.
- johnisgood 9mo ago
  Now you are exposed to every security bug in Tailscale's client, DERP relays, and coordination plane, plus you have added a trust dependency on infrastructure you do not control. The attack surface did not shrink, it shifted.
  - SchemaLoad 9mo ago
    I run the tailscale client in it's own LXC on Proxmox. Which connects to nginx proxy manager also in it's own LXC, which then connects to Nextcloud configured with all the normal features (Passkeys, HTTPS, etc). The Nextcloud VM uses full disk encryption as well. Any one of those components might be exploitable, but to get my data you'd have to exploit all of them.
    - johnisgood 9mo ago
      You do not need to exploit each layer because you traverse them. Tailnet access (compromised device, account, Tailscale itself) gets you to nginx. Then you only need to exploit Nextcloud. LXC isolation protects Proxmox from container escapes, not services from each other over the network. Full disk encryption protects against physical theft, not network attacks while running. And if Nextcloud has passkeys, HTTPS, and proper auth, what is Tailscale adding exactly? What is the point of this setup over the alternative? What threat does this stop that "hardened Nextcloud, exposed directly" does not? It is complexity theater. Looks like defense in depth, but the "layers" are network hops, not security boundaries.
      - butvacuum 9mo ago
        And, Proxmox makes it worse in this case as most people won't know or understand that proxmox's netoworking is fundamentally wrong: its configured with consistent interface naming set the wrong way.
- bjt12345 9mo ago
  How would another service be impacted by an open UDP port on a server that the service is not using?
- IgorPartola 9mo ago
  For every remote exploit and cloud-wide outage that has happened over the past 20 years my sshd that is exposed to the internet on port 22 has had zero of either. There were a couple of major OpenSSH bugs but my auto updater took care of that before I saw it on the news. You can trust BugCorp all you want but there are more sshd processes out there than tailnets and the scrutiny is on OpenSSH. We are not comparing sshd to say WordPress here. Maybe when you don’t over engineer a solution you don’t need to spend 100x the resources auditing it…
  - lillecarl 9mo ago
    If you only expose SSH then you're fine, but if you're deploying a bunch of WebApps you might not want them accessible on the internet. The few things I self host I keep out in the open. etcd, Kubernetes, Postgres, pgAdmin, Grafana and Keycloak but I can see why someone would want to hide inside a private network.
    - IgorPartola 9mo ago
      Yeah any web app that is meant to be private is not something I allow to be accessible from the outside world. Easy enough to do this with ssh tunnels OR Wireguard, both of which I trust a lot more than anything that got VC funding. Plus that way any downtime is my own doing and in my control to fix.
refulgentis 9mo ago
This felt like it didn’t do your aim justice, “$X and an incomplete understanding of what you’re doing is all it takes to be compromised” applies to many $X, including Tailscale.
justinparus 9mo ago
Using a BigCorp service also has risks. You are exposed to many of their vulnerabilities, that’s why our information ends up in data leaks.
johnisgood 9mo ago
Same applies to Tailscale. A Tailscale client, coordination plane vulnerability, or incomplete understanding of their trust model is also all it takes. You are adding attack surface, not removing it. If your threat model includes "OpenSSH might have an RCE" then "Tailscale might have an RCE" belongs there too. If you are exposing a handful of hardened services on infrastructure you control, Tailscale adds complexity for no gain. If you are connecting machines across networks you do not control, or want zero-config access to internal services, then I can see its appeal.
- b112 9mo ago
  There was a time when people were allowed to drive cars unlicensed. These days, that seems insane. As the traffic grew, as speeds increased, licensing became necessary. I think, these days, we're almost into that category. I don't say this happily. But having unrestricted access seems like an era coming to an end. I realise this seems unworkable. But so was the idea of a driver's license. Sometimes society and safety comes first. I'm willing to bet that in under a decade, something akin to this will happen.
  - deleted 9mo ago
    [deleted]
  - yreg 9mo ago
    Can you be more concrete what do you predict?
  - mpalmer 9mo ago
    I'll take this to mean that you think arbitrary access to a computer's capabilities will require licensure, in which case I think this is a bad metaphor. The point of a driver's license is that driving a ton of steel around at >50mph presents risk of harm to others. Not knowing how to use a computer - driving it "poorly" - does not risk harm to others. Why does it merit restriction, based on the topic of this post?
    - oarsinsync 9mo ago
heavyset_go 9mo ago
Someone would need your 256-bit key to do anything to an exposed Wireguard port.
- eqvinox 9mo ago
  In theory. In the same theory, someone would need your EC SSH key to do anything with an exposed SSH port. Practice is a separate question.
  - bjt12345 9mo ago
    SSH is TCP though and the outside world can initiate a handshake, the point being that wireguard silently discards unauthenticated traffic - there's no way they can know the port is open for listening.
    - eqvinox 9mo ago
      Uh, you know you can scan UDP ports just fine, right? Hosts reply with an ICMP destination unreachable / port unreachable (3/3 in IPv4, 1/4 in IPv6) if the port is closed. Discarding packets won't send that ICMP error. It's slow to scan due to ICMP ratelimiting, but you can parallelize. (Sure, you can disable / firewall drop that ICMP error… but then you can do the same thing with TCP RSTs.)
      - apstls 9mo ago
        That's why you discard ICMP errors.
        eqvinox 9mo ago
        If anything, that's why you discard ICMP port unreachable, which I assume you meant. If you're blanket dropping all ICMP errors, you're breaking PMTUD. There's a special place reserved in hell for that. (And if you're firewalling your ICMP, why aren't you firewalling TCP?)
  - 9mo ago

SchemaLoad 9mo ago

Even if you understand what you are doing, you are still exposed to every single security bug in all of the services you host. Most of these self hosted tools have not been through 1% of the security testing big tech services have.

johnisgood 9mo ago
Now you are exposed to every security bug in Tailscale's client, DERP relays, and coordination plane, plus you have added a trust dependency on infrastructure you do not control. The attack surface did not shrink, it shifted.
- SchemaLoad 9mo ago
  I run the tailscale client in it's own LXC on Proxmox. Which connects to nginx proxy manager also in it's own LXC, which then connects to Nextcloud configured with all the normal features (Passkeys, HTTPS, etc). The Nextcloud VM uses full disk encryption as well. Any one of those components might be exploitable, but to get my data you'd have to exploit all of them.
  - johnisgood 9mo ago
    You do not need to exploit each layer because you traverse them. Tailnet access (compromised device, account, Tailscale itself) gets you to nginx. Then you only need to exploit Nextcloud. LXC isolation protects Proxmox from container escapes, not services from each other over the network. Full disk encryption protects against physical theft, not network attacks while running. And if Nextcloud has passkeys, HTTPS, and proper auth, what is Tailscale adding exactly? What is the point of this setup over the alternative? What threat does this stop that "hardened Nextcloud, exposed directly" does not? It is complexity theater. Looks like defense in depth, but the "layers" are network hops, not security boundaries.
    - butvacuum 9mo ago
      And, Proxmox makes it worse in this case as most people won't know or understand that proxmox's netoworking is fundamentally wrong: its configured with consistent interface naming set the wrong way.
bjt12345 9mo ago
How would another service be impacted by an open UDP port on a server that the service is not using?
IgorPartola 9mo ago
For every remote exploit and cloud-wide outage that has happened over the past 20 years my sshd that is exposed to the internet on port 22 has had zero of either. There were a couple of major OpenSSH bugs but my auto updater took care of that before I saw it on the news. You can trust BugCorp all you want but there are more sshd processes out there than tailnets and the scrutiny is on OpenSSH. We are not comparing sshd to say WordPress here. Maybe when you don’t over engineer a solution you don’t need to spend 100x the resources auditing it…
- lillecarl 9mo ago
  If you only expose SSH then you're fine, but if you're deploying a bunch of WebApps you might not want them accessible on the internet. The few things I self host I keep out in the open. etcd, Kubernetes, Postgres, pgAdmin, Grafana and Keycloak but I can see why someone would want to hide inside a private network.
  - IgorPartola 9mo ago
    Yeah any web app that is meant to be private is not something I allow to be accessible from the outside world. Easy enough to do this with ssh tunnels OR Wireguard, both of which I trust a lot more than anything that got VC funding. Plus that way any downtime is my own doing and in my control to fix.

refulgentis 9mo ago

This felt like it didn’t do your aim justice, “$X and an incomplete understanding of what you’re doing is all it takes to be compromised” applies to many $X, including Tailscale.

justinparus 9mo ago

Using a BigCorp service also has risks. You are exposed to many of their vulnerabilities, that’s why our information ends up in data leaks.

johnisgood 9mo ago

Same applies to Tailscale. A Tailscale client, coordination plane vulnerability, or incomplete understanding of their trust model is also all it takes. You are adding attack surface, not removing it. If your threat model includes "OpenSSH might have an RCE" then "Tailscale might have an RCE" belongs there too. If you are exposing a handful of hardened services on infrastructure you control, Tailscale adds complexity for no gain. If you are connecting machines across networks you do not control, or want zero-config access to internal services, then I can see its appeal.

b112 9mo ago
There was a time when people were allowed to drive cars unlicensed. These days, that seems insane. As the traffic grew, as speeds increased, licensing became necessary. I think, these days, we're almost into that category. I don't say this happily. But having unrestricted access seems like an era coming to an end. I realise this seems unworkable. But so was the idea of a driver's license. Sometimes society and safety comes first. I'm willing to bet that in under a decade, something akin to this will happen.
- deleted 9mo ago
  [deleted]
- yreg 9mo ago
  Can you be more concrete what do you predict?
- mpalmer 9mo ago
  I'll take this to mean that you think arbitrary access to a computer's capabilities will require licensure, in which case I think this is a bad metaphor. The point of a driver's license is that driving a ton of steel around at >50mph presents risk of harm to others. Not knowing how to use a computer - driving it "poorly" - does not risk harm to others. Why does it merit restriction, based on the topic of this post?
  - oarsinsync 9mo ago

heavyset_go 9mo ago

Someone would need your 256-bit key to do anything to an exposed Wireguard port.

eqvinox 9mo ago
In theory. In the same theory, someone would need your EC SSH key to do anything with an exposed SSH port. Practice is a separate question.
- bjt12345 9mo ago
  SSH is TCP though and the outside world can initiate a handshake, the point being that wireguard silently discards unauthenticated traffic - there's no way they can know the port is open for listening.
  - eqvinox 9mo ago
    Uh, you know you can scan UDP ports just fine, right? Hosts reply with an ICMP destination unreachable / port unreachable (3/3 in IPv4, 1/4 in IPv6) if the port is closed. Discarding packets won't send that ICMP error. It's slow to scan due to ICMP ratelimiting, but you can parallelize. (Sure, you can disable / firewall drop that ICMP error… but then you can do the same thing with TCP RSTs.)
    - apstls 9mo ago
      That's why you discard ICMP errors.
      - eqvinox 9mo ago
        If anything, that's why you discard ICMP port unreachable, which I assume you meant. If you're blanket dropping all ICMP errors, you're breaking PMTUD. There's a special place reserved in hell for that. (And if you're firewalling your ICMP, why aren't you firewalling TCP?)
- 9mo ago