Is it a risk to allow security or privacy apps to install a certificate and filter HTTPS?

Question

I recently installed the AdGuard app on Windows and Android. It wants to enable HTTPS filtering and install a certificate. I've seen antivirus do similar things. How exactly does this work and what security implications does this have? I'm guessing it's a compromise, but if the app wanted to do something malicious it would have no trouble if it's already running locally (plus AdGuard is open source). What layer(s) of the network does AdGuard work on? Clearly it doesn't just modify the host file for example.

Answer 1

You correctly said that the risk is not the application being naughty with that particular feature, as you already gave it more that enough ways to harm you.

A way the proxy (what it is) could lower your security in an unexpected way is by not being as good as a browser and having a vulnerability that could be exploited while connecting to a hostile server. The main browsers have extremely good security teams that do a lot of preventive work but also monitor crash dumps etc for active exploitation. They also have pretty good processes to push fixes to customers quickly.

Do you trust AdGuard to be that good? Browsers did a lot of work to sandbox their Javascript engines, did AdGuard?

Answer 2

TL;DR: Yes, but not a very large one if the certificate and private key are generated correctly.

What layer(s) of the network does AdGuard work on?

Typically, programs like this act as an HTTPS proxy, configuring the system and specific-browser proxy settings to route through a listener that they control, at which the proxy can generate (locally) trusted certificates for any site. Applications that open a direct connection without regard for system proxy settings may bypass this. It could also be implemented as a network tap or tunnel (such as how many VPNs work), routing the inbound and outbound network traffic to a local process (essentially an invisible proxy) which then bypasses the tap/tunnel to relay the (possibly modified) traffic to its destination.

what security implications does this have?

Several. First, the process that installed the certificate can monitor and modify all HTTPS network traffic for your machine, unless certificate or public key pinning is used (a very small number of sites, mostly things like key Google services and Windows Update servers, are "pinned" in their common clients such that they won't accept unexpected certificates even if that cert would normally be trusted. There was an attempt to define a way for arbitrary sites to pin their own certs, but it is deprecated and not supported by most clients.

Second, any user or process with access to the private key for that local certificate can do the same. This can potentially be far more than you expect, since by default all processes running as a given user (unless sandboxed) can access that user's trusted CA and private keys store, and all processes running as any user on the machine can access the system CA and private key stores. Hopefully the tool installs the certificate to the local user store, with no more access than it needs.

Third, the public/private key pair in the certificate might not be unique, and might even be the same across machines and/or based on weak entropy sources that are predictable. The only safe way to do this is to generate the key pair locally, using a cryptographically secure random number generator, and then destroy any interim data. Any predictability in the private key can be exploited. Any re-use of private keys across machines - which has happened - means an attacker with access to any of those machines now can successfully man-in-the-middle TLS (including HTTPS) connections for any other such machine.

Finally, the CA certificate may be overly trusted. If it's usable for signing emails and code, as well as certificates, that's another potential risk; an attacker with the private key could not only MitM TLS connections, but also bypass code signing restrictions and potentially make other attacks. Furthermore, if the leaf certificates generated for individual sites are trusted for anything other than authenticating the TLS connection, then an attacker who got the private key to one of them could also e.g. generate maliciously signed binaries, or potentially generate their own trusted certificates for arbitrary sites.