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!

  • quaff@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 hour ago

    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.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 hour ago

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

      • quaff@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        26 minutes ago

        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.