PaperlayerView exact revision on arXiv

Source-linked AI summary

Understanding the Privacy-Preserving Potential of HTTP/2 Against Webpage Fingerprinting

Bogdan Cebere, Prateek Kumar, Sylvain Chatel, Wouter Lueks, Christian Rossow

arXiv:2609.05119v1cs.CR

TL;DR

Website fingerprinting can identify webpages from encrypted HTTPS metadata, motivating defenses at the HTTP layer rather than relying on Tor or VPN. This paper benchmarks HTTP/2 emulations and new protocol-based strategies with calibrated attacks, leakage estimators, and overhead measurements, finding privacy gains that vary by dataset and deployment placement. It also shows that HTTP/2 defenses cannot address leakage from DNS or TLS SNI.

  • Problem

    Website fingerprinting remains feasible from encrypted HTTPS metadata, while application-layer HTTP defenses—especially for widely deployed HTTP/2—are comparatively underexplored.

  • Method

    The paper emulates client- and server-side defenses with HTTP/2 primitives and evaluates them using per-dataset calibration, tuned practical attackers, information-theoretic leakage estimates, and overhead measurements.

  • Results

    H2PC maintains a minimum candidate set of 7.31 at lower cost with page-wide coverage, while H2PS keeps the candidate set above 13 webpages at lower overhead without third-party-server coordination.

  • Takeaways & Limitations

    HTTP/2 provides practical subpage-fingerprinting defenses without a multi-hop anonymity network, while defense configurations should be tailored to target websites because privacy and strongest attackers vary across datasets.

  • Takeaways & Limitations

    HTTP/2 defenses cannot address DNS or TLS leakage; Reddit’s DNS leakage is treated as a known limitation, and the information-theoretic estimates may underestimate true leakage.

Abstract

from arXiv · show

Website fingerprinting (WF) attacks can infer which webpage a user visits from encrypted HTTPS traffic alone, compromising privacy even without decryption. WF defenses commonly shape traffic through noise, padding, delays, or flow splitting, yet they are most often studied from the perspective of encapsulating protocols like Tor or VPN rather than at the application layer (HTTP). In this work, we focus on application-layer defenses enabled by the most widely deployed version of HTTP, HTTP/2. We demonstrate how known defenses can be emulated through HTTP/2 features at the client side (HTTPOS, LLaMA, FRONT, Tamaraw) and the server side (ALPaCA, Tamaraw). We further show that HTTP/2 features, such as proactive resource suggestion, multiplexing, and flow control, offer untapped potential for lightweight yet effective defenses deployable at both endpoints. We evaluate these defenses using a unified blueprint that calibrates defense parameters per dataset, then combines practical attacks, information-theoretic leakage estimates, and overhead measurements. For each defense, this framework identifies the strongest hyperparameter-tuned fingerprinting model and estimates the residual uncertainty induced by the defense using two information-theoretic leakage estimators, all while accounting for the defense's privacy-overhead trade-offs.

1 Introduction

Website fingerprinting extracts browsing activity from encrypted traffic metadata, while common defenses are concentrated in Tor or VPN rather than application-layer HTTP. This work evaluates HTTP/2 as a deployable defense layer, emulates established defenses, and explores new features with a unified privacy–overhead framework.

  • Website fingerprinting can infer users’ online activities from observable traffic characteristics despite HTTPS encryption, enabling censorship and targeted surveillance.
  • Because most web traffic does not use Tor or VPN, HTTP packet metadata remains exposed to on-path adversaries, motivating application-layer defenses.
  • Application-layer defenses pursue uniformity or unpredictability through noise insertion, padding, delay, and packet splitting, but these mechanisms complement rather than replace endpoint-hiding protections.
  • HTTP/2’s privacy potential remains underexplored despite its deployment, including multiplexing, reprioritization, flow control, and proactive resource hints.
  • The evaluation blueprint calibrates defenses per dataset, combines practical attacks, leakage estimates, and overhead measurements, and identifies the strongest tuned attacker and residual leakage.
  • Client-side defenses kept plausible candidate sets above 26 webpages on four of five datasets, while server-side defenses kept them above 63 on every dataset when appropriately placed.
  • New client-side techniques kept candidate sets above seven webpages while reducing latency overhead by 55–98% and downstream overhead by 20–66%; server-side techniques kept sets above 13 while reducing bandwidth overhead by 54–80% on most datasets.

2 Threat Model and Attacker Goals

The threat model considers a passive, defense-aware on-path adversary identifying a specific subpage from encrypted HTTP/2 traffic. The adversary observes individual TCP connections and may use labeled defended traces, but cannot modify communications.

  • The adversary analyzes packet lengths, inter-arrival times, and ordering across identifiable TCP connections grouped into one page-load trace.
  • The adversary is passive and cannot alter communications, but is defense-aware and can collect labeled defended traces for training.
  • The task is subpage fingerprinting: identifying a specific page within a known domain, such as an Amazon product page or Reddit thread.
  • DNS and TLS SNI may provide additional subpage leakage, but the study treats these channels as orthogonal to HTTP/2 defenses and focuses on HTTP packet-level signals.

3 Website Fingerprinting

The study benchmarks subpage fingerprinting on diverse real-world datasets using multiple classical and neural attackers, controlled replay, and traffic representations that preserve connection, packet-length, timing, and burst information. Undefended traces remain highly identifiable, with leakage arising from dataset-specific combinations of connections, requests, timing, bursts, and cumulative transfer patterns.

  • 3.1 Website Fingerprinting: Five fingerprinting models include k-FP, Deep Fingerprinting, VarCNN, Holmes, and RobustFP-CNN, combining feature-engineered and deep-learning approaches.
  • 3.1 Website Fingerprinting: The controlled replay pipeline caches browser resources, replays identical content with defenses enabled or disabled, and captures PCAP traces to isolate HTTP/2-layer effects.
  • 3.1 Website Fingerprinting: Traces are represented for k-FP by handcrafted connection statistics and for neural models by tensors containing signed packet lengths and inter-arrival times.
  • 3.1 Website Fingerprinting: Models are evaluated with cross-validation Macro-F1, computed from per-class F1 scores using true positives, false positives, and false negatives.
  • 3.2 Fingerprinting Case Studies: The evaluation uses 100 subpages from Amazon, BBC, Reddit, Udemy, and Wikipedia, with 500 samples per page selected to capture diverse connection and resource characteristics.
  • 3.2 Fingerprinting Case Studies: Multiple tuned architectures achieve Macro-F1 ≥0.9 on every dataset, showing that effective defenses must address both feature-engineered and deep-learning-based fingerprinting.
  • 3.2 Fingerprinting Case Studies: Leakage sources include packet counts, timing, bursts, and CUMUL, with site-specific patterns spanning CDN image requests, multiple connections, or predominantly first-party traffic.
  • 3.2 Fingerprinting Case Studies: DNS contact ordering is largely uninformative for subpage identity on four datasets, but Reddit reaches Macro-F1 0.74 and remains a known DNS-leakage limitation outside HTTP/2 defenses.

4 Benchmarking WF Defenses

The BBQ blueprint evaluates website-fingerprinting defenses across tuned practical attacks, model-agnostic leakage estimates, and operational overhead. It calibrates configurations per dataset and reports privacy–overhead trade-offs using complementary metrics.

  • Benchmarking framework: BBQ evaluates defenses with five tuned practical attackers, two information-theoretic leakage estimators, and privacy–overhead measurements.The framework is designed to avoid relying on a single attack model or accuracy measure.
  • Defense calibration: Each defense is calibrated per dataset by comparing practical attacker Macro-F1 against bandwidth and latency overheads, then fixing the selected configuration for evaluation.Calibration uses 100 traces per webpage and selects an operating point that reduces Macro-F1 without unnecessary higher-intensity overhead.
  • Practical attacker evaluation: The strongest hyperparameter-tuned attacker is reported through maximum Macro-F1, while Top-k accuracy measures how often the correct page remains among the attacker’s k candidates.Top-k accuracy captures predictive proximity that F1 alone can hide.
  • Information-theoretic evaluation: Mutual information estimates quantify residual leakage beyond exact accuracy, crediting attacks that narrow the candidate set without identifying the exact webpage.The framework combines WeFDE’s feature-based estimator with DeepSE’s learned latent representation and k-NN estimation.
  • Information-theoretic evaluation: The effective candidate-set measure K* uses the larger estimated leakage value as a proxy for unknown mutual information, so it is estimator-derived rather than a bound on true uncertainty.Underestimated leakage can make the reported candidate-set size larger than the true effective set.
  • Operational overhead: Operational overhead is measured as relative per-page upload, download, and latency changes against an undefended baseline, with latency excluding trailing defensive traffic.The framework reports pooled median and quartile overheads across pages and case studies.

5 Modelling WF Defenses in HTTP/2

The paper emulates established client- and server-side defenses with HTTP/2 and evaluates them through calibrated attacks, privacy metrics, and overhead measurements. Defense effectiveness is strongly dataset- and placement-dependent: CL-Tamaraw is strongest among client defenses, while server defenses require protecting connections carrying dominant leakage.

  • Defense emulation: HTTP/2 emulates HTTPOS, LLaMA, FRONT, and Tamaraw on the client side, while also supporting server-side defenses such as ALPaCA and Tamaraw.Server Push-based defenses are evaluated mainly as an estimate of their potential because browser support has declined.
  • Client-side defenses: HTTPOS provides limited protection: calibration Macro-F1 remains above 0.97 on BBC, Reddit, Udemy, and Wikipedia under aggressive range splitting.Amazon reaches 0.699 with W = 1024 B and N ∼U{10, . . . , 20}.
  • Client-side defenses: FRONT reaches calibration Macro-F1 of at most 0.593 at selected operating points, while CL-Tamaraw provides the strongest resilience across all five datasets.CL-Tamaraw’s client-side performance remains dataset-dependent, with K∗ ranging from 38.43 on Amazon to 2.48 on Udemy.
  • Client-side defenses: CL-Tamaraw achieves the lowest Macro-F1 on every dataset, but Udemy remains weak at 0.88; HTTPOS ranges from 0.86 to 0.99 and LLaMA stays above 0.80.FRONT is the second strongest overall, with best Macro-F1 values of 0.54 on Amazon and 0.43 on Wikipedia.

6 The Untapped Potential of HTTP/2 for Fingerprinting Defenses

The paper develops HTTP/2-native defenses that either emulate established traffic-shaping strategies or exploit multiplexing, flow control, PINGs, and resource hints. H2PC and H2PS improve privacy–overhead trade-offs, but performance and calibration remain dataset-dependent.

  • Trade-offs: HTTP/2-native defenses can reduce overhead or expand deployment coverage, but established defenses may require considerable overhead or careful server placement.These limitations arise because the emulated defenses were not designed for HTTP/2’s architecture.
  • Opportunities: HTTP/2 primitives let clients and servers emulate established website-fingerprinting defenses while exposing new application-layer strategies.The paper studies client-side and server-side emulation alongside HTTP/2-native randomization, multiplexing, flow control, and proactive resource suggestions.
  • Client Side: H2PC randomizes flow control, request batching, PING activity, and guarding streams to perturb observable burst patterns.Its calibration varies guarding-stream limits, PING probability and counts, receive-delay bounds, and thresholds.
  • Client Side: H2PC’s strongest configuration reaches Macro-F1 values of 0.232, 0.444, and 0.109 on BBC, Reddit, and Udemy, respectively.Amazon and Wikipedia favor an intermediate operating point, while BBC, Reddit, and Udemy justify the strongest configuration.
  • Client Side: H2PC maintains K∗≥7.32 on Amazon, BBC, Reddit, and Wikipedia while reducing latency and downstream overhead relative to CL-Tamaraw.On Udemy, H2PC raises K∗ from 2.48 to 7.31 while reducing latency overhead from 4.7 to 0.2 and downstream overhead from 8.2 to 2.8.
  • Server Side: H2PS uses randomized server flow control, PINGs, and 103 Early Hints to extend protection page-wide from the 1st-party server.It avoids requiring third-party or CDN cooperation and keeps the attacker’s estimated candidate set above 13 webpages across all five datasets.

7 Conclusion

The paper concludes that HTTP/2 can support practical subpage-fingerprinting defenses without a multi-hop anonymity network. Its evaluation also shows that privacy–overhead results and selected configurations vary across datasets, motivating calibrated, multi-dataset assessment.

  • HTTP/2 supports practical subpage-fingerprinting defenses without requiring a multi-hop anonymity network.
  • H2PC offers lower-cost, page-wide client protection, while H2PS provides page-wide server protection from the 1st-party server alone.H2PC maintains a higher minimum candidate set at lower cost, and H2PS avoids coordination with third-party servers.
  • The benchmarking blueprint combines defense calibration, attacker hyperparameter tuning, and privacy–overhead assessment across datasets.
  • The work releases code for defense calibration, auditing, data collection and replay, endpoint defenses, and dataset benchmarking.
  • The experiments use publicly accessible, non-authenticated scripted sessions and did not collect personal data, user accounts, or sensitive identifiers.

D Data Collection Methodology

The data-collection methodology records browser interactions and server responses for each webpage using automated headless Chromium sessions. These traces are then preserved for replay under controlled HTTP/2 defenses.

  • Browser traces are collected with headless Chromium automated via Playwright, with caching disabled and loading stopped at the domcontentloaded event.
  • Each URL produces parallel client-side request logs and server-side response logs, including headers, content types, status codes, and round-trip durations.
  • The recorded request order and response content are replayed in a Python HTTP/2 client–server environment with defenses enabled or disabled.

D.2 HTTP/2 Client - Server Simulation

The simulation replays identical webpage traces through custom Python HTTP/2 endpoints so client- and server-side defenses can be evaluated under controlled conditions. Network captures are generated independently for each webpage and defense scenario.

  • The replay system uses a standalone HTTP/2 client–server library implemented with the Python h2 library.The implementation is based on a pure-Python, RFC 9113-compliant HTTP/2 stack.
  • Client and server run in separate Docker containers connected through a virtual network rather than the host loopback interface.
  • The client runner loads captured browser data, groups requests by connection, replays requests against the server, and sniffs traffic on the client-side interface.

D.4 Evaluation Datasets Creation

PCAP traces are transformed into separate 2D and 3D evaluation datasets, while security is assessed with both attack-based and information-theoretic estimators under defense-specific tuning.

  • PCAP traces are parsed into distinct 2D and 3D evaluation representations.
  • The 2D pipeline extracts packet-count, timing, burst, and CUMUL features into a trace-by-feature matrix for k-FP and WeFDE.
  • The 3D pipeline stacks signed timing and normalized signed-size channels, padding or truncating each trace to an adaptive feature length.
  • Evaluation combines fingerprinting classifiers with information-theoretic estimators, and classifier hyperparameters are tuned independently for each dataset and defense configuration.
  • k-FP represents traces with random-forest leaf identifiers and uses nearest-neighbor matching, tuning tree count and neighbor count.

E.1.2 Deep-FP [62].

Deep-FP uses a convolutional network to learn website-fingerprinting features directly from raw traces, with its architecture and training parameters selected through hyperparameter search.

  • Deep-FP learns fingerprinting features directly from raw traces rather than using handcrafted features.
  • Its four convolutional blocks double channel depth from 32 to 256 before 512-dimensional embedding and classification heads.
  • Hyperparameter search tunes learning rate, weight decay, classifier dropout, and batch size.

E.1.3 VarCNN [5].

The evaluation compares several CNN-based fingerprinting and leakage-estimation methods, adapting architectures and tuning to the dataset while incorporating packet-length information.

  • VarCNN: VarCNN uses a ResNet-based CNN designed to achieve strong performance with fewer training traces than DF.
  • VarCNN: VarCNN uses a ResNet-18 backbone with four residual stages and tunes learning rate, weight decay, dropout, and batch size.
  • Holmes: Holmes targets early-stage website fingerprinting with a four-stage residual convolutional encoder and VarCNN-matched search ranges.
  • RobustFP-CNN: RobustFP-CNN uses the Robust Fingerprinting CNN architecture with the study’s packet representation rather than reproducing the complete preprocessing pipeline.
  • Shared adaptation: All CNN-based methods are modified to process packet-length information, which is informative in the evaluation datasets.
  • WeFDE: WeFDE estimates mutual information from manually selected features using KDE, Monte Carlo sampling, top-20 feature selection, and redundancy pruning at normalized mutual information above 0.7.

E.2.2 DeepSE-WF [67].

DeepSE-WF estimates mutual information and Bayes error from learned latent spaces using k-nearest-neighbor estimators and a DF-based embedding model evaluated with cross-validation.

  • DeepSE-WF estimates mutual information and Bayes error with specialized kNN-based estimators on learned latent feature spaces.
  • Its embedding model uses a DF backbone with embedding_size = 512, dropout = 0.1, batch_size = 200, and input length = 5,000.
  • The evaluation uses stratified 5-fold cross-validation with two held-out test sets for computing pairwise k-NN distances.
  • The evaluated models are provided in the repository’s wfaudit folder.

F Security Estimators Hyperparameter Tuning

The evaluation tunes each attacker separately for every dataset–defense pair, retaining optimized parameters only when they outperform the default configuration. The resulting tables report the strongest tuned attacker and its selected hyperparameters for each pair.

  • Optimization procedure: Optuna tunes each attacker independently for every dataset–defense pair using Macro-F1 on a stratified held-out validation split.Each search uses up to 150 traces per webpage, with 20% reserved for validation.
  • Configuration selection: The optimized configuration is retained only when its best trial exceeds the default configuration’s Macro-F1 on the tuning split.Otherwise, the default parameters are preserved.
  • Configuration selection: The selected attacker configuration is retrained and evaluated on the full dataset using the same benchmarking procedure as the remaining experiments.
  • Reported results: Tables 10–14 report the strongest attacker after tuning and the hyperparameters selected for each dataset–defense pair.The tables abbreviate batch size, dropout, learning rate, and weight decay as bs, do, lr, and wd, respectively.
Loading 2609.05119v1…