Pith. sign in

REVIEW 4 major objections 3 minor 41 references

CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks

T0 review · 4 major / 3 minor · reviewed 2026-08-01 · deepseek-v4-flash

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

Pith's one-line read Small HTTP/3 requests can be amplified into large HTTP/1.1 floods against CDN-hosted sites, with bandwidth amplification up to 350x.

desk verdict A plausible and well-scoped new attack surface — HTTP/3-to-HTTP/1.1 conversion at CDNs — with a real six-vendor evaluation, but the headline numbers are softer than they look because the measurements are single-testbed and the impact estimate is a proxy. read the letter →

arxiv 2607.26589 v1 pith:FXO664AZ submitted 2026-07-29 cs.CR

Ziyu Lin , Tianlong Su , Yingjie Lin , Prosanta Gope , Yinzhi Cao , Ximeng Liu , Biplab Sikdar This is my paper · ORCID
classification cs.CR
keywords HTTP/3QUICCDNsecuritydenialofservicebandwidthamplificationconnectionQPACKprotocolconversion
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

This paper tries to prove that the gap between the protocols a CDN speaks to clients and to websites creates a new denial-of-service weapon. Because CDNs typically accept HTTP/3 from users but forward requests to origin servers over HTTP/1.1, the CDN must decompress QPACK-compressed headers and multiplex many streams into separate backend connections. The authors design two attacks that exploit this conversion: one inflates bandwidth by expanding tiny header indexes into full HTTP/1.1 headers, and the other inflates the number of connections by slowly feeding data through HTTP/3 streams. They report that all six major CDNs they tested are vulnerable to the bandwidth attack, five to the connection attack, and that a scan of the Tranco Top 1M domains identifies 42,330 subdomains as potentially vulnerable. If correct, the work shows that heterogeneous protocol deployment at CDNs is itself an attack surface that requires guardrails during protocol conversion.

What carries the argument

The central mechanism is the HTTP/3-to-HTTP/1.1 protocol conversion at the CDN edge, specifically two HTTP/3 features that get lost in translation. QPACK header compression lets clients replace full headers with small dynamic-table indexes; the CDN must expand those indexes into full HTTP/1.1 headers, creating bandwidth amplification. HTTP/3 multiplexing over QUIC lets an attacker open many concurrent streams over one connection, each of which can trigger a separate backend HTTP/1.1 connection if the CDN is eager to establish backend connections, creating connection amplification.

What would settle it

Connect a fresh origin server to any CDN that claims to enforce the paper's mitigations (e.g., a 512-byte dynamic-table entry cap and a 64KB decompressed-request limit), send QPACK-indexed headers with large dynamic entries, and measure the origin bandwidth. If the amplification factor stays near 350x, the root-cause claim is wrong. Separately, for the HCA attack, connect to a CDN that buffers the complete HTTP/3 request before establishing a backend connection; if the origin sees no sustained connection pool exhaustion, the connection-amplification claim is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that a CDN's HTTP/3-to-HTTP/1.1 conversion step can be weaponized for amplification. The HTTP/3 Bandwidth Amplification (HBA) attack exploits QPACK header compression: an attacker sends small index references that the CDN must expand into full raw HTTP/1.1 headers, achieving measured amplification factors up to 66x with the static table and 350x with the dynamic table. The HTTP/3 Connection Amplification (HCA) attack exploits the fact that most CDNs open a backend TCP connection immediately upon receiving an HTTP/3 HEADERS frame; by slowly sending DATA frames, the attacker holds many backend connections open, exhausting the origin's connection pool. The paper rep

Load-bearing premise

The central result rests on the assumption that the conversion behaviors observed in the testbed—immediate backend connection on HEADERS, permissive dynamic-table entry sizes up to 3,072 bytes, no decompressed-request size cap, and POST-based cache bypass—are stable across edge nodes and generalizable beyond the six CDN vendors tested.

Editorial extensions

If this is right

  • If the amplification factors hold, an attacker using less than 500 Kbps can saturate a 100 Mbps origin via HBA with dynamic tables.
  • The attacks require no special victim configuration beyond being hosted behind a CDN with HTTP/3 enabled, which is a default for several major providers.
  • The connection attack can exhaust an origin's connection pool within seconds using just a few HTTP/3 client connections, amplifying a single attacker into hundreds of backend connections.
  • The proposed mitigations—capping dynamic-table entry sizes, limiting header-index references, enforcing decompressed-request size limits, and buffering complete requests—directly target the conversion behaviors that enable the attacks.
  • Two CDN vendors have already acknowledged and patched the vulnerabilities, suggesting the attack is practical enough for vendors to respond.

Reading between the lines

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

  • Beyond the paper's claims: the same conversion flaws likely extend beyond CDNs to any HTTP/3-terminating proxy or load balancer that forwards to HTTP/1.1 origins, so the attack surface could be wider than the six vendors tested.
  • A reader might infer that the 42,330 subdomain figure is a lower bound, since subdomain enumeration is incomplete and HTTP/3 default-on deployments expose victims even when the website owner has taken no action.
  • An editor's extension: the paper's root-cause analysis suggests a concrete way to assess the HBA mitigation in the wild—measure the amplification factor before and after deploying a 512-byte dynamic-table entry cap; the paper's own numbers suggest this would sharply reduce amplification.
  • A further inference is that attack detection is hard because the malicious requests are indistinguishable from normal CDN-to-origin traffic; this points to the need for protocol-conversion-level rate limiting rather than traditional volumetric DDoS filters.
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

4 major / 3 minor

Summary. The paper studies DoS attacks that exploit the heterogeneous deployment of HTTP/3 on the client–CDN segment and HTTP/1.1 on the CDN–origin segment. It introduces two attacks: HBA (HTTP/3 Bandwidth Amplification), which abuses QPACK header compression so that compact indexed headers are expanded into large raw HTTP/1.1 headers at the origin; and HCA (HTTP/3 Connection Amplification), which uses slow DATA frames to keep backend connections open and exhaust the origin's connection resources. The authors evaluate both attacks against six CDN vendors, reporting that all six are vulnerable to HBA and five to HCA, with amplification factors up to 66x (static QPACK table) and 350x (dynamic table). They further measure the Tranco Top 1M list and report 151,685 subdomains hosted by vulnerable CDNs, of which 42,330 are 'potentially vulnerable.' The paper also proposes mitigations and describes responsible disclosure, with Baidu and Tencent deploying fixes.

Significance. If the reported results hold, this is a timely and useful contribution: it is the first systematic study of HTTP/3-to-HTTP/1.1 conversion as a DoS amplifier at the CDN layer, building on the earlier HTTP/2-based CDN Judo attack and showing that HTTP/3's QPACK and multiplexing features increase the amplification surface. The attack requires minimal attacker resources (a single connection with small bandwidth) and no special victim-side configuration, which makes the threat model realistic. The paper's strengths include direct measurements against production CDNs, concrete responsible-disclosure outcomes, and practical mitigation principles. However, the paper does not release code or data, and the empirical evidence is thin in terms of repeatability and generality. The impact measurement is an upper-bound estimate based on CNAME suffixes and an HTTP/3 probe, not on validation of the actual conversion behavior on the measured domains. These limitations do not invalidate the core attack idea, but they do prevent the paper's current quantitative claims from being taken at face value.

major comments (4)
  1. [§IV-A, Tables IV–VI, Figures 6–7] The vendor-vulnerability claims are based on a single testbed configuration: one attacker VPS in Singapore, one Apache origin in Hong Kong, and one time window. The paper reports no per-PoP variation, account-tier variation, or repeated runs with error statistics for Figures 6 and 7. The manuscript itself shows that behavior is not uniform across vendors: Table IV reports that Cloudflare buffers the complete request before opening the backend connection (kept-open 7.57s vs. ~300s for others), and Fastly limits fan-out to the first 10 streams per connection. Without evidence that the measured behaviors are stable across the vendors' edge surfaces and over time, the headline claims that 'all six' are vulnerable to HBA and 'five' to HCA are not established beyond the tested configuration.
  2. [§III-B, Figure 5] The 42,330 'potentially vulnerable' domains are identified by (i) matching CNAME suffixes from prior work [27] and (ii) an HTTP/3 connection probe. The actual conversion behavior exploited by HBA/HCA — immediate backend connection on HEADERS, QPACK dynamic-table size, absence of a decompressed-request size cap — is not tested on those 42,330 domains. The paper correctly uses the word 'potentially,' but the abstract and RQ2 answer present the number as an identified impact figure. This estimate should be explicitly framed as an upper bound that assumes all edge nodes of the six vendors behave like the single tested node, and the manuscript should discuss how sensitive the estimate is to that assumption.
  3. [§IV-D, Figure 8, Table V] The amplification-factor analysis lacks statistical support. No error bars, confidence intervals, or per-run values are reported for Figure 8 or Table V, and the only repeated experiment mentioned is RQ3 (10 repetitions), without reporting variance. For central quantitative claims — especially the 350x dynamic-table peak and the claim that the factor is 'independent of the number of streams' for the static table — the paper must provide repeat counts and dispersion measures, or clearly state that these are single-run observations.
  4. [§V-B, §V-D] The paper discloses that Baidu and Tencent have acknowledged the vulnerabilities and deployed mitigations. Nevertheless, the abstract and RQ1 answers report 'all six are vulnerable' / 'five are vulnerable' without caveating that this reflects the state before those mitigations and may no longer describe the current exposure of those two vendors. The claims should be dated and qualified (e.g., 'as of the measurement period') so that readers do not assume the current attack surface is unchanged. This is a load-bearing point because the impact numbers in the paper are intended to quantify real-world risk.
minor comments (3)
  1. [Abstract and §I] Typo: 'thefirststudy' appears as one word in both the abstract and the introduction; it should read 'the first study.'
  2. [Figures 6–8] The y-axis labels and legends are readable, but the figures would benefit from marking the attack start/end times and the victim's capacity limits more explicitly, and from including error bars or shaded confidence regions.
  3. [References] References should include access dates for online resources, especially the Tranco list and vendor documentation, and the paper would benefit from a link to a released artifact (code/data) for reproducibility.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the HBA/HCA amplification factors and connection counts are measured, not derived from the model's inputs; the only self-citation is a supporting data source.

full rationale

The HBA and HCA results are empirical measurements against six CDNs. Amplification factors (up to 66x static, 350x dynamic) and connection counts (384 backend connections) come from testbed experiments in Section IV (Tables IV-VI, Figures 6-8), not from fitting parameters to the claimed outputs. There is no equation in which a predicted quantity reduces to an input by construction. The 42,330 'potentially vulnerable' subdomains are an extrapolation from vendor-level vulnerability plus HTTP/3-enabled domain discovery, so they may over-generalize, but the extrapolation is not circular. The only notable self-citation is [27], used as the source of CDN-assigned subdomains for DNS-based domain discovery (Section III-B: 'we collect CDN-assigned subdomains from previous work [27]'). That list is a supporting input for the impact measurement, not for the central attack derivation; the vendor-level attack results and amplification factors stand independently of it. The paper also discloses behavioral differences (Cloudflare buffers the complete request; Fastly caps backend fan-out at 10 streams), which limits generalization but does not make the derivation circular. No load-bearing premise is justified by a self-citation chain or defined in terms of the target results.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claims are empirical, so no numerical free parameters are fitted. The attacks rest on vendor-specific protocol conversion behaviors and on the measurement assumptions listed above; no new physical or protocol entities are postulated.

assumptions (5)
  • domain assumption The six CDNs terminate HTTP/3 at the edge and always use HTTP/1.1 for the CDN-to-origin leg, even when the origin supports HTTP/3.
    Table I and Section II-B state this heterogeneous deployment; if any tested CDN forwarded HTTP/3 end-to-end, both attacks would not apply.
  • domain assumption The listed cache-bypass techniques (POST, random URL, query parameters, cookie/authorization headers) reliably prevent cached responses for all six CDNs.
    Section II-D and Table II assert these were confirmed, but no per-vendor evidence or success rates are reported; the attacks require each request to reach the origin.
  • domain assumption QPACK dynamic table entries up to 3,072 bytes are accepted, and decompressing them into HTTP/1.1 headers is not capped by a per-request size limit.
    Section III-A.1 and Table VI; the HBA amplification factor depends on the CDN honoring large dynamic-table entries and expanding them without truncation.
  • domain assumption The CDN opens an origin connection upon receiving the HTTP/3 HEADERS frame and keeps it open while DATA frames trickle in, for up to 300+ seconds.
    RQ3 and Table IV; the HCA attack depends on this eager connection establishment and client-controlled keep-alive.
  • domain assumption The measurement framework's DNS enumeration and aioquic probes correctly identify CDN-hosted, HTTP/3-enabled subdomains from the Tranco Top 1M.
    Section III-B; the 42,330 count inherits any false positives or negatives from prefix enumeration, CNAME matching to Table III, and HTTP/3 probing.

how reviews work

0 comments
Cite this review

Pith. "Pith review of CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks." pith.science (2026). https://pith.science/paper/FXO664AZ

@misc{pith2026260726589,
  author       = {Pith},
  title        = {Pith review of: CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FXO664AZ}},
  note         = {Machine review of arXiv:2607.26589}
}
read the original abstract

Content Delivery Networks (CDNs) provide high availability, accelerate content delivery for their host websites, but are also vulnerable to different types of Denial-of-Service (DoS) attacks. Prior works have studied a variety of DoS attacks with HTTP/1.1 or HTTP/2 connections, but most of them are being fixed, making CDNs robust against such attacks. One unexplored research area is how the recent introduction of HTTP/3 at CDNs affects the DoS attack landscape, especially when there are heterogeneous deployments of HTTP/3 and HTTP/1.1 between CDNs and host websites. In this paper, we design the first study of DoS attacks against HTTP/3 protocols deployed at CDNs. Our key insight is that when the CDN adopts HTTP/3 but the host websites use HTTP/1.1, an adversary can utilize the disparity to amplify a small amount of traffic to the CDN using HTTP/3 to a large amount from the CDN to the host website using HTTP/1.1. More specifically, we design two attack variations-HTTP/3 Bandwidth Amplification (HBA) and HTTP/3 Connection Amplification (HCA)-targeting the bandwidth and the number of connections, respectively. Furthermore, we conduct a large-scale measurement upon the Tranco Top 1M domain list to quantify the real-world impact of these attacks, identifying 42,330 subdomains that are potentially vulnerable to our attacks. Finally, we responsibly disclose the details of our attacks to the affected CDN vendors: so far, two vendors have already acknowledged their vulnerabilities with bounties and have deployed our mitigations.

Figures

Figures reproduced from arXiv: 2607.26589 by the authors.

Figure 2
Figure 2. Concept of HTTP/3 Bandwidth Amplification Attack. An attacker [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 1
Figure 1. Attack concept of HTTP/3 Amplification Attacks. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. Concept of HTTP/3 Connection Amplification Attack. An attacker [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Workflow of the automated measurement framework. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Number of potentially vulnerable domains across different CDN [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Launch an HBA attack lasting 60s. 0 50 100 150 200 250 300 350 400 450 500 550 600 Time(s) 0 100 200 300 400 Concurrent Connection Number Alibaba Baidu CloudFront Fastly Tencent (a) Number of established CDN-website connections 0 50 100 150 200 250 300 350 400 450 500 …
Figure 7
Figure 7. Figure 7: Launch an HCA attack lasting 300s. TABLE VI LIMITS SET BY CDNS ON HTTP/3 STREAMS AND DYNAMIC TABLES. Alibaba Baidu Cloudflare CloudFront Fastly Tencent Max Streams 128 128 256 128 100 128 Dynamic Table Size 4KB 4KB N/A N/A N/A 4KB Max Entry Size 3072B 3072B N/A N/A N/A…
Figure 8
Figure 8. Figure 8: Bandwidth amplification factor when the number of concurrent streams [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

41 extracted references · 3 canonical work pages

  1. [27]

    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

    arXiv 2024

  2. [1]

    User Datagram Protocol,

    “User Datagram Protocol,” RFC 768, Aug. 1980. [Online]. Available: https://www.rfc-editor.org/info/rfc768

    1980

  3. [2]

    A coordinated response to madeyoureset http/2 protocol attacks,

    Akamai, “A coordinated response to madeyoureset http/2 protocol attacks,” 2025, https://www.akamai.com/blog/security/ response-madeyoureset-http2-protocol-attacks

    2025

  4. [3]

    Botnet-based distributed denial of service (ddos) attacks on web servers: Classification and art,

    E. Alomari, S. Manickam, B. B. Gupta, S. Karuppayah, and R. Alfaris, “Botnet-based distributed denial of service (ddos) attacks on web servers: Classification and art,”CoRR, vol. abs/1208.0403, 2012. [Online]. Available: http://arxiv.org/abs/1208.0403

    arXiv 2012

  5. [4]

    Understanding the mirai botnet,

    M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. Bursztein, J. Cochran, Z. Durumeric, J. A. Halderman, L. Invernizzi, M. Kallitsis, D. Kumar, C. Lever, Z. Ma, J. Mason, D. Menscher, C. Seaman, N. Sullivan, K. Thomas, and Y . Zhou, “Understanding the mirai botnet,” in26th USENIX Security Symposium, USENIX Security 2017, Vancouver, BC, Canada, August 16...

    2017

  6. [5]

    Bishop, “HTTP/3,” RFC 9114, Jun

    M. Bishop, “HTTP/3,” RFC 9114, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9114

    2022

  7. [6]

    Content delivery network usage statistics,

    Builtwith, “Content delivery network usage statistics,” 2024, https: //trends.builtwith.com/CDN/Content-Delivery-Network

    2024

  8. [8]

    A hands-on gaze on HTTP/3 security through the lens of HTTP/2 and a public dataset,

    E. Chatzoglou, V . Kouliaridis, G. Kambourakis, G. Karopoulos, and S. Gritzalis, “A hands-on gaze on HTTP/3 security through the lens of HTTP/2 and a public dataset,”Computers & Security, vol. 124, p. 103051, 2023

    2023

Show all 41 references
  1. [9]

    Revis- iting QUIC attacks: a comprehensive review on QUIC security and a hands-on study,

    E. Chatzoglou, V . Kouliaridis, G. Kambourakis, and C. Kolias, “Revis- iting QUIC attacks: a comprehensive review on QUIC security and a hands-on study,”International Journal of Information Security, vol. 22, pp. 1037–1053, 2023

    2023

  2. [10]

    Host of troubles: Multiple host ambiguities in HTTP implementations,

    J. Chen, J. Jiang, H. Duan, N. Weaver, T. Wan, and V . Paxson, “Host of troubles: Multiple host ambiguities in HTTP implementations,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28,

    2016

  3. [11]

    Forwarding-loop attacks in content delivery networks,

    J. Chen, X. Zheng, H. Duan, J. Liang, J. Jiang, K. Li, T. Wan, and V . Paxson, “Forwarding-loop attacks in content delivery networks,” in23rd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016. The Internet Soc...

    2016

  4. [12]

    The cloudflare support http/3

    Cloudflare, “The cloudflare support http/3.” 2024, https://developers. cloudflare.com/speed/optimization/protocol/http3/

    2024

  5. [13]

    Transmission Control Protocol (TCP),

    W. Eddy, “Transmission Control Protocol (TCP),” RFC 9293, Aug

  6. [14]

    Blocking-resistant communication through domain fronting,

    D. Fifield, C. Lan, R. Hynes, P. Wegmann, and V . Paxson, “Blocking-resistant communication through domain fronting,”Proc. Priv. Enhancing Technol., vol. 2015, no. 2, pp. 46–64, 2015. [Online]. Available: https://doi.org/10.1515/popets-2015-0009

    2015 doi

  7. [15]

    Temporal cdn-convex lens: A cdn-assisted practical pulsing ddos attack,

    R. Guo, J. Chen, Y . Wang, K. Mu, B. Liu, X. Li, C. Zhang, H. Duan, and J. Wu, “Temporal cdn-convex lens: A cdn-assisted practical pulsing ddos attack,” in32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023. USENIX Association, 2023. [Onli...

    2023

  8. [16]

    CDN judo: Breaking the CDN dos protection with itself,

    R. Guo, W. Li, B. Liu, S. Hao, J. Zhang, H. Duan, K. Sheng, J. Chen, and Y . Liu, “CDN judo: Breaking the CDN dos protection with itself,” in 27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, California, USA, February 23-26, 2020. The Interne...

    2020

  9. [17]

    Ddos mitigation: A review of content delivery network and its ddos defence techniques,

    M. Imthiyas, S. Wani, R. A. A. Abdulghafor, A. A. Ibrahim, and A. H. Mohammad, “Ddos mitigation: A review of content delivery network and its ddos defence techniques,”International Journal on Perceptive and Cognitive Computing, vol. 6, no. 2, pp. 67–76, 2020

    2020

  10. [18]

    QUIC: A UDP-Based Multiplexed and Secure Transport,

    J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000

    2021

  11. [19]

    QFAM: Mitigating QUIC handshake flooding attacks through crypto challenges,

    A. Jabbari, Y . A. Joarder, B. Teyssier, and C. Fung, “QFAM: Mitigating QUIC handshake flooding attacks through crypto challenges,”arXiv preprint arXiv:2412.08936, 2024

    2024 arXiv

  12. [20]

    A security orchestration system for cdn edge servers,

    E. Jalalpour, M. Ghaznavi, D. Migault, S. Preda, M. Pourzandi, and R. Boutaba, “A security orchestration system for cdn edge servers,” in 2018 4th IEEE Conference on Network Softwarization and Workshops (NetSoft). IEEE, 2018, pp. 46–54

    2018

  13. [21]

    Wide-scale botnet detection and characterization,

    A. Karasaridis, B. Rexroad, and D. A. Hoeflin, “Wide-scale botnet detection and characterization,” inFirst Workshop on Hot Topics in Understanding Botnets, HotBots’07, Cambridge, MA, USA, April 10, 2007. USENIX Association, 2007. [Online]. Available: https://www.usenix.org/con...

    2007

  14. [22]

    QUICLORIS: A slow denial- of-service attack on the QUIC protocol,

    M. Kosek, J. S. Kotimur, and V . Bajpai, “QUICLORIS: A slow denial- of-service attack on the QUIC protocol,” inProceedings of the ACM SIGCOMM 2023 Workshop on Protocols for Future Large-scale, Di- verse, Real-time Networks. ACM, 2023

    2023

  15. [23]

    Security and service vulnerabilities with HTTP/3,

    M. Kosek, J. S. Kotimur, T. Marshburn, A. Perrig, and V . Bajpai, “Security and service vulnerabilities with HTTP/3,” in2024 IEEE 13th International Conference on Cloud Networking (CloudNet). IEEE, 2024

    2024

  16. [24]

    QPACK: Field Compression for HTTP/3,

    C. B. Krasic, M. Bishop, and A. Frindell, “QPACK: Field Compression for HTTP/3,” RFC 9204, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9204

    2022

  17. [25]

    CDN backfired: Amplification attacks based on HTTP range requests,

    W. Li, K. Shen, R. Guo, B. Liu, J. Zhang, and H. D. et al., “CDN backfired: Amplification attacks based on HTTP range requests,” in50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2020, Valencia, Spain, June 29 - July 2, 2020. IEEE, 2020, ...

    2020

  18. [26]

    When HTTPS meets CDN: A case of authentication in delegated service,

    J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, “When HTTPS meets CDN: A case of authentication in delegated service,” in2014 IEEE Symposium on Security and Privacy, SP 2014, Berkeley, CA, USA, May 18-21, 2014. IEEE Computer Society, 2014, pp. 67–82. [Online]. Available...

    2014 doi

  19. [28]

    {CDN} cannon: Exploiting{CDN}{Back-to-Origin}strategies for amplification attacks,

    Z. Lin, Z. Lin, X. Liu, J. Chen, R. Guo, C. Chen, and S. Xiao, “{CDN} cannon: Exploiting{CDN}{Back-to-Origin}strategies for amplification attacks,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5717–5734

    2024

  20. [29]

    Unveiling the bandwidth nightmare: Cdn compression format conversion attacks,

    Z. Lin, Z. Lin, X. Liu, Z. Ying, and C. Chen, “Unveiling the bandwidth nightmare: Cdn compression format conversion attacks,” in2024 2nd International Conference on Big Data and Privacy Computing (BDPC). IEEE, 2024, pp. 97–106

    2024

  21. [30]

    List, 2024, https://tranco-list.eu/

    T. List, 2024, https://tranco-list.eu/

    2024

  22. [31]

    Jaqen: A high- performance switch-native approach for detecting and mitigating volumetric ddos attacks with programmable switches,

    Z. Liu, H. Namkung, G. Nikolaidis, J. Lee, C. Kim, X. Jin, V . Braverman, M. Yu, and V . Sekar, “Jaqen: A high- performance switch-native approach for detecting and mitigating volumetric ddos attacks with programmable switches,” in30th USENIX Security Symposium, USENIX Securit...

    2021

  23. [32]

    Cached and confused: Web cache deception in the wild,

    S. A. Mirheidari, S. Arshad, K. Onarlioglu, B. Crispo, E. Kirda, and W. Robertson, “Cached and confused: Web cache deception in the wild,” in29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020. USENIX Association, 2020, pp. 665–682. [Online]. Available: ht...

    2020

  24. [33]

    QUICsand: Quantifying QUIC reconnaissance scans and DoS flooding events,

    M. Nawrocki, R. Hiesgen, T. C. Schmidt, and M. W ¨ahlisch, “QUICsand: Quantifying QUIC reconnaissance scans and DoS flooding events,” in Proceedings of the 21st ACM Internet Measurement Conference (IMC). ACM, 2021, pp. 260–275

    2021

  25. [34]

    Your cache has fallen: Cache-poisoned denial-of-service attack,

    H. V . Nguyen, L. L. Iacono, and H. Federrath, “Your cache has fallen: Cache-poisoned denial-of-service attack,” inProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS 2019, London, UK, November 11-15, 2019. ACM, 2019, pp. 1915–

    2019

  26. [35]

    Usage statistics of http/3 for websites,

    W. T. Surveys, “Usage statistics of http/3 for websites,” 2025, https: //w3techs.com/technologies/details/ce-http3

    2025

  27. [36]

    Content delivery networks: Protection or threat?

    S. Triukose, Z. Al-Qudah, and M. Rabinovich, “Content delivery networks: Protection or threat?” inComputer Security - ESORICS 2009, 14th European Symposium on Research in Computer Security, Saint-Malo, France, September 21-23, 2009. Proceedings, ser. Lecture Notes in Computer ...

    2009 doi

  28. [37]

    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 2021, August 11-13, 2021. USENIX Association, 2021, pp. 3327–3343. [Online]. Available: https://www.usenix.org/confe...

    2021

  29. [38]

    Low-rate dos attacks, detection, defense, and challenges: A survey,

    Z. Wu, W. Li, L. Liu, and M. Yue, “Low-rate dos attacks, detection, defense, and challenges: A survey,”IEEE Access, vol. 8, pp. 43 920–43 943, 2020. [Online]. Available: https://doi.org/10.1109/ ACCESS.2020.2976609

    2020

  30. [39]

    Domain borrowing: Catch my c2 traffic if you can,

    J. Zhou and T. Ding, “Domain borrowing: Catch my c2 traffic if you can,” 2021, https://i.blackhat.com/asia-21/Thursday-Handouts/ as-21-Ding-Domain-Borrowing-Catch-My-C2-Traffic-If-You-Can.pdf

    2021

  31. [1936]

    Available: https://doi.org/10.1145/3319535.3354215

    [Online]. Available: https://doi.org/10.1145/3319535.3354215

  32. [2016]

    1516–1527

    ACM, 2016, pp. 1516–1527. [Online]. Available: https: //doi.org/10.1145/2976749.2978394

    2016

  33. [2022]

    Available: https://www.rfc-editor.org/info/rfc9293

    [Online]. Available: https://www.rfc-editor.org/info/rfc9293

Pith tools

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