I am making this post in good faith

In my last post I asked about securely hosting Jellyfin given my specific setup. A lot of people misunderstood my situation, which caused the whole thread to turn into a mess, and I didn’t get the help I needed.

I am very new to selfhosting, which means I don’t know everything. Instead of telling me that I don’t know something, please help me learn and understand. I am here asking for help, even if I am not very good at it, which I apologize for.

With that said, let me reoutline my situation:

I use my ISP’s default router, and the router is owned by Amazon. I am not the one managing the router, so I have no control over it. That alone means I have significant reason not to trust my own home network, and it means I employ the use of ProtonVPN to hide my traffic from my ISP and I require the use of encryption even over the LAN for privacy reasons. That is my threat model, so please respect that, even if you don’t agree with it. If you don’t agree with it, and don’t have any help to give, please bring your knowledge elsewhere, as your assistance is not required here. Thank you for being respectful!

Due to financial reasons, I can only use the free tier of ProtonVPN, and I want to avoid costs where I can. That means I can only host on the hardware I have, which is a Raspberry Pi 5, and I want to avoid the cost of buying a domain or using a third party provider.

I want to access Jellyfin from multiple devices, such as my phone, laptop, and computer, which means I’m not going to host Jellyfin on-device. I have to host it on a server, which is, in this case, the Raspberry Pi.

With that, I already have a plan for protecting the server itself, which I outlined in the other post, by installing securecore on it. Securing the server is a different project, and not what I am asking for help for here.

I want help encrypting the Jellyfin traffic in transit. Since I always have ProtonVPN enabled, and Android devices only have one VPN slot enabled, I cannot use something such as Tailscale for encryption. There is some hope in doing some manual ProtonVPN configurations, but I don’t know how that would work, so someone may be able to help with that.

All Jellyfin clients I have used (on Linux and Android) do not accept self-signed certificates. You can test this yourself by configuring Jellyfin to only accept HTTPS requests, using a self-signed certificate (without a domain), and trying to access Jellyfin from a client. This is a known limitation. I wouldn’t want to use self-signed certificates anyways, since an unknown intruder on the network could perform a MITM attack to decrypt traffic (or the router itself, however unlikely).

Even if I don’t trust my network, I can still verify the security and authenticity of the software I use in many, many ways. This is not the topic of this post, but I am mentioning it just in case.

Finally, I want to mention that ProtonVPN in its free tier does not allow LAN connections. The only other VPN providers I would consider are Mullvad VPN or IVPN, both of which are paid. I don’t intend to get rid of ProtonVPN, and again that is not the topic of this post.

Please keep things on-topic, and be respectful. Again, I am here to learn, which is why I am asking for help. I don’t know everything, so please keep that in mind. What are my options for encrypting Jellyfin traffic in transit, while prioritizing privacy and security?

  • litchralee@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    4 days ago

    I previously proffered some information in the first thread.

    But there’s something I wish to clarify about self-signed certificates, for the benefit of everyone. Irrespective of whichever certificate store that an app uses – either its own or the one maintained by the OS – the CA Browser Forum, which maintains the standards for public certificates, prohibits issuance of TLS certificates for reserved IPv4 or IPv6 addresses. See Section 4.2.2.

    This is because those addresses will resolve to different machines on different networks. Whereas a certificate for a global-scope IP address is fine because it should resolve to the same destination. If certificate authorities won’t issue certs for private IP addresses, there’s a good chance that apps won’t tolerate such certs either. Nor should they, for precisely the reason given above.

    A proper self-signed cert – either for a domain name or a global-scope IP address – does not create any MITM issues as long as the certificate was manually confirmed the first time and added to the trust store, either in-app or in the OS. Thereafter, only a bona fide MITM attack would raise an alarm, the same as if a MITM attacker tries to impersonate any other domain name. SSH is the most similar, where trust-on-first-connection is the norm, not the outlier.

    There are safe ways to use self-signed certificate. People should not discard that option so wontonly.

    • catloaf@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      5 days ago

      It sounds like the clients do not have the ability to manually trust a self-signed cert.

      • N0x0n@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        edit-2
        4 days ago

        I don’t get that…

        I have self-signed SSL certificate and intermediateCA installed on all my devices and works flawlessly with every application that accept those (on android the manifest.XML has to allow user based certificate which is in most cases).

        One exception on Android was the use of MPV which doesn’t do that and never will? However, the web player video type from official application works without issues…

        I have navidrome, jellyfin, Ironfox, LibreTube, KoReader, Findroid… All work flawlessly with self-signed certs !

        The issue here (as said in the second answer of his linked jellyfin post) is that them needs a reverse proxy that takes care of the SSL handshake and not jellyfin directly. So OP was missing a lot of good information in them’s first post…

        • catloaf@lemm.ee
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          4 days ago

          If it’s signed by an intermediate CA, then it’s not self-signed.

          • N0x0n@lemmy.ml
            link
            fedilink
            English
            arrow-up
            2
            ·
            4 days ago

            Huh? Yeah it is… It’s a self-signed intermediate CA, signed by a self-signed rootCA.

            In my case a miniCA in my lan.

            • catloaf@lemm.ee
              link
              fedilink
              English
              arrow-up
              3
              ·
              4 days ago

              Right. If it’s signed by a CA, it’s not self signed. Self signed means signed by nobody but the server that generated it.

              self-signed certificates are public key certificates that are not issued by a certificate authority (CA)

              https://en.wikipedia.org/wiki/Self-signed_certificate

              An internal CA whose signing certs you’ve manually installed is still a trusted CA.

              • N0x0n@lemmy.ml
                link
                fedilink
                English
                arrow-up
                1
                ·
                4 days ago

                Ohhhhh ! Sometimes I just need to sh*up !

                Thanks for the clarification.

      • Hydrian@twit.social
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        4 days ago

        @catloaf @litchralee As they shouldn’t trust a self-signed cert. If you can run Jellyfin, you can run an internal CA and DNS server. Create a .internal domain in your DNS server and create certs based on it. Then just roll out your root ca cert.