Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TrustTunnel: AdGuard VPN protocol goes open-source

adguard-vpn.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#31

Post by ameshkov »

vitorsr wrote: post #9
ameshkov wrote: post #6

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 s…

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.

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#32

Post by ameshkov »

userbinator wrote: post #28
stefanha wrote: post #11

Link to the protocol specification: https://github.com/TrustTunnel/TrustTunnel/blob/master/PROTO... 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!

Basically a CONNECT proxy? That's definitely not a difficult thing to write.

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#33

Post by ameshkov »

kidfiji wrote: post #29
ameshkov wrote: post #7

Earlier quoted context omitted.

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.

And AdGuard Home is a wonderful alternative to Pi-hole :)

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

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#34

Post by eptcyka »

ameshkov wrote: post #32
userbinator wrote: post #28

Earlier quoted context omitted.

Basically a CONNECT proxy? That's definitely not a difficult thing to write.

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 t…

QUIC CONNECT supports UDP too now.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#35

Post by eptcyka »

ameshkov wrote: post #30
rfv6723 wrote: post #16

Earlier quoted context omitted.

Does your team have Chinese memebers? GFW has been able to filter SNI to block https traffic for a few years now.

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…

How do you do this on iOS?

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#36

Post by eptcyka »

rfv6723 wrote: post #20
gruez wrote: post #19

Earlier quoted context omitted.

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

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

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

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#37

Post by eptcyka »

vitorsr wrote: post #9
ameshkov wrote: post #6

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 s…

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.

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

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#38

Post by ameshkov »

eptcyka wrote: post #34
ameshkov wrote: post #32

Earlier quoted context omitted.

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 t…

QUIC CONNECT supports UDP too now.

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#39

Post by ameshkov »

eptcyka wrote: post #35
ameshkov wrote: post #30

Earlier quoted context omitted.

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…

How do you do this on iOS?

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#40

Post by figmert »

ameshkov wrote: post #33
kidfiji wrote: post #29

Earlier quoted context omitted.

And AdGuard Home is a wonderful alternative to Pi-hole :)

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

Wow! Am I about to live to see the day?! I've been following the releases fairly closely, and looking forward to it.
Post reply on HN