Closed klzgrad closed 3 years ago
Cool, thanks for the PR! I think this is worth a shot. But @sergeyfrolov would have a chance to chime in, I think he'll have a better understanding of the privacy/probe-resistance implications.
Thanks for the PR @klzgrad! Too bad Google Chrome does not allow QUIC proxying at this time. Do you have a link to your client?
@mholt this PR does not seem to impact the probe-resistance. However, I could imagine that using traffic analysis to detect the use of proxy with QUIC could be slightly more accurate than with HTTP/2. We should still proceed with the optional QUIC proxying, if we can, because it should provide a noticeable performance boost.
I am curious if our friends at Google (@bemasc @fortuna @dalyk) are interested in QUIC proxying, in particular, with Google Chrome as a client?
My understanding is that Chrome does support using HTTP CONNECT over QUIC. I don't see any reason to disable that combination on Caddy's end.
On Sat, Dec 5, 2020, 5:29 PM Sergey Frolov notifications@github.com wrote:
Thanks for the PR @klzgrad https://github.com/klzgrad! Too bad Google Chrome does not allow QUIC proxying at this time. Do you have a link to your client?
@mholt https://github.com/mholt this PR does not seem to impact the probe-resistance. However, I could imagine that using traffic analysis to detect the use of proxy with QUIC could be slightly more accurate than with HTTP/2. We should still proceed with the optional QUIC proxying, if we can, because it should provide a noticeable performance boost.
I am curious if our friends at Google (@bemasc https://github.com/bemasc @fortuna https://github.com/fortuna @dalyk https://github.com/dalyk) are interested in QUIC proxying, in particular, with Google Chrome as a client?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caddyserver/forwardproxy/pull/80#issuecomment-739424857, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABO3SPS5MYCZ3LSCOF4ASLSTKX3ZANCNFSM4SBKVH4A .
@sergeyfrolov https://github.com/klzgrad/naiveproxy It's essentially a minimized Chromium net stack, so I can turn QUIC proxy support back on.
using traffic analysis to detect the use of proxy with QUIC could be slightly more accurate than with HTTP/2
Can you explain why this is the case?
Right there is a report of website fingerprinting of QUIC without padding https://arxiv.org/abs/2101.11871, but I don't get why QUIC is slightly more prone to traffic classification than HTTP/2.
Just wanted to mention some recent research on this subject. This twitter thread gives a link and a summary: https://twitter.com/nikitab/status/1374825008334303234?s=19
On Sat, Jan 30, 2021, 13:24 klzgrad @.***> wrote:
Right there is a report of website fingerprinting of QUIC without padding https://arxiv.org/abs/2101.11871, but I don't get why QUIC is slightly more prone to traffic classification than HTTP/2.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caddyserver/forwardproxy/pull/80#issuecomment-770275514, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJQ4S75D7SDLBWHX35QBXLS4RTHZANCNFSM4SBKVH4A .
It's expected for unpadded QUIC traffic to be fingerprinted on the same level of accuracy as HTTP/2 as they are both designed to have minimal delay so there's little room for the packet pattern to change.
Ok, great, let's try it out. Thanks!
Though the patch is small it's not easy to test it because the pieces for H/3 have yet to fall in place.
First build Caddy with this PR. Then Caddyfile:
Then
which prompts for password. After that you should be able to open http://example.com. Caddy should print a message like this:
2020/10/02 01:23:45.678 ERROR http.log.error Proxy-Authorization is required! Expected format: <type> <credentials>{"request": {"remote_addr": "1.2.3.4:5678", "proto": "HTTP/3", "method": "GET", "host": "secret.com", "uri": "/", "headers": {"Upgrade-Insecure-Requests": ["1"], "User-Agent": ["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36"], "Accept": ["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"], "Accept-Encoding": ["gzip, deflate"], "Accept-Language": ["en-US,en;q=0.9"]}, "tls": {"resumed": false, "version": 0, "cipher_suite": 0, "proto": "", "proto_mutual": false, "server_name": ""}}, "duration": 0.000106268}
I have a patch with quic-go v.0.18.0 https://github.com/lucas-clemente/quic-go/commit/c81eeb8bb855eeba6df52660efd99be6d74e6c87 to enable the CONNECT method. But Chrome has disabled QUIC proxying for any https origins and I haven't found the right parameters to turn it back on for this test. But my other customized proxy tool based on Chrome stack does work with HTTP/3 CONNECT in Caddy. This should make sense because the test above already shows GET requests get proxied correctly.