Tailscale+Headscale are pretty easy to implement these days. Since it’s effectively zero trust, the tunnels become the encrypted channel so there’s an argument that HTTPS isn’t really required unless some endpoints won’t be accessing services over the Tailnet. SmallStep and Caddy can be used to automatically manage certs if it’s needed though.
You can even configure a PiHole (or derivative) to be your DNS server on the VPN, giving you ad blocking on the go.
there’s an argument that HTTPS isn’t really required…
Talescale is awesome but you gotta remember that Talescale itself is one of those services (Yikes). Like all applications it’s potentially susceptible to vulnerabilities and exploits so don’t fall into the trap of thinking that anything in your private network is safe because it’s only available through the VPN. “Defence in depth” is a thing and you have nothing to lose from treating your services as though they were public and having multiple layers of security.
The other thing to keep in mind is that HTTPS is not just about encryption/confidentiality but also about authenticity/integrity/non-repudiation. A cert tells you that you are actually connecting to the service that you think you are and it’s not being impersonated by a man in the middle/DNS hijack/ARP poison, etc.
If you’re going to the effort of hosting your own services anyway, might as well go to the effort of securing them too.
Tailscale isn’t an exposed service. Headscale is, and it isn’t connected to the Tailnet. It’s a control server used to communicate public keys and connectivity information between nodes. Sure, a threat actor can join nodes to the Tailnet should it become compromised. But have you looked at Headscale’s codebase? The attack surface is significantly smaller than anything like OpenVPN.
A cert tells you that you are actually…
I’m all for ssl/tls, but it’s more work and may not always be worth the effort depending upon the application, which is exactly why I recommended SmallStep+Caddy. Let’s not pretend that introducing things like a CA don’t introduce complexity and overhead, even if it’s just distributing the root cert to devices.
MITM/DNS Hijack/ARP Poisoning…
Are you suggesting that these attack techniques are effective against zero trust tunnels? Given that the encryption values are sent out of band, via the control channel, how would one intercept and replay the traffic?
Absolutely! And it’s a great system that I thoroughly recommend. The attack surface is very small but not non-existent. There have been RCE using things like DNS rebinding(CVE-2022-41924) etc. in the past and, although I’m not suggesting that it’s in any way vulnerable to that kind of thing now, or that it even affected most users we don’t know what will happen in future. Trusting a single point of failure with no defence in depth is not ideal.
it’s more work and may not always be worth the effort
I don’t really buy this. Certs have been free and easy to deploy for a long time now. It’s not much more effort than setting up whatever service you want to run as well as head/tailscale, and whatever other fun services you’re running. Especially when stuff like caddy exists.
I recommended SmallStep+Caddy.
Yes! Do this if you don’t want to get your certs signed for some reason. I’m only advocating against not using certs at all.
Are you suggesting that these attack techniques are effective against zero trust tunnels
No I’m talking about defence in depth. If Tailscale is compromised (or totally bypassed by someone war driving your WiFi or something) then all those services are free to be impersonated by a threat actor pivoting into the local network after an initial compromise. Don’t assume that something is perfectly safe just because it’s airgapped, let alone available via tunnel.
I feel like it’s a bit like leaving all your doors unlocked because there’s a big padlock on the fence. If someone has a way to jump the fence or break the lock you don’t want them to have free reign after that point.
My claim is that Headscale has a lesser likelihood of compromise than Nextcloud, and that the E2EE provides an encrypted channel between nodes without an immediate need for TLS. Of course TLS over E2EE enhances CIA. There’s no pushback to defense in depth here. But in the beginning, the E2EE will get them moving in the right direction.
OP began the post by stating that the login page to a complex PHP web application is internet facing (again, yikes). Given the current implementation, I can only assume that OP is not prepared to deploy a CA, and that the path of least resistance – and bolstered security – can be via implementation of HS+TS. They get the benefit of E2EE without the added complexity, for which there is plenty, of a CA until if/when they’re ready to take the plunge.
If we’re going to take this nonsense all or nothing stance, don’t forget to mention that they’re doing poorly unless they implement EDR, IDS, TOTP MFA on all services, myriad DNS controls, and full disk encryption. Because those components don’t add to the attack surface as well, right?
My only issue was with the assertion that OP could comfortably do away with the certs/https. They said they were already using certs in the post and I wanted to dispel the idea that they arguably might not need them anymore in favour of just using headscale as though one is a replacement for the other.
I haven’t had any issues with Nextcloud yet. But any torrent client refuses to work. I’ve tried various qbittorrent containers, transmission, deluge briefly, they all work for a while but eventual refuse to do anything.
I had TOTP die for one user on my Nextcloud. I tried to disable it, but it “didn’t exist”. I tried to enable it, but it was already enabled. It would come up when I used occ twofactorauth:state user. I ended up fixing it by (force) disabling the app and re-enabling it. It didn’t break any other user’s TOTP and it fixed problem-user’s TOTP. No idea what went wrong, but I get these random issues with Nextcloud sometimes.
The plus side to this is I’ve learnt how to use Mariadb and I’ve gotten better at debugging things.
Well dang, I have Nextcloud installed as a snap (which has been perfectly stable for me when running on Ubuntu Server), but I was thinking of switching over to a docker installation; this thread doesn’t exactly fill me with enthusiasm for that idea…
Anecdotal, but Ive had a container running Nextcloud in an LXC on Proxmox along with PiHole, Step CA, Bacula, and quite a few other services and I’ve had zero downtime since June 2023. Even have Tailscale rigged to use PiHole as the tailnet DNS to have adblocking on the go.
Guess that restart: always value in the Compose config is pulling it’s weight lol
I ended up on the snap because I couldn’t get the AIO install working properly. My snap version has been super solid. I think I’m gonna stick with it for a while.
I’ve been a proponent here for a few months on using postgres/redis every time someone shits on NC for performance. While I agree the database change itself isn’t a huge improvement, it pays for itself long term in larger volume installs when you and your organization/group get using it heavily. The redis connected on socket like the AIO mastercontainer sets up is where the real juice comes from, but only on an install that gets used so it caches properly. The first time you fire it up, it’s pretty slow but as it gets used, things are much better.
It’s not both, it’s Akamai Connected Cloud. The Linode brand has been retired. The vestiges of the Linode brand that are still visible are merely due to Akamai’s sloppy and disordered integration effort. They’ll likely retain the Linode.com domain so as not to break existing API calls, but the switch away from Linode.com as the primary domain, and removal of the name Linode from technical documents and design elements is ongoing.
Roku, Playstation, Xbox, streaming device from ISP (like the device from comcast), Fire stick, and I’m sure there are many more. They all do what you’re looking for.
Xbox sucks as a streaming box, especially with Plex. If you try to choose something from the watchlist, it can’t send a url to the related streaming app.
I just did a quick bing chat search (“does DRI_PRIME work on systems without a cpu with integrated graphics?”) and it says it will work. I can’t check for you because my CPUs all have graphics.
I CAN tell you that some motherboards will support it (my ASUS does) and some don’t (my MSI).
BTW, I’m talking about Linux. If you’re using Windows, there’s a whole series of hoops you have to jump through. LTT did a video a while back.
While it might work in the OS, setting the OS up may be a pain (the installer may or may not work like that) and I strongly suspect that the BIOS can’t handle it.
I suspect that an easier route would be to use a cheap, maybe older, low-end graphics card for the video output and then using DRI_PRIME with that.
It’s probably a pain to set up in Windows. In Linux, it just works, there’s nothing to set up. I’m using it right now.
OP really should have mentioned their OS.
Edit: Actually, nevermind both my posts. I know DRI_PRIME works by using my APU for regular desktop activity, and routing discrete GPU output in whenever a game is being played. But I don’t know if it’s possible to make it use the dGPU all the time.
Even if it did, it would only work inside the OS, so if you had to boot into the BIOS for anything, you wouldn’t have a display. So for all intents and purposes, it wouldn’t really work.
selfhosted
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.