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!
just did some spec reading, it's quite clear and nit.
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?
userbinator 3 days ago [-]
Basically a CONNECT proxy? That's definitely not a difficult thing to write.
ameshkov 3 days ago [-]
More or less, built on top of it with added udp/icmp.
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.
eptcyka 3 days ago [-]
QUIC CONNECT supports UDP too now.
ameshkov 3 days ago [-]
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.
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.
eptcyka 2 days ago [-]
Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
ameshkov 2 days ago [-]
Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.
eptcyka 2 days ago [-]
Unfortunately, I am no stranger to embedding a whole userspace networking stack into a VPN client either.
xtacy 2 days ago [-]
> QUIC is not bad, but there are places where it either does not work at all or works too slow.
Curious: in your experience where does QUIC work bad/slow?
ameshkov 2 days ago [-]
For example, in some countries it's either slowed down or outright blocked.
mrbluecoat 3 days ago [-]
Very cool! Thanks for supporting open source (unlike a half-hearted attempt, like ExpressVPN's Lightway). Quick question: the website animated gif has no arrows from the website to the VPN server. Am I missing something?
Update: just followed the quickstart and worked great; speed is virtually line speed - impressive!
ameshkov 3 days ago [-]
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 3 days ago [-]
Does your team have Chinese memebers?
GFW has been able to filter SNI to block https traffic for a few years now.
ameshkov 3 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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 17 hours ago [-]
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 3 days ago [-]
How do you do this on iOS?
ameshkov 3 days ago [-]
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 3 days ago [-]
>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 3 days ago [-]
> 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 3 days ago [-]
>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 3 days ago [-]
CDN traffic is quite expensive, don’t believe it would be feasible to provide a VPN product for that. But for individuals, sure.
vitorsr 3 days ago [-]
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 3 days ago [-]
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 3 days ago [-]
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 3 days ago [-]
Embedding Go code into other binaries sucks ass. Debugging is worse, it installs some signal handlers.
kumrayu 2 days ago [-]
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 2 days ago [-]
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.
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 2 days ago [-]
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 2 days ago [-]
So happy that you guys are doing this!
DrBurrito 2 days ago [-]
I like and use your products, so, first of all, thank you!
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 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).
In Cyprus, companies are usually incorporated via a corporate service provider, who also provides the registered office address and PO Box services. Basically, if you need to reach out to us by mail, you should use the "legal address" from the website.
Sir_Burpalot 1 days ago [-]
Does anyone know if this protocol uses QUIC's RFC 9221 extension in order to eliminate overhead when tunnelling UDP over QUIC? According to their blog post, TrustTunnel does somehow avoid that overhead, but the actual protocol specification doesn't mention anything of that sort.
ameshkov 1 days ago [-]
No, but it's a very good point, we'll add it to the backlog
Sir_Burpalot 1 days ago [-]
Excellent, thanks for the quick response! Are there any plans to add support for full-cone NAT as well, in order to improve compatibility with some games?
denkmoon 3 days ago [-]
What makes this worth using over something like vless? Work blocked my gatcha game so I've had to set up a xray/vless/xhttp/tls proxy and it works flawlessly. Gets through the corp firewall unscathed at full bandwidth and no appreciable increase in latency.
subscribed 3 days ago [-]
Could you please drop names/links to the magic sauce if there's anything more than the names mentioned?
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.
dfadsadsf 3 days ago [-]
Just use Amnezia VPN - it can masquerade as https.
subscribed 3 days ago [-]
I can't, my endpoint runs software enforcing compliance. "no disallowed VPN software" is one of the rules.
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.
subscribed 2 days ago [-]
Thanks a lot. VPNs are forbidden but this might easily slip under the radar (I can even check the signatures on the endpoint protection and our office firewall :))
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!
reader9274 3 days ago [-]
How does this compare to Obscura
mrbluecoat 3 days ago [-]
Obscura is WireGuard-over-QUIC, not a new protocol.
It’s great for you to open source the protocol and implementation, it written in rust which I will definitely consider to learn it add add to my vpn client in the future
nfgrep 3 days ago [-]
Super cool stuff! Excited to see what p2p between clients might look like, and how it compares on speed with Wireguard.
GardenLetter27 2 days ago [-]
So what are the reasons to use this over Wireguard?
dmantis 2 days ago [-]
Standard wireguard is blocked by DPI in Russia, China, Iran, etc.
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.
almaight 3 days ago [-]
Does it support the mwss protocol?
3 days ago [-]
zx8080 3 days ago [-]
I'm surprised that the browser extension to block ads has a proprietary vpn-like protocol. WTF?
ameshkov 3 days ago [-]
One interesting thing I’ve noticed is that AdGuard means different things in different parts of the world. In some places, people know us primarily as an ad blocker, in others we’re best known for our DNS service and in some regions AdGuard is associated almost exclusively with our VPN. The reality is that AdGuard makes several different products, not just one.
0x1ch 3 days ago [-]
I'm an American. I knew about the VPN service, but mostly associate your brand with the DNS services and lists you provide (thank you!).
kidfiji 3 days ago [-]
And AdGuard Home is a wonderful alternative to Pi-hole :)
ameshkov 3 days ago [-]
Yay, thank you! :)
I wish we finish with redesigning it nicely this year and finally after all those years we will finally call it v1.0
figmert 3 days ago [-]
Wow! Am I about to live to see the day?! I've been following the releases fairly closely, and looking forward to it.
jabroni_salad 3 days ago [-]
One of my first experiences with adguard was using it to block ads on an unrooted phone. It pipes your connection through a local vpn to do it.
huflungdung 3 days ago [-]
[dead]
sillyfluke 3 days ago [-]
It would be also nice if they could hold their implicit promise of having the AdGuard extension working on Safari iOS, it's broken for me even when I reinstal it. Anyone else have the same problem?
ameshkov 3 days ago [-]
This is not a common issue tbh. What sometimes may happen is that after an iOS update the content blockers in Safari becomes corrupted and the only thing that fixes it is not just a reinstall, but uninstall + reboot + reinstall after that. If even this doesn’t help please contact me at “am at adguard.com”, I will try to help.
sillyfluke 3 days ago [-]
Thanks for the suggestion! I'll definitely try the uninstall-reboot-reinstall flow. I was about to switch browsers on all the elderly devices.
Rendered at 20:11:49 GMT+0000 (Coordinated Universal Time) with Vercel.
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!
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?
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?
Update: just followed the quickstart and worked great; speed is virtually line speed - impressive!
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.
GFW has been able to filter SNI to block https traffic for a few years now.
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?
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.
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.
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.
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.
https://adguard.com/en/contacts.html
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!
https://obscura.net/#faq-technical
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.
I wish we finish with redesigning it nicely this year and finally after all those years we will finally call it v1.0