Security Tradeoffs: Privacy

Created on November 12, 2023 at 11:25 am

In a recent post, I explored some of the tradeoffs engineers must make when evaluating the security properties of a given design. In this post, we explore an interesting tradeoff between Security ORG and Privacy in the analysis of web traffic.

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 Chrome ORG and Firefox ORG both integrate the Google Safe Browsing service, while Microsoft Edge ORG 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 ORG

Chrome ORG or 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 DNS ORG lookups 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 Protection ORG and Web Content Filtering features rely upon the Windows Filtering Platform ORG 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 ( DNS ORG or 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 ORG -over-HTTPS (DoH) means that browsers will no longer send unencrypted hostnames to the DNS ORG server when performing lookups, and a new feature called Encrypted Client Hello WORK_OF_ART (ECH) means that browsers can no longer spy on the first ORDINAL few packets of a TLS connection to see what server hostname was requested. Both Chromium ORG and Firefox ORG have recently enabled support for ECH ORG . Notably, both DoH and ECH ORG are presently disabled-by-default in Chrome, Edge ORG , and Firefox ORG for “managed” devices. A test site for ECH ORG can be used to see whether your browser is using ECH ORG .

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.

Browser Policies

Browsers offer policies to allow network administrators to make their own tradeoffs by disabling security-software-blinding privacy changes.

Chrome

DNS-over-HTTPS (already disabled by default on “Managed” devices)

Encrypted Client Hello WORK_OF_ART (currently, ECH ORG on Windows PRODUCT and Linux PRODUCT requires DoH aka “Secure DNS”; testing shows that ECH ORG can be used on Mac ORG when DoH ORG is off.)

QUIC ( HTTP3 GPE products that only support HTTPS-over-TCP/IP cannot analyze QUIC traffic)

Edge

Firefox

Stay safe out there!

-Eric

PS PERSON : 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 ORG , Cloudflare ORG 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 two CARDINAL other cases: 1 CARDINAL ) If the browser uses QUIC, the HTTP/3 traffic isn’t going over a traditional TLS ORG -over-TCP channel at all, and 2 CARDINAL ) If the browser uses H/2 Connection coalescing, the browser might reuse a given HTTPS stream across multiple different origins.

Connecting to blog.lzomedia.com... Connected... Page load complete