[Proposal] Rust-based QUIC Pluggable Transport(UAT)

Support Censorship Circumvention
1

To increase the options for Bridges and achieve better performance than existing TCP-based transports, I have developed a new Pluggable Transport based on QUIC.

Why QUIC?
Current TCP-based transports (like Obfs4 or WebTunnel) suffer from Head-of-Line blocking, especially in censorship environments with high packet loss. By using QUIC (UDP), this PT aims to provide faster connection establishment and more stable throughput.

Technical Details:

Language: I am implementing everything in Rust with Arti in mind.

Mechanism: It mimics standard HTTP/3 traffic.

Current status: It functions as a bridge and has been confirmed to connect successfully. However, it is still in the early development stage (alpha version), and formal benchmark measurements or long-term stability checks have not been performed.

Repository: [ GitHub - yo-4m/UAT: UDP Adaptive Transport for Tor ]

Please feel free to share any feedback on the design and implementation, or any other ideas you may have.
Check out the repository for more details!

1 Like
2

Cool! So it looks like visiting a website in your browser, but it’s routed via UDP = QUIC.. But would blocking QUIC cause collateral damage for censors?

Is your main goal:

  1. adding another bridge pluggable transport as an option
  2. making it censorship resistant
  3. or increase the speed of Tor bridges with this protocol-type?

About the anti-censorship side, would it be better than the UDP-based protocol AmneziaWG?

Ok, those are probably all my questions for now.

Tor’s anti-censorship team meets on Thursday at 16:00 UTC via IRC, there is an option to join by .onion (IRC), afaik, more details in the link, so if you’d like to present and ask questions to the Tor Project’s anti-censorship team about your pluggable transport, then you’re welcome. Or you can create an account on the Tor Project’s GitLab for better collaboration, there you can create an issue somewhere in the anti-censorship category. Because implementing pluggable transports requires some work, I think, it’s better to ask the devs, yeah.

You can request a GitLab account for the Tor Project instance of it here.

3

Thanks for the reply!!

First, my primary goal at this point is #1: “Add another bridge plugin-type transport.”
This is because I believe that increasing the number of bridge options, rather than relying on a small number of bridges, will lead to #2: “making it censorship resistant"Regarding “Does blocking QUIC inflict collateral damage on censors?”, there’s still room for consideration. However, compared to AmneziaWG, one advantage of QUIC is that while AmneziaWG employs obfuscation, QUIC is also used by common web services. This allows it to better mimic the behavior of a typical web service.
Regarding “increase the speed of Tor bridges with this protocol-type,” we won’t know until we actually test it. However, there was a paper that reported higher benchmarks than existing Tor when implementing Tor itself using QUIC, so I believe we can expect speed improvements for Bridges as well.

Thanks for the detailed info about the meeting too!
I’m not very confident in English, but I’ll do my best with GitLab and everything else!

4

In Russia the DPI seems to look at some initial QUIC SNI and block it or something.

https://ntc.party/t/ограничение-http3-quic/1823

AmneziaWG deploys a slightly different configuration for each user so there wasn’t any one thing the censor can block, because it looks like a call.

Let’s hear what the Tor devs think about this.

Cool, good luck!

5

Thanks for you contribution! I have got a look at the code and has the following observations:

Speed

As I understood, when using QUIC for improved transfer throughput, it is often necessary to patch the library and rewrite some part of the library, as the original developer might not be as invested with high packet loss network environment. There is an open issue about it: Transfer rate / congestion control issues · Issue #1372 · quinn-rs/quinn · GitHub In golang space, the quic library also have a similar issue: implement BBRv3 · Issue #4565 · quic-go/quic-go · GitHub Overall, while using UDP based transfer protocol does give engineers more control over the exact protocol details than TCP, how well this potential is realized still depends on execution.

As for UDP itself, which QUIC is based on, can receive higher restriction than UDP. Let’s say in some (small) carrier (in at least China) may throttle it to make as slow as only dns, and ntp would work. This is also the reason why GitHub - wangyu-/udp2raw: A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment) exists.

Overall speed wise, a QUIC based protocol can works better than TCP, but it does requires some engineering effort to make it so. It is really important to be prepared for such effort.

Censorship Resistant

Quic’s encryption design works very similar to TLS. As a result, it can be fingerprinted in the same way, as well as get SNI extracted. So in general it would work as well as any tls based proxies.

Implementation Details

There are 2 details worth pointing out:

The first is about certificate, an active attacker could detect if an self-signed certificate is used in a QUIC configuration, so it is important to use an WebPKI certificate or at least pin the certificate. It is worth doing so early to make sure these options are supported by the library.

The second is about Rust. I am not am expert on Rust, however I think that is good choice overall since we are, in longer term, considering to move to a rust based pluggable transport system. That being said, we don’t have an existing Rust Pluggabe Transport pipeline yet, so it could take sometime before any rust based pluggable transport can be bundled in the mobile version of the tor browser. This is super true as Tor’s shippable mobile app is reaching its limit, bundling additional binary would incur engineering effort from other teams, which can be really slow, (in the worst case at the scale of years).

6

Hello, user from Russia here. This is very old information; Quic has been working and unblocked for at least several years now. Although some mobile internet providers slow down Quic traffic, it’s unlikely that this will significantly impact Quic (up to 256kbps). It’s likely that as Quic becomes more widely adopted online, blockages will become less frequent.

7

Ok, thanks for mentioning that!