Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IMHO Wireguard + SSH is a better (more robust, widely supported and more secure) approach. Maybe the OP simply hasn't yet heard about or used Wireguard.


"Maybe the OP simply hasn't yet heard about or used Wireguard."

I have, but I do not want to run a VPN solution on my private sever, for which I barely have any need. Also Wireguard, although VERY secure is still not "simple" software.

In addition there are usecases where Wireguard would not help, for example when I want to open up an http service for the current network that Im in.


WireGuard is honestly very easy to set up. All of the commands feel very straightforward: https://www.procustodibus.com/blog/2020/11/wireguard-point-t...

You can definitely run an HTTP server behind WireGuard. WireGuard just adds a network interface that your server can listen on (e.g. your server would listen on a private address like 10.0.0.1).


OP's example was a great one. For example, let's say you visit your friends and you want to watch some content together that is accessible on your server. Using this approach you can open access to that without setting up Wireguard on friend's smart TV.

And Wireguard does use quite a bit of CPU if you are using a lot of network bandwidth. Small servers don't have that much compute power, so utilizing the port knocking somewhat removes that issue.


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.


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


Which smart TVs natively support port knocking?


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.


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.


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.


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...


It does not matter - all the ports are closed.


> It does not matter - all the ports are closed.

Yeah and I have a lock on my door. I still won't post my address on HN. It's all about defense in depth.

Another thing I forgot to mention is that port knocking only works if your hypothetical friend has a dedicated static IP. If your ISP decides to reassign your IP address then IP allowlists are useless. Many ISPs in the US run this racket where they make you pay for a "business account" to get a dedicated IP, even if you only want an IP6 address (which are plentiful).


I don't know that you're right about the WireGuard CPU expense thing.


My router (with Wireguard) can't handle more than 45Mbit/s through Wireguard because the CPU starts throttling.

I suspect that RaspberryPi or old Intel NUC also would not be able to handle speeds anywhere near gigabit.


My NUC easily pegs the network. I'm not sure you're right about this. Either way: you can just use WireGuard as a control channel, the same way this software does.


Wireguard doesn't require much, since it is part of Linux kernel.

But your use-case with http server is a good one. For similar cases I have used custom forward-auth service, but that still requires to have the web server accessible, while your solution hides it completely.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: