I wish we finish with redesigning it nicely this year and finally after all those years we will finally call it v1.0
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.
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.
Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.
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).
Proxy server can hide behind CDN like Cloudflare via websocket tunnel.
This is why GFW develops SNI filter, Cloudflare is too big to block.
cloudflare doesn't support domain fronting so any SNI spoofing won't work.
This results that proxy server needs to use a fake sni in white list or ditch https.
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)
Is this feature not yet supported on Android?
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.
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...
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.
I need to open ssh myself and for now I decided on tunnelling over http/3 terminated somewhere in aws/gcp/cf, but maybe your method is better.
Besides, where's fun in it :)
It won't help you get around the endpoint compliance software, I use this for my byod phone (Streisand is a nice ios client). VLESS is the proxy protocol, kinda like SOCKS I guess. It uses xhttp over TLS as the transport.
It's less about breaking the rules, more about getting around the limitations in case I need it and don't fancy waiting 2 days for approval. Might end up with pure http/3, but this tool is fascinating. Thanks!
It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.
It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!
When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.
And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.
We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.
Curious: in your experience where does QUIC work bad/slow?
I can understand that put UDP payload into a single HTTP stream, at least when QUIC transport is in use, there is no UDP in TCP case.
The Source Address/Port in the UDP payload message serve as key to handle to the tunnel client if I understand correctly?
Update: just followed the quickstart and worked great; speed is virtually line speed - impressive!
that the protocol was not open was one of my main issues for not using the vpn service,?it is great to see. i look forward for the upcoming audits.
one thing i would like to see more is info about the company. the team, the offices, etc. there have been rumors and contradictory infos over the years, and the blog always have a “stock photo”, shady vibe. putting your address in google maps brings you to a shady alley… improving the image of the company (in my opinion) as it is now would do lots to create and improve trust.
We have only one office in Limassol, the company is mostly remote: https://maps.app.goo.gl/pounSEQqBvYftZGZ6?g_st=ic
(we are moving to a bit bigger office in the neighboring building, no nice photos on google yet)
We do not have a dedicated team page on the website, but we’re not hiding our faces, the team can be found on Github. Members of the team often visit AFDS [1] [2], you can see some faces there (including mine).
[1]: https://adfilteringdevsummit.com/
[2]: https://youtube.com/playlist?list=PL61EKVIQWizG0tIYqNDoenVaO...
Google sponsoring this summit is peak irony.
The soluton in the post for VPNs as in "censorship bypass", not as in "virtual lan over the internet for businesses". Like AmneziaWG or VLESS protocols.
sillyfluke•2w ago
ameshkov•2w ago
sillyfluke•2w ago