No, really, HTTP and SOCKS proxies cannot carry QUIC traffic, so browsers don't even try. They just send it right through.
If you block UDP, I guess I can still try DNS for exfil. HTTP proxies don't support DNS, and browsers need to be explicitly configured to proxy DNS through SOCKS, if the SOCKS proxy even supports it. Chances are, DNS exfil will work.
Now, if you were to do what I do to disable network access, then I'd have no chance: network namespace in a jail with zero network interfaces (not even loopback).
I'm going to need a bug tracker link for that, it seems to dumb to be true. Surely they would just not use HTTP/3 if they can't do it through the configured proxy. I wouldn't bet my life on it though, I have seen dumber bugs.
edit: tested this the old-fashioned way with Firefox 116.0.3 on Ubuntu and nginx 1.25.1. Firefox does connect over HTTP 3 and CORRECTLY DOESN'T CONNECT AT ALL with a (bad) proxy configured. You are spreading FUD.
My Chrome 115.0.5790.170 doesn't seem to use HTTP 3 at all.
> Surely they would just not use HTTP/3 if they can't do it through the configured proxy.
That's what I thought, at first. But, back when Chrome introduced QUIC, this was a known phenomenon in proxy-restricted but not-UDP restricted setups. I doubt I'd be able to find a bug report for it, given Google's nature, but there's a few reports[1][2][3] by proxy vendors asking for QUIC to be disabled or traffic will go through, even when Chrome is configured to use a proxy.
And here's[4] a user report with the same observation, with Chrome connecting directly to its mothership without going through the configured proxy. The user reports successful blocking upon disabling QUIC
I assure you, I had no such intention. I was just reporting from memory, of years ago, back when I was in college and had to deal with a proxy-restricted network, and QUIC was being rolled out.
> My Chrome 115.0.5790.170 doesn't seem to use HTTP 3 at all.
Maybe your Chrome has HTTP/3 blocked for some reason. Or, more likely, Chrome supports a different draft of the HTTP/3 spec than the server you're testing against. It has a history of doing that too.
Your links point to people and services using intercepting proxies, not configuring one in their browsers. Techniques intercepting TCP traffic and redirecting it to a proxy will not work when the traffic is UDP. This is not a browser issue.
In this thread we were talking about the user willingly configuring a proxy in the browser or OS.
> Your links point to people and services using intercepting proxies, not configuring one in their browsers.
Sorry, I didn't look too closely through any of those links, because I never used those specific products myself.
But I do clearly remember this being an issue for me back in the day. So I dug further. You'll be happy to see this bug report[1] and this commit[2]. Note these words from a Chromium dev: "This code was written when we discovered a problem with QUIC bypassing proxies."
Thanks! This is scary, however you'll agree that a bug on Chrome closed 6 years ago is a far cry from your claim that "HTTP and SOCKS proxies cannot carry QUIC traffic, so browsers don't even try. They just send it right through" present tense. Still thank you for finding this reference, it is a sign that setting a proxy in your system is not as secure as a firewall/netns.
Yeah, I agree. I should've checked the validity before posting it, instead of just going by memory from years ago.
> ... finding this reference ...
It was a lot more effort than I'd have liked to put into my original comment, but hey, I was ticked off by your accusation of spreading FUD. Also didn't help that search engines today aren't what they used to be.
Does this absolutely prevent a page from saving information, eg local stiarge, and later transmitting it when you either visit the site or a Web page where it is iframed?
1. starts by suggesting devTools, which is simple, elegant, and wrong.
2. improves by suggesting the "Work Offline" menu option of the File menu, which is hidden by default on both Windows and Linux, and also wrong.
3. improves to a state of minimal functionality with implicitly ordered steps to use Private Browsing, Offline Mode, and confidential file "upload." And, I guess, always remembering to close all private browsing windows upon completion?
I'll rankly speculate f this ever caught on, 25% of users will forget to check offline mode until after they have finished editing their confidential document, 40% will leave a stray Private Browsing window open at all times, 10% will accidentally continue doing all their browsing in the same Private Browsing window, and 1% will somehow paste their private GPG keys in the query string of the URL.
Not just browsers. (Other) Native apps have the same problem. For some reason we have elaborate permissions for all sorts of things but nothing remotely user friendly for various kinds of network activity.
Little Snitch and Lulu on Mac are reasonably user friendly. I am pretty sure there are equivalents on Linux, though not entirely certain about Windows.
Having to find and install separate firewall software is exactly what I mean by not remotely user friendly, regardless of how relatively user friendly any particular firewall may be.
Why can I not simply disable network access in the app settings? Why am I not being asked to grant this permission just like I'm asked to grant access to my photos?
Permissions systems on desktop platforms are mostly useless for regular users and only somewhat less useless on mobile.
