Draft "PoProxy" binding to relay parcels over TLS proxies

[gnarea]

Executive summary

Relaynet-Internet Gateway operators could deploy highly-distributed pools of ephemeral TLS proxies to bypass censorship in regions employing a denylist approach (e.g., China). Proxy addresses won't be public to prevent censors from adding them to the denylist -- Instead, each proxy will only be shared by 1-5 devices. Additionally, proxies would look like legitimate websites if a censor were to probe them (e.g., by sampling the connections that were allowed recently).

The problem you're trying to solve

Circumventing denylist-based censorship has always been a cat-and-mouse game because (a) proxies are always shared with a large number of users and (b) it's relatively easy for a censor to check if a host:port netloc looks like a sanctioned service or a potential proxy/VPN/Tor node.

The solution you'd like

Gateway operators could optionally deploy a huge pool of reverse proxies, where each proxy would:

• Be shared by up 5 private gateways. Maybe a bit more, especially if they're shared across jurisdictions.
• Have a domain name. We need this to provision TLS certs across a wide range of CAs (some of which may not support IP addresses).
• Have one or more IP addresses supporting the domain name via TLS (E)SNI on port 443. Some of these IP addresses could be ephemeral.
• Reverse proxy all PoWeb requests from a unique, random path (e.g., https://proxy.com/<random>/v1/parcels) -- only known to the private gateways that use the proxy.
• Be able to prove to the private gateway that they belong to the expected public gateway. E.g., frankfurt.relaycorp.cloud could digitally sign a plaintext stating that proxy.com is an authorised proxy.
• If someone were to visit the website -- e.g., by going to the homepage of https://proxy.com -- they'd see an innocuous website, such as:
  • A WordPress blog, an NextCloud instance, a GitLab instance etc. We wouldn't actually be running the backend -- we'd just be serving the HTML/CSS/JS/etc to make it look legit. In the case of AJAX requests, we may have to mock those and add a random delay to make it look like the server is doing something.
  • A randomly-generated, unique website. Perhaps using ML in the future. This would probably have to be in the local language.
  • An Nginx "It works" page.

Additionally, people would have the option to purchase dedicated proxies that aren't automatically shared with anyone else, and tech-savvy people should also be given the option to "donate" existing domain names (nice to bypass an eventual block of domain names registered in the past N months). This would be particularly useful for diaspora communities trying to help their family back home.

The person provisioning the private proxy -- if different from the final user -- will be given the parameters to access the proxy using the following methods:

• A URL for Android/iOS; e.g., https://relaynet.tld#<PROXY-PARAMETERS>. When the user taps on the URL, the Android Gateway will import it.
• A file containing the parameters, to be opened on the desktop gateway.

Private proxies could be tied to specific private gateways, which could be particularly useful when sharing over insecure channels like SMS.

Collateral damage / Ethical considerations

This may "force" the censor to switch to a denylist approach or even cut the whole region from the global Internet.

Alternatives

• See Circumvent Internet censorship without external apps or services relaycorp/relayverse#4
• Instead of using reverse proxies (the approach above), use forward proxies. That way, third parties will be able to deploy proxies that work with any public gateway. However, to protect the privacy of end users, those forward proxies will have to relay cargo, not parcels -- which will undoubtedly impact performance. This binding would be called "CoProxy" and it could co-exist with PoProxy.
• Signal is doing something similar to the private proxies above, but their solution requires tech-savvy people.