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!

  • IsoKiero@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    9 hours ago

    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.