Security Tradeoffs: Privacy
Many different security features and products attempt to protect web browsers from malicious sites by evaluating the target site’s URL and blocking access to the site if a reputation service deems the target site malicious: for example, if the site is known to host malware, or perform phishing attacks against victims.
When a web browser directly integrates with a site reputation service, building such a feature is relatively simple: the browser introduces a “throttle” into its navigation or networking stack, whereby URLs are evaluated for their safety, and a negative result causes the browser to block the request or navigate to a warning page. For example, Google Chromeand Firefox both integrate the Google Safe Browsing service, while Microsoft Edge integrates the Microsoft Defender SmartScreen service. In this case, the privacy implications are limited — URL reputation checks might result in the security provider knowing what URLs are visited, but if you can’t trust the vendor of your web browser, your threat model has bigger (insurmountable) problems.
However, beyond direct integration into a browser, there are other architectures.
For example, you might install a security addon (like Microsoft Defender for
Chromeor Netcraft) into your browser. In that case, the security addon can collect navigating/downloading URL using the browser’s extension API events and perform its task as if its functionality was directly integrated into the browser.
In the loosest coupling, a security provider might not integrate into a web browser or client directly at all, instead providing its security at another architectural layer. For example, a provider might watch unencrypted outbound DNSlookups from the PC and block the resolution of hostnames which are known to be malicious. Or, a provider might watch network connections to an outbound site and block connections where the URL or hostname is known to be malicious. This sort of inspection might be achieved by altering the OS networking stack, or plugging into an OS firewall or similar layer.
The decision of where to integrate security software is a tradeoff between context and generality. The higher you are in the stack, the more context you have (e.g. you may wish to only check URLs for “active” content while ignoring images), while the lower you are in the stack, the more general your solution is (it is less likely to be inadvertently bypassed).
The advantage of integrating security software deep in the OS networking layer is that it can then protect any clients that use the OS networking stack, even if those clients aren’t widely known, and even if the client was written long after your security software was developed. By way of example, Microsoft Defender’s Network Protectionand Web Content Filtering features rely upon the Windows Filtering Platform to inspect and block network connections.
For unencrypted HTTP requests, inspecting traffic at the network layer is easy — the URL is found directly in the headers on the outbound request, and because the HTTP traffic is unencrypted plaintext, parsing it is trivial. Unfortunately for security vendors, the story for encrypted HTTPS traffic is much more complicated — the whole point of HTTPS is to prevent a network intermediary (including a firewall, even on the same machine) from being able to read the traffic, including the URL.
To spy on HTTPS from the networking level, a security vendor might reconfigure clients to leak encryption keys, or it might rely on a longstanding limitation in HTTPS to sniff the hostname from the Client Hello message that is sent when the client is setting up the encrypted HTTPS channel with the server.
Security products based on sniffing network traffic ( DNSor server connections) are increasingly encountering a sea change: web browser vendors are concerned about improving privacy, and have introduced a number of features to further constrain the ability of a network observer to view what the browser is doing. For example, DNS -over-HTTPS (DoH) means that browsers will no longer send unencrypted hostnames to the DNS server when performing lookups, and a new feature called Encrypted Client Hello (ECH) means that browsers can no longer spy on the first few packets of a TLS connection to see what server hostname was requested. Both Chromium and Firefox have recently enabled support for ECH . Notably, both DoH and ECH are presently disabled-by-default in Chrome, Edge , and Firefox for “managed” devices. A test site for ECH can be used to see whether your browser is using ECH .
Blinded by these privacy changes, a security product running at the network level must fall back to only IP reputation, which suffers many challenges.
Unfortunately, this is a direct tradeoff between security and privacy: security products that aren’t directly integrated into browsers cannot perform their function, but disabling those privacy improvements means that a network-based observer could learn more about what sites users are visiting.
Browsers offer policies to allow network administrators to make their own tradeoffs by disabling security-software-blinding privacy changes.
DNS-over-HTTPS (already disabled by default on “Managed” devices)
Encrypted Client Hello(currently, ECH on Windows and Linux requires DoH aka “Secure DNS”; testing shows that ECH can be used on Mac when DoH is off.)
QUIC ( HTTP3products that only support HTTPS-over-TCP/IP cannot analyze QUIC traffic)
Stay safe out there!
PS: It’s worth understanding the threat scenario here– In this scenario, the network security component inspecting traffic is looking at content from a legitimate application, not from malware. Malware can easily avoid inspection when communicating with its command-and-control (C2) servers by using non-HTTPS protocols, or by routing its traffic through proxies or other communication channel platforms like Telegram , Cloudflare tunnels, or the like.
PPS: Integrating into the browser itself may also be necessary to block sites in situations where a site doesn’t require the network in order to load.
PPPS: Sniffing the SNI is additionally challenging in twoother cases: 1 ) If the browser uses QUIC, the HTTP/3 traffic isn’t going over a traditional TLS -over-TCP channel at all, and 2 ) If the browser uses H/2 Connection coalescing, the browser might reuse a given HTTPS stream across multiple different origins.