How does network extension transparent proxy cope with QUIC traffic?

Question

Created Jul ’20

Replies 2

Boosts 0

Participants 2

I build an app on macOS with NETransparentProxyManager to capture the TCP and UDP traffic on port 80 and 443. There is an issue baffles me.

If I create a UDP session on port 443 like following

Code Block sudo nc -ul 443

on one VM and on local macOS

Code Block nc -u remoteipofVM 443

then the NEAppProxyProvider can capture the UDP flow and data can be transferred without issues.

But if it was applied to google chrome with the QUIC traffic I can see that in the method handleNewFlow the NEAppProxyUDPFlow was captured but no datagrams could be read out.

Is this because the NETransparentProxy doesn't handle the QUIC traffic or something else?

Boost

Answer 1

Systems Engineer OP

Apple

Jul ’20

This is a topic that I have been tracking but have simply have not had the time to test out on my own. I would suspect that because QUIC is based on UDP that reading and writing streams from a flow based on QUIC would be possible but I do not exactly know. Having said that, another test you could do here is on the latest release of Big Sur, Beta 3 because it does contain experiment support for HTTP/3 Draft 28. See more here. If you do try this out please respond back and let me know how your testing went and what you uncovered so I can continue to track this.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

Systems Engineer OP

Apple

Oct ’20

I was able to do some research on this topic and did find on macOS 11 Beta 9 HTTP3 flows were being handled through a UDP flow copier as expected. I tested this with a development built copy of curl that had --http3 enabled. The draft version used between the client / server looks like it was h3-29. Upon send the curl request the Transparent Proxy I was running did successfully pick this up and proxy the flow.

I also did some preliminary testing with the experimental version of HTTP3 running on Safari and this did not produce the same results. When I tested this the flows that I believed to HTTP3 flows in Safari were being delivered as TCP flows to handleNewFlow in the Proxy. This leads me to believe that I am not producing a true HTTP3 request in Safari to determine a successful pass/fail result. I could be wrong though and would like to know if anyone else has tested this in Safari? If so, please let me know here.

Thanks.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0