![]() ![]() 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. 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. 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.įinally, the CA certificate may be overly trusted. Any predictability in the private key can be exploited. 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. 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. Hopefully the tool installs the certificate to the local user store, with no more access than it needs. 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. Second, any user or process with access to the private key for that local certificate can do the same. 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. 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. What security implications does this have? 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. Applications that open a direct connection without regard for system proxy settings may bypass this. 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. What layer(s) of the network does AdGuard work on? TL DR: Yes, but not a very large one if the certificate and private key are generated correctly.
0 Comments
Leave a Reply. |