this sort of stuff is rampant. A few years old but it makes my blood boil every time I think about it.

Tool Creator should work on this, it ain’t making no sense that the default json file (Google) is not updated cause seeing that work on Google tells us that it definitely works on all sites

@drk1wi please resolve google.json file to stop this cookie disabled error

Seems minor but the tone of the demand is wildly entitled.

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?

Tailscale is one of those services…

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?

Yikes! I’d avoid leaving any services externally exposed unless they’re absolutely necessary…

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.

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

Definitely complicated to root cause. Please share if ya figure out the hard parts 😄

An idea: Netflix could be fingerprinting TUN interfaces on the TV.

One thing I’d consider trying is Tailscale in userspace networking mode on a distinct network host at location 2, which’ll start a SOCKS/HTTP proxy that the TV can use for outbound connections.

Bonus: any devices incompatible with Tailscale can use the proxies.

If you’d like to take a stab at this, Headscale is a self-hosted version of Tailscale’s service. Personally, I use Caddy to automatically manage letsencrypt certs while proxying requests to Headscale.