3 ms·

> The intended use of the proxy service is to shield HTTP/HTTPS requests from eavesdropping by edge network providers such as public WiFi hotspots. Avoidance of

> The intended use of the proxy service is to shield HTTP/HTTPS requests from eavesdropping by edge network providers such as public WiFi hotspots. Avoidance of geographical restrictions on content access is explicitly not a goal. > The Mozilla extension will always make a secure request to the Cloudflare network, regardless if the request is for TLS or plaintext (From Cloudflare's privacy notice: https://www.cloudflare.com/mozilla/firefox-private-network-privacy-notice/ https://www.cloudflare.com/mozilla/firefox-private-network-p...) Now there's an interesting thought. Since the extension is routing requests at the application layer rather than at the network level, would it be possible to only route unencrypted HTTP requests through Cloudflare, while leaving encrypted HTTPS connections unaffected in order to avoid any latency penalty and save resources on Cloudflare's end? I'd love an extension/VPN app that runs silently in the background and automatically routes unencrypted requests through a private connection, while simultaneously leaving encrypted connections untouched. Maybe even have a whitelist of trusted Wi-Fi networks where the system is automatically turned off. Done right, a service like that could potentially allow users to use unencrypted Wi-Fi networks without having to worry about MITM attacks, without imposing any of the downsides that come with leaving a VPN running 24/7.

kevingadd 7y ago
The IP mismatch (unencrypted requests going through CF, encrypted through the user's connection directly) seems like it could cause trouble, though maybe in the real world most websites wouldn't care?
- Ajedi32 7y ago
  In theory it shouldn't be a problem. HTTP is supposed to be stateless, and some users will inevitably change their IP pretty frequently anyway when hopping between mobile and Wi-Fi networks so it's not like that sort of behavior is unheard of. In practice though, I have no idea. It's entirely possible there's some subset of websites making bizarre, incorrect assumptions about the relationship between users and individual IP addresses, and that dividing HTTP and HTTPS requests between different IPs could break them. If it turns out to be a problem, as a mitigation you could set it so that once you make a plaintext HTTP request to a specific domain without the response immediately redirecting to HTTPS, any future requests to that domain happen over the proxied connection for some period of time, regardless of whether those requests are HTTPS or not. That way full HTTPS sites would benefit from not needing to go through the proxy, whereas mixed content sites would not.

kevingadd 7y ago

The IP mismatch (unencrypted requests going through CF, encrypted through the user's connection directly) seems like it could cause trouble, though maybe in the real world most websites wouldn't care?

Ajedi32 7y ago
In theory it shouldn't be a problem. HTTP is supposed to be stateless, and some users will inevitably change their IP pretty frequently anyway when hopping between mobile and Wi-Fi networks so it's not like that sort of behavior is unheard of. In practice though, I have no idea. It's entirely possible there's some subset of websites making bizarre, incorrect assumptions about the relationship between users and individual IP addresses, and that dividing HTTP and HTTPS requests between different IPs could break them. If it turns out to be a problem, as a mitigation you could set it so that once you make a plaintext HTTP request to a specific domain without the response immediately redirecting to HTTPS, any future requests to that domain happen over the proxied connection for some period of time, regardless of whether those requests are HTTPS or not. That way full HTTPS sites would benefit from not needing to go through the proxy, whereas mixed content sites would not.