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

[4i_un]

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!

[unic3rn]

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.

[4i_un]

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!

[unic3rn]

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.

@4i_un

I’m not very confident in English, but I’ll do my best with GitLab and everything else!

Cool, good luck!

[Shelikhoo]

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).

[Preetor681]

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.

[unic3rn]

Ok, thanks for mentioning that!

[4i_un]

Thank you for your reply. My real life has been a bit busy lately, so I couldn’t respond, but things have settled down now, so I’m back.

First, thank you for the advice on the overall implementation. Regarding the technical effort (simply me pushing forward with the work), since I’m constantly thinking about Tor and privacy in my daily life, that part is not an issue. I’m prepared to see it through no matter what, even if it takes years to reach the goal.

Regarding your points, you’re absolutely right—the current implementation has issues with certificates. I’m using the Quinn library, and it seems possible to pin certificates. I’m leaning towards pinning them for now, but I want to explore this issue a bit more.

Next, regarding the pipeline issue—is there anything I can do about this? I’ve never been involved in the Tor development community before. Can I personally create issues or PRs on my own?

If it’s possible, I’ll try my best to build the pipeline too. I want to finish what I’ve started as much as possible.

[4i_un]

Hello, everyone

Just posting a quick update on recent progress

・Certificate issues

One current challenge is certificate-related problems. The proposed solutions are either certificate pinning or using WebPKI. For now,
I have adopted the proposal to pinning the certificate.

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

The reason is that WebPKI imposes very high costs on Bridge operators (certificate issuance, domain acquisition, etc.).

However, WebPKI is undoubtedly better for censorship resistance, so I’d like to hear everyone’s thoughts on this point.

Also, after posting here, I found this:

GitHub - ahf/quic-pt: Quic Pluggable Transport for Tor.

I also learned the creator is a Tor core developer.

This implementation is labeled experimental, but it’s from 9 years ago, and QUIC-PT isn’t bundled in Tor Browser yet.

Why wasn’t his implementation bundled in Tor Browser?

I emailed him, but Tor core developers apparently take weekends off, so I haven’t gotten a reply yet. (He’s probably busy too.)

[unic3rn]

@4i_un

The reason is that WebPKI imposes very high costs on Bridge operators (certificate issuance, domain acquisition, etc.).

However, WebPKI is undoubtedly better for censorship resistance, so I’d like to hear everyone’s thoughts on this point.

So the difference is that one works with real domain names and the other one - doesn’t-?

@4i_un

Also, after posting here, I found this:

Is that solution similar to yours?

[4i_un]

@unic3rn

So the difference is that one works with real domain names and the other one - doesn’t-?

Yes, that’s generally correct.
By fronting the bridge with a legitimate website on an actual domain, and using standard certificates (like Let’s Encrypt), the traffic becomes indistinguishable from visiting a regular QUIC-enabled website.

Regarding my current approach:

My implementation currently uses self-signed certificates with certificate pinning. This keeps the entry barrier low for operators, incurring essentially no costs beyond hardware. However, active censors may actually access the Bridge address and detect the self-signed certificate. This may appear suspicious compared to standard web servers.

@unic3rn

Is that solution similar to yours?

There are differences in languages and libraries used, and whether or not the one-session-one-stream problem exists, but his approach is basically almost identical to mine.

[Shelikhoo]

@4i_un

Next, regarding the pipeline issue—is there anything I can do about this? I’ve never been involved in the Tor development community before. Can I personally create issues or PRs on my own?

Thanks! You are more than welcome to open a ticket at Sign in · GitLab to discuss options about adding add Rust based pluggable transport to Tor Browser.

Like WebTunnel pluggable transport, it should be possible to support both WebPKI and certificate pinning at the same time. That being said I agree that we can start with certificate pinning.

Why wasn’t his implementation bundled in Tor Browser?

I think there are many prototype projects created by Tor’s members, and many of them won’t be included in Tor browser either because either the prototype did not work as well as intended, or there is insufficient energy for the long term maintenance of the project. You might wants to contact this author about the lesson learnt from the experiment.

[gus]

Hi @4i_un!

I tried to run your project following the GitHub instructions, but it didn’t work.

docker:

curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip 
curl: (97) Recv failure: Connection reset by peer

Thank you!

[4i_un]

I created a repository and an issue on GitLab!

Please check it out.

repository

41_un / UAT · GitLab

issue

Issues · The Tor Project / Anti-censorship / Pluggable Transports / pluggable...

[4i_un]

Oh… I see. Thank you for reporting the bug.
I had previously confirmed it worked correctly here, but it might be due to some recent implementations like certificate pinning.
Since I just uploaded it to GitLab the other day, I’ll work on fixing the bug.