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

51–60 of 69 posts

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#51

Post by ameshkov »

rfv6723 wrote: post #43
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…

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.

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)

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#52

Post by dmantis »

GardenLetter27 wrote: post #50

So what are the reasons to use this over Wireguard?

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#53

Post by tommica »

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…

So happy that you guys are doing this!

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#54

Post by kumrayu »

ameshkov wrote: post #47
kumrayu wrote: post #46

Earlier quoted context omitted.

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

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…

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#55

Post by ameshkov »

kumrayu wrote: post #54
ameshkov wrote: post #47

Earlier quoted context omitted.

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…

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

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#56

Post by pandemic_region »

ameshkov wrote: post #49
DrBurrito wrote: post #48

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

There are no shady alleys in Cyprus:) 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…

> https://adfilteringdevsummit.com/

Google sponsoring this summit is peak irony.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#57

Post by eptcyka »

ameshkov wrote: post #38
eptcyka wrote: post #34

Earlier quoted context omitted.

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

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.

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#58

Post by ameshkov »

pandemic_region wrote: post #56
ameshkov wrote: post #49

Earlier quoted context omitted.

There are no shady alleys in Cyprus:) 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…

> https://adfilteringdevsummit.com/ Google sponsoring this summit is peak irony.

Well, Google is like a small country and some parts of it are very good guys that are genuinely interested in being a "user agent".

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#59

Post by xtacy »

ameshkov wrote: post #38
eptcyka wrote: post #34

Earlier quoted context omitted.

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

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

Re: TrustTunnel: AdGuard VPN protocol goes open-source

#60

Post by ameshkov »

eptcyka wrote: post #57
ameshkov wrote: post #38

Earlier quoted context omitted.

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

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.

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.
Post reply on HN