Hey everyone,
I’m one of the people who still used proton and am now in the process of switching everything and trying to selfhost more.
I sucessfully setup Vaultwarden. I also decided I should move away from having my dockers publicly exposed with nginx reverse proxy and switched everything over to netbird. Im using their proxy feature now to access everything with custom domains and followed a tutorial to setup a bring your own proxy server on a vps. So now all my services are only accessible when my netbird vpn is active. I also spun up a pihole docker and added that to my netbird dns servers to try and get ad blocking on my mobile devices. So far so good.
I wonder however that while some webui’s like vaultwarden run with https, others like radarr dont. Is this a problem or does it not matter so much since i have the vpn running?
I dont really understand how I would go about making them https though. Im on unraid for my dockers and don’t see why some use https and others don’t.
Sorry if this is a convoluted post, I’m quite in over my head with all the networking and dns stuff and just hoping I’m not doing something stupid.
Thanks for your help!
if you’re accessing over the internet, always use TLS/HTTPS.
if you’re accessing over LAN, you should still use TLS/HTTPS.
just because you’re hosting the app locally doesn’t mean the JS embedded in the page is safe. HTTPS will ensure that all your traffic is encrypted so only you and the server knows what it contains.
Yes, always use HTTPS, even on local networks if there ever are more than one device on the network.
The way to handle services with/without HTTPS is to put everything behind a reverse proxy that automatically handles certificates. Since you’re using NGINX, you can try setup certbot, or switch to something like Caddy that has certificate handling built in. If you have all your Docker containers on one server, you can look at Traefik.
Always use HTTPS. Especially if you’re using your services on mobile.
Imagine you’re on your friend’s WiFi, and you disconnect from your net bird/tailscale/wireguard connection to your self hosted network… Any and all mobile apps that require that secure connection, is going to be making calls to your internal services and trying to pass auth/session token details to them.
A bad actor on your friend’s WiFi network, could, in theory, capture these requests and now you’re at the mercy of how well those services are written.
It’s a bit paranoid, but this is what we are trying to mitigate here.
It’s not even that hard to imagine, this is exactly what rogue wifi access points do. It’s surprisingly common for wifi access at places like coffee shops to be compromised and used to silently conduct these types of attacks. The people that set them up are not very knowledgeable and also they don’t ever check up on them as long as they keep working.
This is also why you want to enable HSTS on top of your HTTPS, so that rogue requests to downgrade the connection to plain HTTP are ignored.
Another good idea is to place all the services that should only be accessed over VPN only in private DNS (home LAN DNS and the VPN’s DNS), never in public DNS. A simple and effective way of doing that is to place them on a deep subdomain like
*.private.example.comrather than*.example.com. That way if your VPN drops when you try to resolve those subdomains you don’t get any response anymore and there’s no connection for the rogue wifi to hijack.Yep! Definitely don’t add any of your internally used domains used on public DNS services. Be careful requesting SSL certs for the child subdomains too. They will show up on transparency logs like on shodan.io. Use internal DNS, and wild card certs for these things. And obviously, do not expose your ports publically.
Yes especially since https is to setup and maintain.
Yes you do.
First of all, there are services that will refuse to work properly on http only. Specially if you want an SSO like authelia, will not work over http
Second, modern browsers will complain when using plain http if the website has forms to fill or passwords to write … very annoying, but it’s the way it is.
Third, having the “this site is not secure” broken lock is not very nice for users. At best they might complain, at worse they will get used to “unsecured” websites and .ight end up easier prey for fake sites in the future. Yes I mean wife or kids. These are things normal users should not see as normal…
Last, if you expose anything to the web, please never ever do that without proper https with certificates from let’s encrypt.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CA (SSL) Certificate Authority DNS Domain Name Service/System SSO Single Sign-On TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network nginx Popular HTTP server
6 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.
[Thread #162 for this comm, first seen 8th Nov 2026, 18:10] [FAQ] [Full list] [Contact] [Source code]
short answer (and the safest one) is yes, use HTTPS always.
However, if and only if a service you are using is confined locally or via your privately hosted VPN (this just means not available over the public internet) you are probably OK without, unless there are other people on your local network who might be interested in snooping.
with your VPN (looks like netbird in this case) you should be OK, as the VPN handles encryption in the absense of HTTPS.
For more research checkout LetsEncrypt. its a super simple way to setup SSL (Which generally makes up the S part in HTTPS) and it’s free.
i think many of us started like you. you’ll get there, you’re just about to learn a lot of stuff before you do.
I suggest you should treat your own network as at least a little compromised.
Most houses run something that has a residential proxy, browsers like Chrome are happy to snoop on your local network, and apps and smart devices are completely free to use your network as they see fit by default.
Anything that has sensitive data should be handled via https.
agreed. this is part of the reason i have separate VLANs for my server, IoT network, Management network, guests, and home computers. I also consciously try not to use programs like Chrome and all my traffic goes through OPNSense/Unbound DNS.
i realize not everyone has the equipment for / can do all of that though. And that despite all of that and more, I’m still compromised to anyone with dedication. or a fucking ai
I just want to point out that it’s not just other people who might be interested in snooping. Compromised smart home equipment is a big potential vector of attack if services are unencrypted on your home network.
Relevant XKCD: https://xkcd.com/1966/
Websites exist just to look through exposed pc’s files and webcams, or used to at least
If you’re not using https, then anyone who can see the traffic in your VPN can see everything you do.
Whether that’s a problem depends. In principle, as long as access to your VPN is restricted to people you trust, then http inside it is fine. In practice, if your security isn’t perfect, and someone gets access to your VPN, then https provides a meaningful second line of defense.
My recommendation would be to never use http for anything where a breach would be really painful. It’s good that vaultwarden is on https. Beyond that, https is absolutely the best practice, but if someone getting access to your service is only a mild inconvenience, then leaving it on http is fine as long as it’s only accessible inside your VPN - the risk is relatively low, and the consequences aren’t bad.
What about Tailscale, can they see http traffic over my Tailscale connection?
What about Tailscale, can they see http traffic over my Tailscale connection?
No, they can’t see anything inside node-to-node connections. They are encrypted end-to-end with keys that are only kept on each node and the node clients are open source so you can verify yourself that’s how it works.
The Tailscale servers only help the nodes find each other and establish connections to each other, they don’t have any access to the connections themselves.
The only way for Tailscale to intervene would be for them to silently add their own nodes to your tailnet but (1) even then the rogue node would only see connections between itself and other nodes, not connections between other nodes, and (2) at some point they added a setting that requires existing nodes to approve any new node, so you can use that to completely prevent it.
Tail scale should act as a mediator basically initializing the connection between two remote sessions. Then stepping away, letting go two remote sessions handle everything else. If every customer’s traffic had to go through them as a central server, it would be a central bottleneck and a massive operating cost for them. This is why free Vpns are never worth it. You are always the product on them, and they are always heavily mining your data.
I’m not sure that’s true to say it “steps away” because you can go to tailscale.com (on a machine that’s not connected to the tailnet) and log into the console and see all the machines and change their settings if you want, so clearly something is routing through their servers and actions taken on their servers are able to influence the machines.
I’m not an expert here clearly, just going on my own observations.
The tailnet devices report their status to the central servers along with the version they run, the state of their connections to the rest of the tailnet and (unless you disable it) they also send in their logs. But the central server can’t see inside node-to-node connections.
Ok good to know thanks for the clarification!
Its possible the client on your PC could be profiling your traffic and reporting back. That would likely end up badly for the parent company. But things like that aren’t unheard of and part of the reason I’m building my own router again. (See the ongoing GN LG coverage) Those sort of devices can spy on, and report back about other traffic on the network. If your smart devices are connected via Ethernet then they can likely see and read everything on your network that is unencrypted.
But a management console isn’t traffic snooping. Yes, you do have to trust the client to use it. They aren’t routing your traffic through them though. If they’re found to be spying it will be huge news turning them into a parriah in the IT and open source communities.
Thanks that makes sense
Tailscale is a sort of VPN. So, yeah, treat it the same.
I’m mostly responding to add a little context to the security concerns. Probably the biggest inside-the-VPN concern is that someone on your VPN gets some malware. So, if this is your family network, and say, your kid’s phone or laptop gets some malware, now any non-encrypted traffic is potentially compromised. Basically, the VPN is only as secure as the weakest link. That’s the thing you’re protecting against with https for individual services.
If I were hosting vaultwarden, and had my bank login in there, I absolutely wouldn’t consider a VPN + http sufficient protection. With LLMs, if we don’t have malware that knows how to hunt around for valuable credentials in the wild already, it’ll be here soon. I personally run my Jellyfin server over https because I’ve gone to the trouble to set up a good system to use letsencrypt with nginx as a proxy for any service. But I wouldn’t be too worried about running Jellyfin over http.
HTTPS for everything means you have to buy into the cartel of “identity providers” that manage DNS and certificates, even if there are some mostly-good actors in there such as Let’s Encrypt, you still have the external dependency. As we have seen with cases such as Austistici, having that dependency can be a problem. It’s your call if it is in your case or not, but I wanted to raise this point because no one has pointed out that particular weakness vector so far in the thread.
In a very general sense, if your services are under a netbird or any sort of VPN where you control who gets account access or not, you “should not need” HTTPS. Might still be convenient to have.
There’s no cartel, you can buy a HTTPS cert from lots of places all over the world. Most domain registrars can set you up. It just won’t be free like Let’s Encrypt and also will have a very different renewal process (most likely once a year manually rather than every 90 days automatically).
It’s a cartel in the sense that the CA/Browser forum determines, on their own whim, which CA gets featured or revoked in your browser. And single-handedly impose technical restrictions like shorter cert lifetimes and less features. Stuff like eMudhra being able to compromise everyone shows its quite a vulnerable group of single-point failures as well, but still condoned by almost everyone.
ZeroSSL and Komodo does have free certs if I remember correctly. They’re still bound by the 90 days (soon to be 47) limit though
All you need is a DNS name. You can buy one for a few dollars.
Even if you refuse to buy a domain you could always run your own certificate chain
That sounds interesting. But then you have to convince your peers to install your certificate root, right?
No, you would only use this internally. Overall doing this is a bad idea (if the root gets stolen encryption is useless) but is technically possible if you are looking for a learning exercise. It would be about the same amount of work as Let’s encrypt since you would probably still want to run ACME with fairly short certificate lifetimes.
Well you could technically also use self signed certificates. But it requires a bit more work as well as installing your own custom CA cert.
Self signed isn’t quite the same as a internal CA
Yeah I oversimplified but doing the whole thing your self is possible.
I use tailscale serve for my selfhosted stuff. (Safari on my phone won’t let me open http sometimes)
Safari
Get a better browser? HTTP is as legit a transmission protocol as HTTPS and email are.
All mobile browsers are safari wrappers on iphone
Back when I joined Lemmy (and before I understood what .ml was), I tried to contribute to the project. I suggested updating a link (possibly to docs) that was using an HTTP connection. The goal at the time was to make Lemmy approachable for normal users. As a user, I have non-secure sites blocked in my browser, so I have to manually proceed… and seeing that warning makes me not want to use a site. The devs told me that the link didn’t matter because the site was static. That was the end of my being willing to contribute, and my monetary support for the project ended as soon as I understood the dev’s beliefs and personalities.
Is this a problem or does it not matter
It’s not a problem, but it does matter. With plain HTTP traffic everything you send and receive from a given site is unencrypted, so anyone in the chain delivering your package can read what you’re doing, collect your passwords and do all kinds of shenanigans. If it’s just your local network which is secured from the public internet then it’s pretty much just you who can intercept that traffic and it’s generally fine, as you already have all the passwords and such. And if you connect to the services via VPN that takes care of ‘secured from public interenet’ -part of the equation.
HTTPS is the same traffic, but encrypted with certificates. To achieve that you’ll need to have a server certificate and then browsers can use the public part of certificate to encrypt your traffic. With docker that’s commonly achieved either with docker-proxy or external proxy like nginx. Your computer already has a bunch of certificate authorities which it trusts and they are bundled in your operating system and/or browser. Without a trusted certificate your browser throws a warning about it, but if you proceed with ‘untrusted’ certificate the traffic will still be just as strongly encrypted as it would be with a ‘known’ certificate. The catch is that anyone can create their own certificates, so there’s no guarantee if the server actually is what it claims to be. For example I could sign my own certificate for gmail.com and offer that to users and steal their passwords. That would of course be trivial to figure out as the browser wouldn’t show the “good” lock symbol on address bar, but the certificate would be technically speaking a working certificate.
Now, to get a certificate for your own services you need to either build your own certificate authority and add that to trusted list of your devices or obtain a certificate from a already known authority like letsencrypt. With letsencrypt (and other similar services) you need to provide a proof that you own a domain which you’re obtaining the certificate for, so with those you can’t get a certificate for gmail.com or any other random domain name. Letsencrypt uses ‘certbot’ tool to validate certs, other services ask for spesific DNS entry or something else for proof that the domain is actually yours. But the main part is that all the ‘commonly known’ certificate authorities work only on publicly available services and domains (a bit simplified explanation, but that’s roughly it).
But once you have the certificate you’ll need to configure something on your network to use it. Actual best practice and configuration depends on the service you’re running. If your services run only on your local network and they are never allowed to public internet you’re likely fine to run everything without HTTPS encryption, but it’s still good to understand the differences and effects between unencrypted and encrypted traffic.
For me, everything exposed to the internet is https (that is http + Apache reverse proxy using Let’s Encrypt), and everything that is not (and I access via my tailnet) is http.
If the access is only over VPN then http is fine, that’s how I access my arr setup. You can create certificates and manually upload them to radarr and other sites but it’s not necessary.
@inquanto Theoretically, when you are alone in your own network it can be ok, to go only with http. But login passwords over http are transferred without encryption.
The problem with https are valid certificates, so that clients can connect to your selfhosted services without issues.
For example, I was not able to connect with a KDE PIM program to a Nextcloud with a self signed certificate or with http only.With step-ca there can be a solution for this problem:
https://jan.wildeboer.net/2025/07/letsencrypt-homelab-stepca/You could just use Let’s encrypt
@possiblylinux127 Only when you have a valid domain name.
Not everybody can or wants to pay for a domain name, when it is not really necessary.
Their cheapest domains are $1/year. I’m not sure I understand why you wouldn’t just get a domain.
@possiblylinux127 A domain creates dependencies on external infrastructure.
Let’s Encrypt and the Internet Security Research Group are U.S. organizations that rely on donations and can very likely be restricted by instructions from the American government.
Don’t get me wrong, if you want to use your own domain, you could do so.
But this creates dependencies for self-hosting, which may not be wanted and/or probably also not necessary.So your solution is to use a less secure setup? I don’t really get your logic. It is trivial to migrate acme providers and all your devices are already dependent on the global certificate authorities including Let’s encrypt
