11–20 of 69 posts
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!
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.
Go has a lot of strengths, but embedding performance-critical code as a shared library in a mobile app isn't among them.
I'm surprised that the browser extension to block ads has a proprietary vpn-like protocol. WTF?
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.
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.
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.
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…
GFW has been able to filter SNI to block https traffic for a few years now.
Update: just followed the quickstart and worked great; speed is virtually line speed - impressive!
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.
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.
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…
Does your team have Chinese memebers? 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).
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.
>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.