litchralee

There's at least !bestoflemmy@lemmy.world

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that's a different topic). It should also be fairly quick to configure the hairpin on your router.

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no "single source of truth" (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that's on top of debugging NAT issues.

Plus, DNS isn't a security feature unto itself: successful resolution of internal hostnames shouldn't increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that's the same faulty argument that suggests ICMP pings should be blocked; it shouldn't.

To be clear, ad-blocking DNS servers don't suffer from the ails of split-horizon described above, because they're intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don't really care if SSOT is diminished for those hostnames.

which means DNS entries in a domain, and access from the internet

The latter is not a requirement at all. Plenty of people have publicly-issued TLS certs for domain named services that aren't exposed to the public internet, or aren't using HTTP(s). If using LetsEncrypt, the DNS-01 challenge method would suffice, or can even issue a wildcard certificate for subdomains, so additional certificate issuance is not required.

If after acquiring a domain, said domain can be pointed to one of many free nameservers that provide an API which can be updated from an ACME script for automatic renewal of the LetsEncrypt certificate using DNS-01. dns.he.net is one such example.

OP has been given a variety of options, each of which come with their own tradeoffs. But public access to Jellyfin just to get a public cert is not a necessary tradeoff that OP needs to make.

Not "insecure" in the sense that they're shoddy with their encryption, no. But being free could possibly mean their incentives are not necessarily aligned with that of the free users.

In security speak, the CIA triad stands for Confidentiality, Integrity, and Availability. I'm not going to unduly impugn Proton VPN's credentials on data confidentiality and data integrity, but availability can be a legit security concern.

For example, if push comes to shove and Proton VPN is hit with a DDoS attack, would free tier users be the first to be disconnected to free up capacity? Alternatively, suppose the price for IP transit shoots through the roof due to weird global economics and ProtonVPN has to throttle the free tier to 10 Mbps. All VPN operators share these possibilities, but however well-meaning Proton VPN and the non-profit behind them are, economic factors can force changes that aren't great for the free users.

Now, the obv solution at such a time would be to then switch to being a paid customer. And that might be fine for lots of customers, if that ever comes to pass. But Murphy's Law makes it a habit that this scenario would play out when users are least able to prepare for it, possibly leading to some amount of unavailability.

So yes, a holistic analysis of failure points is precisely what proper security calls for. Proton VPN free tier may very well be inappropriate. But whether it rises to a serious concern or just warrants an "FYI", that will vary based on individual circumstances.

Don't. OP already said in the previous post that they only need Jellyfin access within their home. The Principle of Least Privilege tilts in favor of keeping Jellyfin off the public Internet. Even if Jellyfin were flawless -- and no program is -- the only benefit that accrues to OP is that the free tier of ProtonVPN can access Jellyfin.

Opening a large attack surface for such a modest benefit is letting the tail wag the dog. It's adding a kludge to workaround a different kludge, the latter being ProtonVPN's very weird paid tier.

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.

Physical wire tapping would be mostly mitigated by setting every port on the switch to be a physical vlan

Can you clarify on this point? I'm not sure what a "physical VLAN" would be. Is that like only handling tagged traffic?

I'm otherwise in total agreement that the threat model is certainly not typical. But I can imagine a scenario like a college dorm where the L2 network is owned by a university, and thus considered "hostile" to OP somehow. OP presented their requirements, so good advice has to at least try to come up with solutions within those parameters.

I had a small typo where "untrusted" was written as "I trusted". That said, I think we're suggesting different strategies to address OP's quandary, and either (or both!) would be valid.

My suggestion was for encrypted L3 tunneling between end-devices which are trusted, so that even an untrustworthy L2 network would present no issue. With technologies like WireGuard, this isn't too hard to do for mobile phone clients, and it's well supported for Linux clients.

If I understand your suggestion, it is to improve the LAN so that it can be trusted, by way of segmentation into VLANs which separate the trusted devices from the rest. The problem I see with this is that per-port VLANs alone do not address the possibility of physical wire-tapping, which I presumed was why OP does not trust their own LAN. Perhaps they're running cable through a space shared with other tenants, or something like that. VLANs help, but MACsec encryption on the wire paired with 802.1x device certificate for authentication is the gold standard for L2 security.

But seeing as that's primarily the domain of enterprise switches, the L3 solution in software using WireGuard or other tunneling technologies seems more reasonable. That said, the principle of Defense In Depth means both should be considered.

Prior-gen Epyc boards show up on eBay from time to time, often as CPU+mobo bundles from Chinese datacenters that are upgrading to latest gen. These can be had for a deal, if they're still available, and would provide PCIe lanes for days.

I agree with the idea of not using a 10 Gbps network for GPU work. Just one small nitpick: PCIe Gen 1 in an x1 slot is only capable of 2.5 GTransfers/sec, which translates to about 2 GBits/sec, making it about 5x slower than a 10 Gbps line-rate network.

I sincerely hope OP is not running modern AI work on a mobo with only Gen 1...

After reviewing the entire thread, I have to say that this is quite an interesting question. In a departure from most other people's threat models, your LAN is not considered trusted. In addition, you're seeking a solution that minimizes subscription costs, yet you already have a VPN provider, one which has a -- IMO, illogical -- paid tier to allow LAN access. In my book, paying more money for a basic feature is akin to hostage-taking. But I digress.

The hard requirement to avoid self-signed certificates is understandable, although I would be of the opinion that Jellyfin clients that use pinned root certificates are faulty, if they do not have an option to manage those pinned certificates to add a new one. Such certificate pinning only makes sense when the client knows that it would only connect to a known, finite list of domains, and thus is out-of-place for Jellyfin, as it might have to connect to new servers in future. For the most part, the OS root certificates can generally be relied upon, unless even the OS is not trusted.

A domain name is highly advised, even for internal use, as you can always issue subdomains for different logical network groupings. Or maybe even ask a friend for a subdomain delegation off of their domain. As you've found, without a domain, TLS certificates can't be issued and that closes off the easy way to enable HTTPS for use on your untrusted LAN.

But supposing you absolutely do not want to tack on additional costs, then the only solution I see that remains is to set up a private VPN network, one which only connects your trusted devices. This would be secure when on your untrusted LAN, but would be unavailable when away from home. So when you're out and about, you might still need a commercial VPN provider. What I wouldn't recommend is to nest your private VPN inside of the commercial VPN; the performance is likely abysmal.

Agreed. Email has its uses -- ubiquity, mostly "Just Works" (tm), most people know how to use it -- and while I might send a symmetric encrypted PDF along with a plaintext email, I'm more inclined to suggest that my recipients adopt Signal and get all the benefits of e2ee. EFF even has a guide for it: https://ssd.eff.org/module/how-to-use-signal