InviCloak: An End-to-End Approach to Privacy and Performance in Web Content Distribution

TL;DR

InviCloak tackles the problem that ordinary TLS-based web traffic through CDNs leaks private data to the CDN. It proposes an end-to-end approach that distributes a website-specific public key via DNSSEC/DNS over HTTPS (DoH) and embeds an encryption tunnel inside existing TLS sessions, enabling unilateral deployment by websites and optional client-side integrity verification. The key contributions are the three-part architecture (client proxy, server proxy, integrity verifier), a DNS-based key distribution mechanism (TLSA/DANE with DNSSEC), and an end-to-end encryption channel complemented by cookie protection and integrity verification. Evaluation shows the solution adds minimal page-load-time overhead and preserves CDN throughput, offering a practical alternative to TEEs or two-domain schemes with lower deployment costs and without modifying TLS or CDN infrastructure. The work demonstrates a feasible path to privacy-preserving web content distribution that remains compatible with current web ecosystems while enabling active-attack protection through a browser extension.

Abstract

In today's web ecosystem, a website that uses a Content Delivery Network (CDN) shares its Transport Layer Security (TLS) private key or session key with the CDN. In this paper, we present the design and implementation of InviCloak, a system that protects the confidentiality and integrity of a user and a website's private communications without changing TLS or upgrading a CDN. InviCloak builds a lightweight but secure and practical key distribution mechanism using the existing DNS infrastructure to distribute a new public key associated with a website's domain name. A web client and a website can use the new key pair to build an encryption channel inside TLS. InviCloak accommodates the current web ecosystem. A website can deploy InviCloak unilaterally without a client's involvement to prevent a passive attacker inside a CDN from eavesdropping on their communications. If a client also installs InviCloak's browser extension, the client and the website can achieve end-to-end confidential and untampered communications in the presence of an active attacker inside a CDN. Our evaluation shows that InviCloak increases the median page load times (PLTs) of realistic web pages from 2.0s to 2.1s, which is smaller than the median PLTs (2.8s) of a state-of-the-art TEE-based solution.

Figures (6)

• Figure 1: This figure shows the high-level design of InviCloak in the case of active attackers. It has three components: a client proxy, a server proxy, and an integrity verifier. The client proxy and server proxy encrypt and decrypt the communication between a client and a website's origin server, while the integrity verifier validates the integrity of HTML and JavaScript files returned by a CDN. The client proxy is a Service Worker, which is different from regular JavaScript code (§ \ref{['Design:ClientProxy']}). In the case of passive attackers, the integrity verifier is unnecessary.
• Figure 2: This figure shows the computational time our testbed machines take to perform InviCloak's cryptographic operations.
• Figure 3: This figure shows how InviCloak and Phoenix affect a server and a CDN's throughput. The throughput is in the unit of HTTP responses per second.
• Figure 4: (a) CDF of PLTs on 50 Alexa websites (§ \ref{['ClientPageLoadTime']}). (b) CDF of DeathStarBench's PLTs from six geographically distributed clients (§ \ref{['InternetPageLoadTime']}). The unit of each figure's x-axis is second.
• Figure 5: This figure shows an example of the client proxy configuration file configure.js. A website can specify its sensitive URLs succinctly using regular expressions. In this example, the sensitive URLs are those whose paths are exactly "/transactions" and start with "/profile."