[throwitaway1123]

WireGuard has apps for most devices (macOS, iOS, Android, Windows). For smart TVs it's a bit of a mixed bag. Some of them do support VPN clients, and I know Tailscale works on the Apple TV now (Tailscale uses WireGuard under the hood).

If you're using the Ruroco client to proxy requests to the server, then you could do the same with WireGuard. You could have HAProxy (or something similar) proxy requests from your local network to the WireGuard interface.

[Jnr]

It is much simpler to open access to the same network using port knocking than setting up VPN apps and profiles on TV.

[throwitaway1123]

Which smart TVs natively support port knocking?

[Jnr]

No, the example is - you go to friends, join their Wifi, have the same external IP, send the knock from your phone/laptop to open 443 to that IP, and then you can connect from TV or their computers.

[throwitaway1123]

Port knocking only handles authentication (it's basically a crude password). It doesn't ensure the integrity (tamper prevention) or privacy of your connection. You would need to set up SSL certificates to handle that. You also need to get the TV to accept those certificates, which would require either a public DNS record (which exposes your server's IP via the certificate transparency log to any client that can issue a DNS request), or you would need to modify your friend's router's DNS resolver (which is even more complicated than installing a VPN, and assumes the TV uses the router's DNS server). A TV isn't going to have an /etc/hosts file that you can use to point a domain at your server's IP address.

So instead I would go to my friend's house, connect to their Wifi, and accept incoming connections from computers and TVs over the local area network and forward them through WireGuard. The TV would connect to my device via plain HTTP (which is fine since it's all happening locally), and then my device would be responsible for securely connecting to the server via WireGuard. This also has the benefit of implicitly revoking access as soon as I leave their house with my device.

[Jnr]

You are slightly wrong.

TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step.

And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

[throwitaway1123]

You are both slightly wrong, and slightly misunderstanding what I'm saying.

> TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate.

TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with.

> And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

Yes this is called the ACME DNS challenge. I've used it many times, but if you want to be able to type in your server's domain name on a friend's TV and have it resolve to your server's IP address, then you'll need a public DNS record.

> Certificate itself has nothing to do with DNS beyond the verification step.

Yes it does, because most certificate authorities only sign certificates for fully qualified domain names, not IP addresses [1], so it obviously does involve the domain name system (you can view the domain name associated with a certificate in your browser, it'll be listed under the field "common name"). On a desktop computer you could get around this by editing the hosts file to map any domain name to any arbitrary IP address, but you can't do that on a TV.

> And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

I never said anything about ports, I said a public DNS record exposes the server's IP address. The whole point of the domain name system is to convert domain names into IP addresses, so that you can actually use the internet protocol to connect to a server's IP (internet protocol) address. Try running dig from the command line on literally any domain name and watch it expose the server's IP. Malicious bots can watch the transparency log to find out about new certificates [2], then run dig or some other tool to issue a DNS request (to determine the IP address of the server), and then start hammering the server to search for vulnerabilities or even potentially to just DDOS it. If you use a wildcard certificate it's harder for attackers to figure out which subdomain to query to find your server's IP, but with WireGuard I don't need a domain name at all.

[1] https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-d...

[2] https://community.letsencrypt.org/t/suspicious-web-traffic-a...