Support HTTP/3

[klzgrad]

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:

{
  experimental_http3
}
:443, example.com
tls [email protected]
route {
  forward_proxy {
    basic_auth user pass
    hide_ip
    hide_via
    probe_resistance secret.com
  }
  file_server {
    root /var/www/html
  }
}

Then

google-chrome --enable-quic --quic-version=h3-29 --proxy-server=quic://example.com secret.com

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 quic-go/quic-go@c81eeb8 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.

[mholt]

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.

[sergeyfrolov]

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?

[bemasc]

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 ***@***.***> 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 ***@***.*** <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 <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABO3SPS5MYCZ3LSCOF4ASLSTKX3ZANCNFSM4SBKVH4A> .

[klzgrad]

@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?

[klzgrad]

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.

[sergeyfrolov]

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 <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJQ4S75D7SDLBWHX35QBXLS4RTHZANCNFSM4SBKVH4A> .

[klzgrad]

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.

[mholt]

Ok, great, let's try it out. Thanks!