Pith. sign in

REVIEW 2 major objections 5 minor 38 references

Domain Decoupling Attack: Exploiting the Validation Gap Between Protective DNS and Shared Edge Routing

T0 review · 2 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that DNS-based egress controls are structurally unable to keep a permitted connection bound to the domain that earned the permission, and that an attacker can reach nearly any tenant sharing the allowed domain's IP address

desk verdict The core DDA mechanism is real and the ZTDNS lab result is clean, but the paper overreaches when it calls the bypass structural for 'any DNS-bound control' — that is an assumption, not a measured property. read the letter →

arxiv 2608.00643 v1 pith:G4WEYEB4 submitted 2026-08-01 cs.CR cs.NI

Weizhe Wang , Minhong Dong , Jinhao Li , Yao Zhang , Hao Liu , Qiang Hu , Tao Luo , Guangquan Xu
show 1 more author
Bin Wu
This is my paper · ORCID
classification cs.CRcs.NI
keywords DomainDecouplingAttackProtectiveDNSDNS-boundaccesscontrolsharededgeTLSSNICDNmulti-tenancytraffichidingegressfiltering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper introduces the Domain Decoupling Attack (DDA), which exploits a validation gap in DNS-based authorization: a protective DNS service approves a domain, but the resulting firewall or Zero Trust DNS permit applies to the resolved IP address, not to that domain. Because CDN and shared-hosting edges serve many tenants behind one IP, an attacker can resolve an allowed domain, obtain permission for the shared edge address, then connect to that same address while presenting a hidden domain consistently in TLS SNI and HTTP Host. A large-scale measurement of 1,069,048 domains found that 95.8% accept such a connection, with 99.26% exposure among CDN domains and 92.75% among non-CDN domains. Laboratory tests with Windows ZTDNS confirmed the underlying structural limitation: DNS-bound access control cannot preserve the approved-domain binding when a later connection selects another tenant behind the same shared address. The paper argues this makes DDA distinct from domain fronting (no SNI–Host inconsistency), domain borrowing (no ownership verification weakness), and domain shadowing (no routing rewrite), and recommends defenders bind connection-time identity to the approved domain.

What carries the argument

The core mechanism is the 'validation gap' described as a tuple (D_allowed, IP_cdn, D_malicious, D_malicious), where the DNS-approved domain D_allowed yields a permitted shared address IP_cdn, and the connection then presents D_malicious consistently in both SNI and Host. The load-bearing object is the address-level permission granted by DNS-bound access control (e.g., Windows ZTDNS), which applies to the IP rather than to the domain associated with the DNS response. A second mechanism is the 'co-location chain': same-IP tenants form connected components in a graph, so one approved cover domain extends to every tenant in its component.

What would settle it

A concrete falsifier would be a single enterprise deployment where, after a client resolves an allowed domain and receives an IP-level permit, the egress control rejects or flags a TLS connection to the same IP when the SNI names a different domain that is also hosted on that IP — or a measurement showing that a representative DNS-bound egress product binds the permit to the resolved domain at connection time in its default configuration.

Watch

Extended reading notes

Core claim

DDA is a new traffic-hiding attack that separates the domain approved during DNS resolution from the domain presented during connection establishment while preserving SNI–Host consistency. The attack resolves an allowed domain to obtain an address-level permission for a shared edge IP, then connects to the same IP while presenting the hidden domain in both TLS SNI and HTTP Host. The CDN or shared-hosting edge routes the connection to the hidden tenant because tenant selection is based on connection-level identity, not on the DNS-approved domain. Measurements on 1,069,048 domains show that 95.8% accept a TLS handshake carrying an external SNI, and that a co-location chain extends a single aut

Load-bearing premise

The attack's generality rests on the assumption that real DNS-bound egress controls grant outbound permission at the address level without binding that permission to the domain associated with the DNS response, and that no inline application-layer inspection blocks or flags the hidden domain's cleartext SNI in Simple Mode.

Editorial extensions

If this is right

  • If the central claim is correct, DNS-bound egress allowlists cannot reliably restrict traffic to approved domains when the permitted IP serves multiple tenants, because permission is granted at the address level.
  • Defenders should bind connection-time identity to the approved domain (e.g., require SNI to match the DNS-approved domain at the edge) and treat address-level reuse on shared edges as a security property.
  • The co-location chain means that a small allowlist can cover a large reachable set: one approved domain can provide cover for every tenant in its same-IP connected component, potentially thousands of unrelated domains.
  • Encrypted Client Hello (ECH) removes the connection-level domain from inspection, so SNI-aware inspection cannot distinguish the hidden tenant from the allowed one in ECH Mode; rules based on the outer name or shared IP are non-selective.
  • The attack adds no protocol overhead and requires no special privilege, certificate, or modification of network controls, making it a low-cost technique for concealing C2, data exfiltration, and censorship-circumvention traffic.
  • Provider-specific edge policies affect feasibility (exposure ranges from 76.52% for one CDN to 99.72% for another), suggesting that some providers can mitigate the attack by cross-checking connection identity against the DNS-approved domain.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The prevalence of the vulnerable architecture on real enterprise networks is not measured; the paper verifies the bypass in a controlled lab for one DNS-bound control (Windows ZTDNS) and extrapolates structurally. A follow-up could survey how many enterprise egress controls issue address-level permits without domain binding.
  • The attack likely also applies to other address-level allowlists (e.g., some cloud firewalls or access-control proxies) that derive permit state from a DNS response; testing these would show whether the validation gap is broader than CDN and shared hosting.
  • A defense that binds connection-time identity to the approved domain would need to handle legitimate scenarios where a domain resolves to multiple IPs and where connections to the same IP may be load-balanced; the paper does not discuss the usability cost of such binding.
  • The measurement's 'exposure' is defined as TLS acceptance plus content match where applicable; a stricter definition that requires a full application-layer response might yield lower rates, though the paper separates HIGH, MEDIUM, and LOW levels.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper introduces the Domain Decoupling Attack (DDA), which exploits the separation between DNS-based domain authorization and IP-level connection permissions on shared CDN and non-CDN hosting edges. The attacker resolves an allowlisted domain to obtain a permit for a shared edge IP, then connects to the same IP while presenting another domain consistently in TLS SNI and HTTP Host. Four modes are described: Simple, Split, ECH, and Direct IP. A laboratory evaluation with Windows ZTDNS shows that after resolving an allowed domain, the resulting address-level permit can be reused to reach a blocked domain on the same shared edge with ordinary TLS and with ECH. A large-scale measurement of 1,069,048 Tranco domains reports that 95.8% accept a TLS handshake carrying an external SNI, with 84.6% reaching the HIGH level where the hidden tenant's content is returned. The paper further claims a co-location chain attack that extends a single approved domain to all domains in a connected same-IP co-location graph, and concludes that DNS-bound access controls have a structural limitation on shared addresses.

Significance. The laboratory result is a clean, direct demonstration that a real DNS-bound access control (Windows ZTDNS) grants address-level permissions that can be reused by another tenant on the same shared IP. The measurement is large-scale (over one million domains, 18 million probes) and the exposure claim is not the product of a fitted parameter; the SimHash threshold only separates HIGH from MEDIUM. If the results hold, the paper documents an important architectural gap between DNS-domain decisions and IP-level enforcement. The contribution is currently weakened by two overstatements: the 'structural' generalization from ZTDNS to all DNS-bound controls is not established, and the co-location-chain transitivity claim is mathematically incorrect as stated. With corrected framing, this would be a solid empirical contribution to the literature on DNS-based egress control and shared-infrastructure security.

major comments (2)
  1. [§IV / §III-B2] The claim that the bypass is 'structural and transfers to any DNS-bound control that admits resolver-returned addresses' (§IV) is unsupported. The laboratory evaluates only Windows ZTDNS, which exactly matches Assumption A2 (address-level permit without domain binding). A control that admits resolver-returned addresses but binds the permit to the resolved domain's SNI/certificate—the paper's own recommended mitigation—would block Simple Mode and force the ECH inner SNI to be exposed at the enforcement point. The 95.8% measurement quantifies edge-side acceptance of foreign SNIs, not the prevalence of the vulnerable control class or attack success under DNS-bound controls. The conclusion must be scoped to DNS-bound controls that grant address-level permissions without domain binding; as written, the central 'structural limitation' claim is an assertion, not a demonstrated result.
  2. [§III-D] The co-location-chain argument overstates reachability. The graph is defined by same-IP co-location, so a connected component can contain domains that do not share any single IP (e.g., A shares IP1 with B, B shares IP2 with C). The statement that 'co-location is transitive over shared IPs, one approved domain reaches every tenant in its connected component' is false: A's approved DNS permit covers IP1 only; reaching C requires a separate permit for IP2. The component-size statistics (largest component 77,991 domains) therefore do not support the claim that a single allowlisted domain covers an entire component. The chain attack is only valid when each additional tenant along the path is itself an authorized domain. This should be stated explicitly, and the abstract and contribution list should be reworded to avoid the transitive-reach claim.
minor comments (5)
  1. [Abstract / §III-A3] The abstract's 95.8% exposure rate includes MEDIUM and LOW results (TLS success without content match). The HIGH rate of 84.6% is the rate at which the hidden tenant's content is actually served. Please report both rates together in the abstract or clarify that 'exposure' means SNI acceptance only, to avoid overstating practical attack success.
  2. [§III-A2 / §II-E] Split Mode is presented as a DDA mode, but the laboratory evaluation covers only Simple Mode and ECH Mode. If Split Mode is not empirically evaluated, this should be stated explicitly in the evaluation section; otherwise the mode remains an untested hypothesis.
  3. [§III-A1 / §III-C2] The phrase 'across six continents' refers to GeoLite2 registration locations of edge IPs, not to measurement vantage points. The location of the measurement server is not stated. Clarify this to avoid implying geographically distributed scanning.
  4. [§III-A3] Only the SimHash threshold 0.90 is mentioned; no sensitivity analysis or score distribution is provided. The paper states the exposure claim is threshold-independent, but a figure of similarity-score distributions would substantiate this.
  5. [§III-C2] The country-level aggregation merges Hong Kong, Taiwan, and Macao into 'China'. This is a politically sensitive labeling choice; please align with ISO 3166 or provide a clarifying footnote.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the exposure rates are measured quantities and the structural-limitation claim is a conditional consequence of the address-level permit assumption, not a fitted or self-cited result.

full rationale

The paper's central quantitative claims are measurement results, not outputs of a fitted model. The 95.8% overall exposure rate, the CDN/non-CDN splits, and the cross-tenant IP figures are counts of TLS handshakes carrying an external SNI that were accepted by shared edge infrastructure, and the paper explicitly states in §IV that the SimHash threshold only separates HIGH from MEDIUM and does not affect the binary exposure claim. The laboratory result on Windows ZTDNS is an empirical instantiation of Assumption A2, which states that the firewall grants permission at the address level without binding it to the DNS-response domain. The conclusion that an address-level permit cannot preserve a domain-level binding on a multi-tenant address is an analytic consequence of that assumption, not a prediction derived from the conclusion itself. The paper's only scope weakness is that it generalizes from one implementation to 'any DNS-bound control that admits resolver-returned addresses' (§IV) without measuring how widely that vulnerable subclass is deployed; this is an external-validity concern, not a circular derivation. There are no load-bearing self-citations, no fitted parameters renamed as predictions, and no equations that reduce to their own inputs.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the composition of three independent properties: address-granular DNS-derived permits (A2), tenant-selection by SNI alone (A3), and the absence of TLS-level re-validation. Only the SNI-routing property is measured at scale; the control property is tested on one product; the absence of inspection is assumed. No new entities are posited.

free parameters (2)
  • SimHash content-similarity threshold = 0.90
    Hand-chosen cutoff separating HIGH from MEDIUM exposure (§III-A3); the paper states it does not affect the exposure claim, but it is an un-validated knob in the measurement pipeline.
  • Split-Mode time window Δt = unspecified
    Split Mode's exploitability depends on a 'short interval Δt' during which the inspection engine reuses trusted state for C2 (§II-E); no value or target state-management policy is given, so this parameter is free and untested.
assumptions (4)
  • domain assumption A2: DNS-bound egress controls (e.g., ZTDNS) grant address-level permits derived from DNS answers without binding the permit to the resolved domain.
    Load-bearing: if a control bound the permit to the TLS identity or certificate of the resolved domain, DDA's IP-reuse step fails. Verified only against Windows ZTDNS in the lab (§III-B2); its generality is asserted in §IV.
  • domain assumption The target path has no application-layer TLS interception (Simple Mode), or the inspection engine skips re-analysis within Δt (Split Mode).
    Simple Mode requires P_dpi to be absent (§II-D); Split Mode requires stateful skip behavior (§II-E). If the enterprise TLS-inspects egress, both modes fail or are detected; prevalence of such deployments is unmeasured.
  • domain assumption A3: the CDN/shared edge selects the tenant from connection-level identity (SNI/Host) and cannot cross-check the DNS-stage domain.
    Near-tautological given how SNI-based routing works (§II-B), but it is the second half of the 'validation gap' and the model depends on it.
  • ad hoc to paper ZTDNS is representative of the entire class of 'DNS-bound controls that admit resolver-returned addresses'.
    The paper generalizes a single-stack lab result to 'any DNS-bound control' (§IV) without testing other implementations; this is the paper's own structural claim, not a measured fact.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Domain Decoupling Attack: Exploiting the Validation Gap Between Protective DNS and Shared Edge Routing." pith.science (2026). https://pith.science/paper/G4WEYEB4

@misc{pith2026260800643,
  author       = {Pith},
  title        = {Pith review of: Domain Decoupling Attack: Exploiting the Validation Gap Between Protective DNS and Shared Edge Routing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/G4WEYEB4}},
  note         = {Machine review of arXiv:2608.00643}
}
read the original abstract

Network attackers often conceal malicious communication within legitimate Internet traffic. Existing CDN-based evasion techniques rely on SNI--Host inconsistency, insufficient domain ownership verification, or provider-specific routing rewrites, which limit their applicability in modern CDN environments. We identify a validation gap in DNS-based authorization, where permission derived from an allowed domain applies to a shared IP and can be reused to reach another tenant in both CDN and non-CDN shared-hosting environments. This paper presents the Domain Decoupling Attack (DDA), which resolves an allowed domain to obtain permission for a shared edge IP and subsequently connects to the same address while presenting the hidden domain consistently in both TLS SNI and HTTP Host. Measurements of 1,069,048 domains across six continents produce 18,025,068 successful probes and identify exposure rates of 95.8% overall, 99.26% for CDN domains, 92.75% for non-CDN domains, and 97.7% for non-CDN cross-tenant IPs, while laboratory experiments reveal a structural limitation of DNS-bound access control on shared addresses. These results clarify the security risks of DNS-derived IP authorization and support the evaluation and improvement of access-control mechanisms in CDN and non-CDN shared-hosting environments.

Figures

Figures reproduced from arXiv: 2608.00643 by the authors.

Figure 1
Figure 1. Validation gap between DNS-based authorization and CDN tenant [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. DDA overview: the DNS-approved domain and the connection-level tenant diverge at the shared edge. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Exposure by vulnerability level. external SNI. These results show that external SNI acceptance is widespread and that most accepted connections reach the intended tenant rather than terminating at a generic edge response. The comparison between CDN and non-CDN domains reveals a clear difference in attack effectiveness. DDA exposes 99.26% of the 506,763 CDN domains and 92.75% of the 562,285 non-CDN domains, which rep… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Exposure rate by CDN provider. L1 intra-tenant (exploitable) L2 cross-tenant (exploitable) L2 cross-tenant (all) 0 10000 20000 30000 40000 50000 IPs 3,336 52,811 54,069 [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Non-CDN same-IP multi-tenancy and exploitable cross-tenant IPs. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 10
Figure 10. Figure 10: This component structure supports a co-location chain at￾tack. An authoritative domain A resolves to a shared edge IP and causes the address to receive network permission. The attacker then connects to the same address while presenting another tenant B as the connecti…
Figure 10
Figure 10. Figure 10: Connected-component sizes of the same-IP co-location graph. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 9
Figure 9. Figure 9: Exposure rate by DNS depth. HTTP Host, so the channel between the endpoint and C is recorded as communication with A. The permission does not stop at one domain pair: because the permit covers the shared address rather than a single tenant, and co-location is transitiv…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 2 linked inside Pith

  1. [1]

    Hunting for invisibility: Characterizing and detecting malicious web infrastructures through server visibility analysis,

    J. Zhang, X. Hu, J. Jang, T. Wang, G. Gu, and M. Stoecklin, “Hunting for invisibility: Characterizing and detecting malicious web infrastructures through server visibility analysis,” inIEEE INFOCOM 2016-The 35th Annual IEEE International Conference on Computer Communications. IEEE, 2016, pp. 1–9

    2016

  2. [2]

    A long-term perspective of the internet susceptibility to covert channels,

    P. ˙Z´orawski, L. Caviglione, and W. Mazurczyk, “A long-term perspective of the internet susceptibility to covert channels,”IEEE Communications Magazine, vol. 61, no. 10, pp. 171–177, 2023

    2023

  3. [3]

    Assessing and exploiting domain name misinformation,

    B. Anderson and D. McGrew, “Assessing and exploiting domain name misinformation,” in2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 2023, pp. 475–486

    2023

  4. [4]

    Blocking- resistant communication through domain fronting,

    D. Fifield, C. Lan, R. Hynes, P. Wegmann, and V . Paxson, “Blocking- resistant communication through domain fronting,”Proceedings on Privacy Enhancing Technologies, 2015

    2015

  5. [5]

    Deniable upload and download via passive participation,

    D. Sommer, A. Dhar, L. Malisa, E. Mohammadi, D. Ronzani, and S. Capkun, “Deniable upload and download via passive participation,” in16th USENIX Symposium on Networked Systems Design and Imple- mentation (NSDI 19), 2019, pp. 649–666

    2019

  6. [6]

    Hiding in plain sight: An empirical study of web application abuse in malware,

    M. Yao, J. Fuller, R. P. Kasturi, S. Agarwal, A. K. Sikder, and B. Saltaformaggio, “Hiding in plain sight: An empirical study of web application abuse in malware,” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 6115–6132

    2023

  7. [7]

    Domain shadowing: Leveraging content delivery networks for robust{Blocking-Resistant}communications,

    M. Wei, “Domain shadowing: Leveraging content delivery networks for robust{Blocking-Resistant}communications,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 3327–3343

    2021

  8. [8]

    Censorship evasion with unidentified protocol generation,

    R. Wails, R. Jansen, A. Johnson, and M. Sherr, “Censorship evasion with unidentified protocol generation,” in34th USENIX Security Symposium (USENIX Security 25), 2025, pp. 763–782

    2025

Show all 38 references
  1. [9]

    Discov- ering and measuring CDNs prone to domain fronting,

    K. Subramani, R. Perdisci, P.-C. Skafidas, and M. Antonakakis, “Discov- ering and measuring CDNs prone to domain fronting,” inProceedings of the ACM Web Conference 2024, 2024, pp. 1859–1867

    2024

  2. [10]

    Domeye: Detecting network covert channel of domain fronting with throughput fluctuation,

    Y . Xie, G. Gou, G. Xiong, Z. Li, and W. Xia, “Domeye: Detecting network covert channel of domain fronting with throughput fluctuation,” Computers & Security, vol. 144, p. 103976, 2024

    2024

  3. [11]

    Fakeapp: A high-precision method for domain fronting detection in real networks with neuro-symbolic integration,

    ——, “Fakeapp: A high-precision method for domain fronting detection in real networks with neuro-symbolic integration,” in2025 IEEE Inter- national Conference on Systems, Man, and Cybernetics (SMC). IEEE, 2025, pp. 5581–5588

    2025

  4. [12]

    Detecting and measuring security implications of entangled domain verification in cdn,

    Z. Lin, Z. Lin, R. Guo, J. Chen, M. Zhang, X. Liu, T. Yang, Z. Cao, and R. H. Deng, “Detecting and measuring security implications of entangled domain verification in cdn,”arXiv preprint arXiv:2409.01887, 2024

    2024 arXiv

  5. [13]

    How effective is{Multiple-Vantage-Point}domain control validation?

    G. H. Cimaszewski, H. Birge-Lee, L. Wang, J. Rexford, and P. Mittal, “How effective is{Multiple-Vantage-Point}domain control validation?” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5701–5718

    2023

  6. [14]

    Domain borrowing: Catch my c2 traffic if you can,

    T. Ding and J. Zhou, “Domain borrowing: Catch my c2 traffic if you can,” Black Hat Asia 2021 Briefings, May 2021

    2021

  7. [15]

    (2025) Zero trust dns

    Microsoft. (2025) Zero trust dns. Microsoft Learn. [Online]. Avail- able: https://learn.microsoft.com/en-us/windows/security/operating- system-security/network-security/zero-trust-dns/

    2025

  8. [16]

    Zero trust archi- tecture,

    S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust archi- tecture,”NIST special publication, vol. 800, no. 207, pp. 1–52, 2020

    2020

  9. [17]

    Hypertext transfer protocol (http/1.1): Message syntax and routing,

    R. T. Fielding and J. Reschke, “Hypertext transfer protocol (http/1.1): Message syntax and routing,” RFC 7230, 2014

    2014

  10. [18]

    The web is smaller than it seems,

    C. A. Shue, A. J. Kalafut, and M. Gupta, “The web is smaller than it seems,” inProceedings of the 7th ACM SIGCOMM conference on Internet measurement, 2007, pp. 123–128

    2007

  11. [19]

    Cloudflare ip addresses,

    Cloudflare, “Cloudflare ip addresses,” https://developers.cloudflare.com/fundamentals/concepts/cloudflare- ip-addresses/, 2026, accessed: July 28, 2026

    2026

  12. [20]

    Satellite: Joint analysis of{CDNs}and{Network-Level}interference,

    W. Scott, T. Anderson, T. Kohno, and A. Krishnamurthy, “Satellite: Joint analysis of{CDNs}and{Network-Level}interference,” in2016 USENIX Annual Technical Conference (USENIX ATC 16), 2016, pp. 195–208

    2016

  13. [21]

    Issues and requirements for server name identification (sni) encryption in tls,

    C. Huitema and E. Rescorla, “Issues and requirements for server name identification (sni) encryption in tls,”RFC 8744, 2020

    2020

  14. [22]

    Reqsminer: Automated discovery of cdn forwarding request inconsistencies and dos attacks with grammar-based fuzzing

    L. Zheng, X. Li, C. Wang, R. Guo, H. Duan, J. Chen, C. Zhang, and K. Shen, “Reqsminer: Automated discovery of cdn forwarding request inconsistencies and dos attacks with grammar-based fuzzing.” inNDSS, 2024

    2024

  15. [23]

    Paint it black: Evaluating the effectiveness of malware blacklists,

    M. K ¨uhrer, C. Rossow, and T. Holz, “Paint it black: Evaluating the effectiveness of malware blacklists,” inInternational Workshop on Recent Advances in Intrusion Detection. Springer, 2014, pp. 1–21

    2014

  16. [24]

    Tranco: A research-oriented top sites ranking hardened against manip- ulation,

    V . Le Pochat, T. Van Goethem, S. Tajalizadehkhoob, W. Joosenet al., “Tranco: A research-oriented top sites ranking hardened against manip- ulation,” inProceedings of the 26th Annual Network and Distributed System Security Symposium. Internet Society, 2019, pp. 1–15

    2019

  17. [25]

    A system for detecting network intruders in real-time,

    P. V . Bro, “A system for detecting network intruders in real-time,” in Proc. 7th USENIX security symposium, 1998

    1998

  18. [26]

    Zeek: The open source network security monitor,

    Zeek Project, “Zeek: The open source network security monitor,” https://github.com/zeek/zeek, 2026, gitHub repository. Accessed: August 1, 2026

    2026

  19. [27]

    Suricata: Network threat detec- tion engine,

    Open Information Security Foundation, “Suricata: Network threat detec- tion engine,” https://github.com/OISF/suricata, 2026, gitHub repository. Accessed: August 1, 2026

    2026

  20. [28]

    Opnsense: Open source firewall and routing plat- form,

    OPNsense Project, “Opnsense: Open source firewall and routing plat- form,” https://opnsense.org/, 2026, accessed: August 1, 2026

    2026

  21. [29]

    pfsense: Open source firewall and router platform,

    pfSense Project, “pfsense: Open source firewall and router platform,” https://www.pfsense.org/, 2026, accessed: August 1, 2026

    2026

  22. [30]

    Simhash: Hash-based similarity detection,

    C. Sadowski and G. Levin, “Simhash: Hash-based similarity detection,” Technical report, Google, Tech. Rep., 2007

    2007

  23. [31]

    Geolite2 free geolocation data,

    MaxMind, “Geolite2 free geolocation data,” https://dev.maxmind.com/geoip/geolite2-free-geolocation-data/, 2026, accessed: August 1, 2026

    2026

  24. [32]

    Domain fronting is dead, long live domain fronting: Using tls 1.3 to evade censors, bypass network defenses, and blend in with the noise,

    E. Hunstad, “Domain fronting is dead, long live domain fronting: Using tls 1.3 to evade censors, bypass network defenses, and blend in with the noise,” DEF CON 28, Aug. 2020, conference presentation

    2020

  25. [33]

    Practical censorship evasion lever- aging content delivery networks,

    H. Zolfaghari and A. Houmansadr, “Practical censorship evasion lever- aging content delivery networks,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 1715–1726

    2016

  26. [34]

    The web is still small after more than a decade,

    N. P. Hoang, A. A. Niaki, M. Polychronakis, and P. Gill, “The web is still small after more than a decade,”ACM SIGCOMM Computer Communication Review, vol. 50, no. 2, pp. 24–31, 2020

    2020

  27. [35]

    DNS queries over HTTPS (DoH),

    P. Hoffman and P. McManus, “DNS queries over HTTPS (DoH),” RFC Editor, RFC 8484, Oct. 2018. [Online]. Available: https://www.rfc- editor.org/rfc/rfc8484.html

    2018

  28. [36]

    TLS encrypted client hello,

    E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood, “TLS encrypted client hello,” RFC Editor, RFC 9849, Mar. 2026. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9849.html

    2026

  29. [37]

    Attacking DoH and ECH: Does server name encryption protect users’ privacy?

    M. Trevisan, F. Soro, M. Mellia, I. Drago, and R. Morla, “Attacking DoH and ECH: Does server name encryption protect users’ privacy?” ACM Transactions on Internet Technology, vol. 23, no. 1, pp. 1–22, 2023

    2023

  30. [38]

    Domain name encryption is not enough: Privacy leakage via ip-based website fingerprinting,

    N. P. Hoang, A. A. Niaki, P. Gill, and M. Polychronakis, “Domain name encryption is not enough: Privacy leakage via ip-based website fingerprinting,”arXiv preprint arXiv:2102.08332, 2021

    2021 arXiv

Pith tools

Reviewed August 4, 2026 · model on record in the stance chip above.