There is still no complete replacement for LAN plaintext connections · Issue #23 · WICG/private-network-access (original) (raw)

I've just been informed about this spec proposal, and I noticed that you're citing Plex as a mechanism for doing TLS on LAN servers that public sites communicate with.

I'm an engineer at Plex working on the media server, and it seems like you're missing a key caveat that our current implementation runs into, which in my opinion need to be addressed before this feature can land in browsers in its current state, or else our case will break for a number of users.

I've explained the problem in this Chromium issue; here's a quick summary:

CORS-RFC1918 isn't the first attempted solution to DNS rebinding attacks. A number of consumer and commercial routers have a feature (often on by default, sometimes non-user-configurable) that blocks DNS responses that give A records pointing to LAN addresses. This completely breaks our HTTPS setup, and forces us to downgrade to plaintext connections to raw IP addresses, which (thanks to mixed-content blocking) also forces us to load the web app itself over plaintext HTTP.

This situation is extremely regrettable as-is, but with the current CORS-RFC1918 proposal this case would break completely, meaning users in that situation wouldn't be able to access their LAN servers via the public web app at all. Specifically, this change would prevent any plaintext-HTTP loads of LAN resources from public origins.

This wouldn't be an issue for us if we didn't need to make plaintext requests in the first place, and I'd much prefer to get to a world where we no longer have to rather than coming up with some exception to allow them. As detailed in the linked Chromium issue, we handle this in most non-browser clients (all those on platforms where we have full control over the TLS and network stacks) by skipping DNS resolution entirely. That Chromium issue asks for a way to do the same in-browser. This or some other mechanism to allow TLS connections to LAN hosts with known IP addresses without public DNS is necessary for our product to continue working on affected networks if plaintext LAN requests from public hosts are blocked.

I've wondered whether this might be solvable using multicast DNS as well, though I'm not sure if that really provides any advantage over just letting JS short-circuit name resolution.