Hacker News Reader

Comment by ameshkov | Hacker News Reader

No, AdGuard desktop is basically a full-scale firewall with a network driver that intercepts all network connections.

Regarding Android, this works with the help of the VPN API.

1. Android routes all IP packets to the “tun” interface

2. AdGuard reads them, passes through its own small tcp/ip stack. On one side there is the tun device, on the other side there are real sockets to the IP packets destinations.

3. App detection can be done either by reading /proc/net/tcp or, on newer Android versions, by using special getConnectionUid method.

Regarding secure connections, besides IP filtering (which AG also can do) there is always SNI scanning. Also, there’s an option to MITM connections, in this case AG generates a unique CA locally and does all the certs validation by itself.

View on HN

I read more about how AdGuard works on the website (which is what I should have done in the first place, instead of making assumptions on how it works). I’m quite impressed, especially with Android, at how much control AdGuard has over network traffic. I’m left with a few questions.

- Many apps ignore the device certificates and instead use their own certs which come installed within the app itself (to prevent MITM attacks). How does AdGuard deal with this?

- iOS is much more restrictive. Other than Safari’s content-blocking API, does AdGuard for iOS only do DNS filtering?

- I’m not surprised that apps like TikTok are using DOH to circumvent filtering, but I can’t find a source online confirming this. Could you point me to an article/repo issue/etc. which confirms this practice and lists other apps that also do this?

1. SSL pinning is not actually that widespread. However, it is used by quite popular apps - Facebook and Twitter. Unfortunately, there is no way to deal with it without patching the apps itself. Also, modern Android versions limit the trust for user certs, basically only browsers trust that type of certs. The solution would be to move the cert to the system store, but it requires root.

2. It’s not iOS that’s restrictive but Apple. We can’t even mention anywhere in the app that you can block something using DNS filtering. We’re playing this reject-phonecall-reject-appeal game for two years already and I simply have no confidence that if we bring all the functionality to iOS they allow this. Other than that it’s possible and rather easy to do, the core filtering engine is implemented in C++ and we use it on all other platforms.

3. This is from talks with filters maintainers. But yeah, this is a good topic for an article, we should write one. Thanks for the tip:)

edit: my desire for moving filtering to the server-side actually comes from the experience of communicating with different stores. Also, Chrome’s upcoming changes contribute to my paranoia. Slowly, step by step, users are losing control over their own devices and apps.

Reply on news.ycombinator.com