[ameshkov]

Hi, I’m one of the people working on this.

One clarification that may not be obvious: open-sourcing this isn’t primarily about signaling or auditability. If that were the goal, a standalone protocol spec or a minimal reference repo would have been enough.

Instead, we’re deliberately shipping full client and server implementations because the end goal is for this to become an independent, vendor-neutral project, not something tied to AdGuard.

We want it to be usable by any VPN or proxy stack and, over time, to serve as a common baseline for stealthy transports — similar to the role xray/vless play today.

Happy to answer questions or clarify design choices.

[rfv6723]

Does your team have Chinese memebers?

GFW has been able to filter SNI to block https traffic for a few years now.

[ameshkov]

We do, and from what we know a bigger problem in China is detecting traffic patterns. SNI filtering is not that big of a deal, in order to block your domain it needs to first learn which one you’re using. What for the traffic patterns, people in China prefer to selectively route traffic to the tunnel. For instance, the client apps allow you to route *.cn domains (or any other domains) directly. It makes it harder to detect that you’re using a VPN.

[rfv6723]

In Fujian province, all foreign domains which aren't in white list are blocked.

This results that proxy server needs to use a fake sni in white list or ditch https.

[ameshkov]

This is actually supported by both the client and the server.

To use it in mobile clients you need to specify two domain names like that: fake-sni.com|domain.com where “fake-sni.com” is the domain thay will be in the SNI and “domain.com” is the domain in your TLS certificate (used to check the server’s authenticity)

[Pesevere]

I tried the method you suggested on the Android client, but it doesn't seem to work. After setting the domain name to two domains connected by `|`, the client fails to connect to the server and remains stuck in a “connecting” state.

Is this feature not yet supported on Android?

[eptcyka]

How do you do this on iOS?

[ameshkov]

You mean in TrustTunnel apps? You can create a routing profile there and select which domains/ips are bypassed, and then select that routing profile in the vpn connection settings.

[gruez]

>GFW has been able to filter SNI to block https traffic for a few years now.

SNI isn't really the threat here, because any commercial VPN is going to be blocked by IP, no need for SNI. The bigger threat is tell-tale patterns of VPN use because of TLS-in-TLS, TLS-in-SSH, or even TLS-in-any-high-entropy-stream (eg. shadowsocks).

[rfv6723]

> because any commercial VPN is going to be blocked by IP, no need for SNI.

Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

This is why GFW develops SNI filter, Cloudflare is too big to block.

[gruez]

>Proxy server can hide behind CDN like Cloudflare via websocket tunnel.

cloudflare doesn't support domain fronting so any SNI spoofing won't work.

[eptcyka]

CDN traffic is quite expensive, don’t believe it would be feasible to provide a VPN product for that. But for individuals, sure.

[vitorsr]

Thanks for all impressive work on AdGuard.

Any particular reason to adopt Rust for this project instead of Go as many of your other products?

Because I think since you have quite extensive Go codebase I would imagine you had to rewrite possibly a significant amount of code.

[ameshkov]

Performance reasons aside, TrustTunnel is developed by the team whose main language is C++ (and the client library is actually written in C++) so Rust was a more natural choice for them.

[rcoder]

Likewise interested in the authoritative answer, but: if I needed to write a decent chunk of code that had to run as close to wire/CPU limits as possible and run across popular mobile and desktop platforms I would 100% reach for Rust.

Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.

[eptcyka]

Embedding Go code into other binaries sucks ass. Debugging is worse, it installs some signal handlers.

[kumrayu]

I can't thank Adguard enough for providing so much to the community, they are a BIG part of my privacy-funded lifestyle.

Out of the topic — but if you by any chance work on the mobile apps.

Do you know why the iOS version is still sub-par compared to Android? You all add more features for rooted Android but what about Jailbroken iOS devices?

I have bought 20+ Adguard licenses and have never regretted buying them. Only if the iOS version could be much better.

[ameshkov]

Hi, thank you very much for supporting AG!

We are very cautious with Apple as we suffered from them before [1]. So we're trying to stick to the APIs they provide. I hope the new URL filtering API [2] will improve the situation with the system-wide filtering, but our request for API access is still being reviewed by Apple.

Regarding jailbroken iOS devices, unlike Android the numbers are really marginal so it won't be feasible to support them.

[1]: https://adguard.com/en/blog/adguard-pro-discontinued.html

[2]: https://adguard.com/en/blog/apple-url-filter-system-wide-fil...

[kumrayu]

Thank you so much, I also regularly read your blogs.

I am looking forward for better iOS support. :) Hope Apple can be much reasonable.

Also, what network trackers do you think are most harmful for privacy? — WebRTC, hardware fingerprinting, etags, cookies? Do you think Adguard will hone themselves much more in the future from just being an ad-blocker to evolving into an all-in-one privacy protector?

Also, I apologize for asking too many questions, I just got a bit excited when I saw you comment.

[ameshkov]

Uh, I guess it's a little bit off-topic here:) It's hard to say what's more harmful, I'd say cookies still take #1, but I think we're not far from the moment when your email address or its derivative will be used as the main advertising ID. Regarding evolution, well, definitely possible, the time will show.

[tommica]

So happy that you guys are doing this!