CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks Ziyu Lin∗† , Tianlong Su† , Yingjie Lin† , Prosanta Gope‡ , Yinzhi Cao§ , Ximeng Liu† , Biplab Sikdar∗
arXiv:2607.26589v1 [cs.CR] 29 Jul 2026
∗ National University of Singapore,
† Fuzhou University,
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.
I. I NTRODUCTION Content Delivery Networks (CDNs) are indispensable for the contemporary Internet ecosystem. They significantly reduce user access latency and enhance the user experience by caching content on globally distributed edge servers. A core advantage of CDNs lies in their load-balancing capabilities, which effectively manage massive concurrent requests and ensure global access to content. For example, over 55% of the Top 10K websites and more than 40% of the Top 1M websites are deployed behind CDNs [6]. While CDNs provide convenience for real-world websites, they have also become a popular target for attacks, especially Denial-of-Service (DoS) attacks. In the past, researchers have proposed many DoS attacks [11], [15], [25], [28], [29], [36] against CDN services. For example, Guo et al. [16] designed an amplification attack that abuses the conversion between HTTP/2 and HTTP/1.1 requests. Li et al. [25] utilize HTTP Range Requests for amplifying the request to the host website with a small request. Triukose et al. [36] proposed an attack that exhausts the host website’s bandwidth by quickly disconnecting the clientCDN connection. However, most existing attacks are widely known and have thus been protected against by existing CDN
‡ University of Sheffield,
§ Johns Hopkins University
providers [2]. Furthermore, although prior works have studied various DoS attacks related to different HTTP versions from HTTP/1.1 to HTTP/2, one unexplored research area is the combination of HTTP/3 and CDN services. The HTTP/3 protocol was officially standardized through RFC 9114 [5] and RFC 9204 [24] and is currently supported by 35.2% of websites [35] and most CDN services. In this paper, we propose the first study of DoS attacks against HTTP/3 services adopted by CDN providers. The key insight of the attacks is the mismatch between the efficient transmission in terms of bandwidth and number of connections of HTTP/3 and the low efficiency of HTTP/1.1. Therefore, an attacker can establish efficient HTTP/3 connections to the CDN server, which will be expanded to inefficient requests, such as a large number of requests or requests with large payloads, to the host website, leading to a DoS attack. Specifically, we describe two types of HTTP/3 related DoS attacks: HTTP/3 Bandwidth Amplification (HBA) Attack. The primary objective of this attack is to exploit the CDN’s HTTP/3-to-HTTP/1.1 conversion, where small QPACK index values, a new feature introduced in HTTP/3, are decoded into large raw HTTP headers, thereby launching bandwidth amplification attacks against host websites. • HTTP/3 Connection Amplification (HCA) Attack. The primary objective of this attack is to gradually send DATA frames, thereby effectively controlling the kept-open time of the CDN-website connection, exhaust all available connection resources of the host website, and ultimately launch a DoS attack that blocks requests from legitimate users. •
We evaluated both of our attacks against six major CDN providers. Our results show that five of them are vulnerable to HCA attacks, and all six are vulnerable to HBA attacks. We responsibly disclosed our findings to all CDN providers. So far, two CDN vendors have acknowledged their vulnerability and awarded us bug bounties. They have deployed our mitigations. To further quantify the potential real-world impact of our attacks, we design an automated measurement framework to discover potentially vulnerable domains. We apply our framework to evaluate subdomains from the Tranco Top 1M domains, identifying 151,685 subdomains hosted by vulnerable CDNs, and finding that 42,330 subdomains are potentially vulnerable to our attacks. Our Contributions. We make the following contributions in this paper.
• Two new types of amplification attacks. We introduce two new types of amplification attacks, the HBA and the HCA attack. These attacks exploit the HTTP/3-toHTTP/1.1 conversion, exhausting the victim’s bandwidth and connections. • Real-world evaluations. We examine the HBA and HCA attacks on six popular CDN vendors to assess their feasibility and real-world impacts. The experiment results show that all examined CDNs are vulnerable to the HBA attack, and five of them are vulnerable to the HCA attack. • Real-world impact. We perform a large-scale measurement across the Tranco Top 1M domain list using our framework, discovering 151,685 subdomains hosted by vulnerable CDNs, and identifying 42,330 subdomains potentially vulnerable to our attacks. • Mitigation and responsible disclosure. We present the mitigations and responsibly disclose all vulnerabilities to CDN vendors. In particular, two CDN vendors acknowledged vulnerabilities, rewarded our reports, and have deployed our mitigations. II. OVERVIEW In this section, we first introduce some background on Content Delivery Networks (CDNs) and the new HTTP/3 protocol. Then, we present our problem statement, the threat model, and techniques to bypass the CDN cache mechanism. A. Background: CDN and HTTP/3 CDN is a group of servers located in different geographical locations that have become the backbone of the Internet. It accelerates content delivery through edge servers and offers DDoS protection by absorbing most of the attack traffic. Specifically, CDN acts as a man-in-the-middle between clients and websites to decouple traditional client-website connections into two segments: client-CDN and CDN-website connections. CDNs support different versions of the HTTP protocol in the two connections. HTTP/3 is a relatively new protocol proposed in 2022, which aims to reduce latency and optimize network performance. The main innovation in HTTP/3 is the adoption of the QUIC (Quick UDP Internet Connections) protocol [18], which distinguishes it from previous HTTP versions that run over TCP (Transmission Control Protocol) [13]. This fundamental shift is designed to solve the inherent “head-of-line blocking” issue that TCP faces in modern network environments, thereby further enhancing transmission efficiency and user experience. Next, we will detail two optimization features supported by HTTP/3 that are relevant to our research. • QPACK header compression [24]. QPACK is a header field compression format for HTTP/3 that makes the HPACK header compression format of HTTP/2 compatible with the QUIC protocol. Its primary purpose is to drastically shrink the size of HTTP headers that travel across the network. QPACK achieves this by referencing header fields that have been seen before, sending just small index numbers instead of the full header fields.
TABLE I CDN VENDORS ’ SUPPORT FOR THE HTTP/3 PROTOCOL .
Alibaba Baidu Cloudflare CloudFront Fastly Tencent
•
client-CDN
CDN-website
HTTP/3 Support
HTTP/1.1 & HTTP/3 HTTP/1.1 & HTTP/3 HTTP/1.1 & HTTP/3 HTTP/1.1 & HTTP/3 HTTP/1.1 & HTTP/3 HTTP/1.1 & HTTP/3
HTTP/1.1 HTTP/1.1 HTTP/1.1 HTTP/1.1 HTTP/1.1 HTTP/1.1
Default Off Configurable Default Off Configurable Default On Configurable Default On Configurable Default Off Configurable Default Off Configurable
Multiplexing [5]. HTTP/3’s multiplexing capability is achieved by its underlying QUIC protocol. QUIC implements its own reliable transport, flow control, and multiplexing functions over UDP [1], operating on a connection-based multiplexing model. It allows for the simultaneous handling of multiple independent request streams over a single QUIC connection. Consequently, even if a packet in one stream is lost, it will not block other streams within the same connection, effectively solving TCP’s head-of-line blocking problem.
B. Problem Statement: HTTP/1.1 and HTTP/3
Heterogeneous
Deployment
of
Currently, all CDN providers claim to support HTTP/3 [12] as shown in Table I. The deployment is heterogeneous, though, which means that the client-CDN connection is HTTP/3, but the CDN-website connection is HTTP/1.1. The reason is that many websites still do not support HTTP/3, making an end-toend deployment infeasible. Specifically, we conducted experiments on the HTTP/3 support of six popular CDN providers. The experimental results, as shown in Table I, reveal that all CDNs support HTTP/3 in the client-CDN connection but only support HTTP/1.1 in the CDN-website connections, even when the host website supports HTTP/3. Such a heterogeneous deployment leaves potential room for DoS attacks. C. Threat Model Our threat model involves three parties in a CDN deployment. Specifically, we list each party and their capability below. An end web user: a potential attacker. An attacker, as a web user, can craft malicious yet legitimate requests and send them to a CDN provider, which may then reroute the requests to host websites. • CDN Provider: an unwitting intermediary. CDN providers act as a man-in-the-middle between end users and host websites. In our threat model, attackers exploit the CDN’s HTTP/3-to-HTTP/1.1 conversion mechanism to amplify malicious traffic. The CDN itself is not the target of the attack but is abused as an amplifier to relay and magnify attack traffic toward the host website. • Host Websites: the victims. Host websites are the ultimate victims, which receive amplified DoS traffic from CDN providers, indirectly initiated by the malicious end user. •
TABLE II T ECHNIQUES TO BYPASS THE CDN CACHE MECHANISM .
Dynamic Resources Random URL Query Parameters HTTP POST/PUT WebSocket handshake Cookie Header Authorization Header
Alibaba
Baidu
Cloudflare
CloudFront
Fastly
Tencent
" " " " " " "
" " " " " " "
" " " " " " "
" " " " "
" " " " " " "
" " " "
POST / HTTP/1.1 Host: victim.com large string: large string ... large string: large string
--------Stream0-------:Path: / :Authority: victim.com large string: large string ... large string: large string --------Stream4-------:Method: POST :Path: / :Authority: victim.com
attacker
CDN
website
Fig. 2. Concept of HTTP/3 Bandwidth Amplification Attack. An attacker sends HTTP/3 requests with QPACK headers; the CDN must decompress the HTTP/3 headers, resulting in bandwidth amplification.
① bypass CDN Cache Mechanism ③amplify the forwarding requests
② send crafted legal requests
attacker
CDN
website
Fig. 1. Attack concept of HTTP/3 Amplification Attacks.
D. Techniques to Bypass the CDN Cache Mechanism To send successive attack requests to the victim, the presence of a CDN cache may prevent forwarding of attack requests to the victim. When attacking a website, the victim may return a cacheable HTTP response. It is necessary to bypass the CDN cache mechanism to ensure that attacking requests reach the victim rather than hitting the CDN cache. After exploring the CDN forwarding strategies and working mechanism exhaustively, we conclude several approaches to bypass the CDN cache mechanism and confirm them in the six CDN vendors, as listed in Table II. CDN vendors cache resources based on HTTP-related parameters such as file extensions, URL paths, or HTTP Header. Attackers can exploit these rules to bypass CDN caching. III. D ESIGN In this section, we first present the core design of our HTTP/3 amplification attack and then describe a measurement framework to quantify the impacts of the attacks for real-world websites. A. HTTP/3 Amplification Attack Figure 1 shows the overall attack flow of our amplification attack. The high-level idea is to amplify the connection from an attacker to a CDN to a huge request (either in terms of request size or the number of requests) from the CDN to the host website. Specifically, the attack has three steps: (1) the attacker bypasses the CDN cache mechanism; (2) the attacker sends crafted legal requests; and (3) the CDN amplifies the forwarding requests. The first step is to bypass the CDN cache mechanism. As discussed in Section II, we summarize several techniques to bypass the CDN cache mechanism (Table II). In this paper, we primarily use HTTP POST requests to bypass the CDN cache. The next steps are launching attacks, and we describe two types of such amplifications below.
1) Bandwidth Amplification: The HTTP/3 Bandwidth Amplification (HBA) attack enables attackers to exploit a CDN to convert small HTTP/3 requests into significantly larger HTTP/1.1 requests, thereby depleting the target host website’s bandwidth. Figure 2 shows the attack principle of our HBA attack. Since HTTP/1.1 lacks this header compression mechanism, the CDN forces all indexed fields to be expanded into large raw HTTP/1.1 headers, which leads to a significant bandwidth amplification attack. There are two variations of the HBA attack, depending on whether static and/or dynamic tables are supported. Specifically, according to the QPACK mechanism, in the clientCDN connection, both the client and the CDN maintain static and dynamic tables. The static table is predefined and includes a set of the most common HTTP header fields and their values. Both the client and CDN implicitly possess the same static table, allowing direct referencing via indexes during transmission, eliminating the need to transmit the full content of these common fields. The dynamic table is updated dynamically based on the actual header fields transmitted after the connection is established. The client adds new header fields appearing in the connection to the dynamic table and assigns them indexes. Subsequent duplicate header fields are replaced by referencing the corresponding index values in the dynamic table via their indexes, significantly reducing the number of bytes transmitted. Although QPACK can bring significant performance improvements, its support varies among CDNs. If dynamic tables are supported, an attacker can initiate the attack by first sending an HTTP/3 request with a large header that is inserted into the dynamic table. For subsequent requests, the attacker then repeatedly utilizes small QPACK index values to reference this raw large header. Currently, static tables are widely supported, but only half of the existing CDNs support dynamic tables, as shown in Table V. 2) Connection Amplification: The Connection Amplification enables attackers to manipulate the kept-open time of CDN-website connections to exhaust all available connection resources of the host website. Specifically, to accelerate content delivery, CDNs establish CDN-website connections immediately upon receiving HTTP/3 HEADERS frames. Therefore, an attacker can exploit this behavior by slowly sending HTTP/3 DATA frames to indirectly control the kept-open time of CDN-website connections, thereby launching an HCA attack.
--------Stream0-------HEADER Frame :Method: POST :Path: / :Authority: victim.com
attacker
--------Stream0-------Data Frame ... --------Stream0-------Data Frame
POST / HTTP/1.1 Host: victim.com
TABLE III CDN- ASSIGNED SUBDOMAINS .
aa...aaaaaaaaaa
CDN Wait Time
CDN
HTTP/1.1 200 OK
Alibaba Baidu Cloudflare CloudFront Fastly Tencent
website
Fig. 3. Concept of HTTP/3 Connection Amplification Attack. An attacker sends HTTP/3 HEADERS frames in an HTTP/3 connection; the CDN must establish multiple HTTP/1.1 connections to the host website, resulting in connection amplification.
Figure 3 shows the attack principle. An attacker first sends a HEADERS frame in an HTTP/3 stream to force the CDN to establish an HTTP/1.1 connection with the host website. Subsequently, the attacker prompts the CDN to maintain the CDN-website connection for an extended period by sending subsequent DATA frames at a very low rate. This attack leads the CDN to believe that the request is not yet complete, thus continuously occupying the host website’s connection resources. Since most CDNs support HTTP/3 in the clientCDN connection but still only support HTTP/1.1 in the CDN-website connection, this protocol conversion mechanism means that the CDN will establish an individual TCP connection with the host website for each independent HTTP/3 request stream. HTTP/3’s multiplexing feature allows attackers to initiate a large number of concurrent HTTP/3 request streams within a single HTTP/3 connection. Specifically, the HTTP/3 protocol supports the simultaneous processing of multiple bidirectional streams within a single HTTP/3 connection, thereby avoiding head-of-line blocking during the TCP handshake and achieving full multiplexing of requests and responses. Each HCA attack stream will prompt the CDN to establish a separate connection between the CDN and the host website. Consequently, with minimal resource consumption on their part, an attacker can force CDNs to establish a large number of CDN-website connections far exceeding their own needs, which significantly enhances the attack’s efficiency and amplification effect. Ultimately, all available connection resources of the host website will be exhausted, preventing it from responding to legitimate user requests, and thereby achieving a DoS attack. B. Attack Impact Measurement Quantifying the potential real-world impact of HTTP/3 amplification attacks is crucial. To achieve this, we designed and implemented an automated measurement framework that can identify websites simultaneously hosted on vulnerable CDNs with HTTP/3 support enabled. The workflow of our automated measurement framework is divided into four main steps, as shown in Figure 4. Enumerating subdomains. The objective of this step is to acquire a collection of Fully Qualified Domain Names (FQDNs) from the Tranco Top 1M list. We employ a bruteforce technique based on a custom prefix dictionary. First, we
Assigned subdomain .cdngslb.com, .alicdn.com, .alikunlun.com .bdydns.com, .jomodns.com, .yunjiasu-cdn.net .cdn.cloudflare.net .cloudfront.net .fastly.net, .fastlylb.net .cdn.dnsv1.com, .tdnsv6.com
generate a list of FQDNs under target second-level domains (SLDs) using this custom prefix dictionary, providing greater flexibility in the discovery process. We append each prefix to the target SLD to create an FQDN and verify its existence through DNS queries. We utilize this method to enumerate FQDNs for the Tranco Top 1M domain list. Crawling DNS records. After obtaining the FQDNs list, we crawl the CNAME and NS records for each FQDN. To speed up the DNS record crawling for the Tranco Top 1M domains, we launched five DNS crawler instances simultaneously. Each instance began crawling from a different index within the Tranco Top 1M list. Discovering CDN-hosted domains. When a domain owner wishes to deploy their domains to a CDN, the CDN typically assigns a subdomain belonging to the CDN. The domain owner must then create a CNAME record, pointing their domain to this CDN-assigned subdomain to redirect traffic to the CDN. We identify CDN-hosted domains through the following steps: First, for a given CDN (e.g., Fastly), we collect CDN-assigned subdomains from previous work [27] (Table III). Second, we compare the DNS records with these CDN-assigned subdomains to identify vulnerable CDN-hosted domains. Identifying HTTP/3-enabled CDN-hosted domains. We utilize aioquic as a client to send HTTP/3 requests to vulnerable CDN-hosted domains. If the server responded successfully, it indicated that the host website had HTTP/3 support enabled on that CDN. We consider these as vulnerable domains. IV. E VALUATION Our evaluation answers the following research questions. RQ1: How many real-world CDNs are vulnerable to HTTP/3 amplification attacks? Answer: We evaluated both of our attacks against six major CDN providers in the real world. Our results show that all six of them are vulnerable to HBA attacks, and five of them are vulnerable to HCA attacks. • RQ2: How many websites are affected by the proposed HTTP/3 amplification attacks? Answer: We apply our framework to evaluate subdomains from the Tranco Top 1M domain list [30], identifying 151,685 subdomains hosted by vulnerable CDNs, and finding that 42,330 subdomains are potentially vulnerable to our attacks. •
FQDNs
second-level domains
Tranco Top 1M list
Enumerating subdomains
DNS Records
Crawling DNS records
vulnerable domains
CDN-hosted domains
Discovering Identifying HTTP/3-enabled CDN-hosted domains CDN-hosted domains
Fig. 4. Workflow of the automated measurement framework.
RQ3: Which CDNs immediately establish the CDNwebsite connection upon receiving HTTP/3 HEADERS, and what is the maximum connection kept-open time? Answer: Five CDNs immediately establish the CDNwebsite connection upon receiving HTTP/3 HEADERS frames, and their kept-open time depends on the clientCDN connection’s kept-open time, which makes them vulnerable to the HCA attack. • RQ4: How does the number of concurrent streams affect this amplification factor? Answer: When the attacker uses the static table, the amplification factor does not change with the number of concurrent streams; however, when using the dynamic table, the amplification factor increases with the number of concurrent streams, peaking at approximately 64 streams with a maximum amplification factor of approximately 350× due to the CDN’s CPU overhead in decompressing QPACK indexes into large HTTP/1.1 headers.
80000
•
A. RQ1: Real-world Vulnerable CDNs In this research question, we evaluate both HBA and HCA attacks against six real-world CDNs. Experiment Setup. We set up an Apache HTTP server in Hong Kong as the target host website, with the Apache TimeOut value of 300 seconds and a connection limit of 256. The attacker was launched from a VPS in Singapore. For ethical considerations, we deliberately limited the victim website’s bandwidth to 100Mbps and the attacker’s bandwidth to 30Mbps to ensure that our experimental traffic would not degrade CDN network performance or impact other CDNhosted websites. It is important to note that these bandwidth constraints represent our self-imposed ethical limits, not the upper bounds of the attack’s actual capability. In real-world scenarios, websites with higher bandwidth and connection limits would require proportionally more attack streams, but the fundamental attack mechanism remains effective, as the amplification ratio is inherent to the HTTP/3-to-HTTP/1.1 conversion and is independent of the victim’s capacity. 1) RQ1.1: HBA Attacks.: Figure 6(b) shows the experiment results. For each vulnerable CDN, the bandwidth of the host website is consistently greater than 100Mbps during the HBA attack. Meanwhile, as shown in Figure 6(a), the bandwidth consumption of attackers from the three vendors that support dynamic tables is all less than 500Kbps, while that of attackers from the other vendors that only support static tables is all less than 5Mbps. These results demonstrate that the DoS attack was successfully carried out, depleting the bandwidth resources of host websites across different CDNs.
vulnerable domains CDN-hosted domains
Number of Domains
70000
77724
60000 50000 40000
32590
30000 20000 10000 0
22475 12174 720
Alibaba
12371 3257 18
17431 11606
Baidu CloudflareCloudFront Fastly CDN Vendors
3465 184
Tencent
Fig. 5. Number of potentially vulnerable domains across different CDN providers in the Tranco Top 1M list.
2) RQ1.2: HCA Attacks: Table V shows that all six CDNs support a minimum of 100 concurrent streams. For most CDNs, by establishing four HTTP/3 client-CDN connections and multiplexing 96 streams within each connection (4×96 = 384), we can force each CDN to establish 384 HTTP/1.1 CDNwebsite connections, which effectively exhausts all available connections on the host website. Fastly establishes a maximum of 10 CDN-website connections per HTTP/3 connection. Therefore, we initiated 48 HTTP/3 client-CDN connections, each multiplexing 8 streams (48 × 8 = 384), which also establish 384 HTTP/1.1 CDN-website connections on the host website. On the attacker side, we first send HTTP request headers for each stream using the HTTP/3 HEADERS frame. Subsequently, we slowly send the HTTP request body via the HTTP/3 DATA frame, which allows us to maintain the CDNwebsite connection and carry out a continuous HCA attack for 300 seconds. During the HCA attack, we periodically send GET requests to the CDN every second and record the CDN response time to probe whether the connection resources of the host website have been exhausted. Figure 7(a) shows the experiment results of our HCA attacks. For each vulnerable CDN, the number of established CDN-website connections is consistently greater than 300 during the HCA attack. At the host website, connection resources are exhausted, and other requests are starving. Consequently, as shown in Figure 7(b), when we launch the HCA attack at 100s, the response time for benign clients reached 60s on Alibaba and up to 90s on Baidu and CloudFront, returning an HTTP 504 Gateway Timeout. In particular, for Tencent, approximately 10 seconds after sending a GET request to probe the host website, it actively closes the client-CDN connection, resulting in no response to the probe request.
Meanwhile, Fastly’s response time rises to 15s, returning an HTTP 503 Service Unavailable. These results demonstrate that the DoS attack was successfully executed, severely affecting the availability of host website services across different CDNs. B. RQ2: Measurement of Impacted Websites The purpose of this research question is to measure how many real-world websites are impacted by those two attacks. Specifically, our large-scale measurement across the Tranco Top 1M domain list provides a quantitative assessment of the real-world attack surface for our attacks. Figure 5 illustrates the distribution of CDN-hosted domains and, crucially, the subset of “potentially vulnerable domains” (i.e., those hosted on identified vulnerable CDNs and having HTTP/3 support enabled, thus satisfying all prerequisites for our attacks) across six prominent CDN providers. As illustrated in Figure 5, 151,685 domains were hosted by vulnerable CDNs. Of these, 42,330 are identified as potentially vulnerable. CloudFront has the highest number of domains among vulnerable CDNs, hosting a total of 77,724 domains. Of these, 17,431 are identified as potentially vulnerable. Cloudflare ranks second with 32,590 domains, of which 12,371 are potentially vulnerable. Fastly reveals a total of 22,475 domains, with 11,606 identified as potentially vulnerable. Alibaba hosts 12,174 domains, of which 720 are potentially vulnerable, while Tencent has 3,465 domains, with 184 classified as potentially vulnerable. Baidu has the fewest domains, hosting only 3,257, of which 18 are potentially vulnerable to our attacks. These results underscore the widespread presence of potentially vulnerable websites within the current Internet ecosystem, particularly across major CDN services. C. RQ3: Kept-Open Time of CDN-website Connection The purpose of this research question is to explore how the kept-open time of CDN-website connection affects our HCA attack. Experiment Setup. In our experiments, we set up a selfhosted Apache server and deployed it as the host website behind six CDNs, one at a time. For each CDN, we first send HTTP/3 HEADERS frames, and then send a DATA frame per second, taking 300 seconds to complete the transmission. We establish an HTTP/3 connection with the CDN and send 100 concurrent requests within this connection. Concurrently, we use tcpdump on the host website to capture the time it took for the CDN to establish a CDN-website connection, as well as the kept-open time of CDN-website connection. Experiment Results. After sending 100 concurrent requests and repeating this process 10 times, we obtain the average results as shown in Table IV. We can observe that Alibaba, Baidu, CloudFront, Fastly, and Tencent immediately begin establishing a CDN-website connection upon receiving the HEADERS frame. In contrast, Cloudflare only established the connection after receiving the complete HTTP/3 request. Clearly, for Alibaba, Baidu, CloudFront, and Tencent, the kept-open time of the CDN-website connection depends on the kept-open time of the client-CDN connection, which is
TABLE IV C ONNECTION ESTABLISHING AND KEPT- OPEN TIMES WHEN SENDING 100 STREAMS FOR DIFFERENT CDN VENDORS .
Connection establishing Time Connection Kept-open Time
Alibaba
Baidu
Cloudflare
CloudFront
2.88
1.80
301.56
2.94
311.97
307.76
7.57
306.53
Fastly 1.33(10) 304.97(90) 308.84(10) 5.46(90)
Tencent 2.66 309.96
TABLE V M AXIMUM AMPLIFICATION FACTORS ACROSS THE CDN S USING STATIC TABLE .
# Streams # Headers Factor Dynamic Table
Alibaba
Baidu
Cloudflare
CloudFront
Fastly
Tencent
128 950 65.8 "
128 350 66.06 "
256 190 48.27 %
128 330 51.2 %
100 210 36.41 %
128 201 54.08 "
" This CDN supports the QPACK dynamic table. % This CDN does not support the QPACK dynamic table.
directly controlled by the client, thus potentially exploitable by malicious attackers. Although Fastly also immediately began establishing a CDN-website connection upon receiving the HEADERS frame, its behavior differs: it establishes CDNwebsite connections for the first 10 HTTP/3 HEADERS frames within each HTTP/3 connection. Subsequent requests within the same HTTP/3 connection are then queued, during which Fastly must wait to receive the complete requests, resulting in a kept-open time of 5.46s. D. RQ4: Amplification Factor Analysis The purpose of this research question is to perform an amplification factor analysis for our HBA attack. Experiment Setup. We performed the HBA attack using two distinct QPACK compression strategies to determine the maximum amplification factor. We initially utilized the standard QPACK static table, and subsequently leveraged the QPACK dynamic table. Experiment Results. Both the client and the server possess identical static tables, allowing for direct referencing via indexes during transmission. Consequently, in an HBA attack that leverages the static table, the amplification factor remains independent of the number of streams. In our experiments, we utilize index 56 from the static table to achieve the amplification factors shown in Table V. In contrast, for an HBA attack that leverages the dynamic table, the amplification factor is influenced by the number of concurrent streams. The maximum value for concurrent streams is negotiated during the establishment of the HTTP/3 connection. Table VI summarizes the limits set by each CDN on HTTP/3 streams and dynamic tables. All three CDNs that support dynamic tables allow a maximum of 128 concurrent streams, with a dynamic table size of 4KB and a maximum entry size of 3,072 bytes. To explore how the number of concurrent streams affects the amplification factor, we experimented using a single HTTP/3 connection, varying the number of streams from 1 to 140.
4000
Origin Server Bandwidth Consumption (Mbps)
Attacker Bandwidth Consumption (Kbps)
120
Alibaba Baidu Cloudflare CloudFront Fastly Tencent
5000
3000
2000
1000
0 0
10
20
30
40
50 60 Time (s)
70
80
90
100
Alibaba Baidu Cloudflare CloudFront Fastly Tencent
100 80 60 40 20 0
110
0
(a) Bandwidth consumption of the attacker
10
20
30
40
50 60 Time (s)
70
80
90
100
110
(b) Bandwidth consumption of the host website
Fig. 6. Launch an HBA attack lasting 60s.
Alibaba Baidu CloudFront Fastly Tencent
300 200 100 0
Alibaba Baidu CloudFront Fastly Tencent
100
Response Time(s)
Concurrent Connection Number
400
75 50 25 0
0 50 100 150 200 250 300 350 400 450 500 550 600 Time(s)
(a) Number of established CDN-website connections
0 50 100 150 200 250 300 350 400 450 500 550 600 Time(s)
(b) CDNs response time for the benign client’s request
Fig. 7. Launch an HCA attack lasting 300s.
Max Streams Dynamic Table Size Max Entry Size
Alibaba
Baidu
Cloudflare
CloudFront
Fastly
Tencent
128 4KB 3072B
128 4KB 3072B
256 N/A N/A
128 N/A N/A
100 N/A N/A
128 4KB 3072B
We capture traffic on both the client and the host website using tcpdump to evaluate the amplification factor. As shown in Figure 8, the bandwidth amplification factor increases with the number of concurrent streams. The amplification factor peaks at approximately 64 concurrent streams rather than at the maximum of 128, reaching a maximum bandwidth amplification factor of approximately 350×. This is because the CDN must decompress each QPACK-indexed header into its full HTTP/1.1 representation before forwarding, which introduces significant CPU overhead at the CDN edge. When the number of concurrent streams increases beyond this point, the CDN’s processing capacity becomes the bottleneck: subsequent streams must wait for previous streams to complete their header decompression and forwarding, effectively serializing the conversion process and preventing further amplification gains. When the number of streams exceeds the maximum
Alibaba Baidu Tencent
350 Bandwidth Amplification Factor
TABLE VI L IMITS SET BY CDN S ON HTTP/3 STREAMS AND DYNAMIC TABLES .
300 250 200 150 100 50 0
20
40 60 80 100 Number of Concurrent Streams
120
140
Fig. 8. Bandwidth amplification factor when the number of concurrent streams increases.
allowed (128 streams), our HTTP/3 client must additionally wait for previous streams to close before opening new ones, causing the bandwidth amplification factor to fluctuate. V. D ISCUSSION A. Severity Assessment A severe and widespread practical influence. According to our experimental results, the HBA and HCA attacks can effectively exhaust the host website’s bandwidth and connec-
tion resources, respectively. As detailed in Section IV, the CDNs we tested enjoy global popularity and a high market share. These CDNs host a significant portion of websites on the Tranco Top 1M list: our measurement identifies 151,685 subdomains hosted by vulnerable CDNs, of which 42,330 have HTTP/3 enabled and satisfy all prerequisites for our attacks, making them potentially vulnerable. Therefore, many wellknown websites are exposed to the proposed attacks. A low-cost and efficient DoS attack. Unlike other DDoS attacks that need to control a large scale of botnets [3], the attacker only needs an ordinary laptop to launch the HBA and HCA attacks. As the CDN nodes are dispersed globally, they form a naturally distributed amplification infrastructure [4], [21], allowing attackers to easily congest the target network and possibly cause a denial of service in seconds for a negligible cost. Scalability to high-capacity host websites. Our experiments were conducted against a 100Mbps host website due to ethical constraints. However, the amplification ratio is inherent to the HTTP/3-to-HTTP/1.1 conversion mechanism and is independent of the victim’s capacity. The attack scales linearly: since our HBA attack with dynamic tables achieves an amplification factor of approximately 350×, an attacker consuming less than 500Kbps can saturate a 100Mbps host website. Similarly, for the HCA attack, exhausting the connection resources of a higher-capacity host website with more concurrent connection slots simply requires proportionally more HTTP/3 streams, which can be trivially achieved by opening additional HTTP/3 connections. Therefore, our attacks remain practical and effective against well-provisioned production servers. A security challenge to anti-DDoS. Traditional DDoS attacks primarily target the victim’s incoming bandwidth through volumetric flooding. Our attacks, however, exploit legitimate HTTP/3 requests that pass through CDN infrastructure, making them significantly harder to detect and filter. Since the CDN itself is being abused to amplify the attack traffic, the malicious requests appear as normal CDN-to-host-website traffic, posing security challenges for existing DDoS detection mechanisms [31], [38]. B. Ethics and Responsible Disclosure In our research, our goal was to strike a balance between assessing the severity of real-world attacks and minimizing the potential impact on CDN vendors. We were concerned that using excessive bandwidth during evaluation could degrade the CDN network performance and impact other CDN-hosted websites. Therefore, throughout our evaluations, we paid meticulous attention to avoiding any potential ethical issues. Firstly, we strategically chose attacker locations to ensure minimal latency to CDN servers, which allowed attacks to launch within the backbone network. This setup significantly reduced the risk of attack traffic saturating on-path network segments. Secondly, our attacks targeted our own websites, and we strictly controlled the traffic to remain well below the CDN’s overall capacity, thereby preventing any disruption to other websites hosted on the CDN. Thirdly, we limited
the bandwidth of the victim website to 100Mbps to further protect websites hosted on the CDN. These prudent methods ensured that our research effectively enhanced CDN security while minimizing any potential harm. We responsibly contacted six CDN vendors to report all vulnerabilities found in our study, providing detailed reports and mitigations. All vendors acknowledged our disclosure and expressed appreciation. Two vendors, Baidu and Tencent, confirmed the vulnerabilities, rewarded our reports through their bug bounty programs, and have deployed our mitigations. The other vendors expressed gratitude and are still discussing the reported vulnerabilities internally. The responses from CDN vendors are summarized below: Baidu: acknowledged our report, rated the HCA and HBA vulnerabilities as medium-severity and high-severity, with a bug bounty reward of approximately $350, and deployed our mitigations. Tencent: acknowledged our report, rated the HCA vulnerability as medium severity with a bug bounty reward of approximately $150. They deployed our mitigations, which limit the number of CDN-website connections and restrict the size of HTTP headers in the dynamic table. C. Root Cause The root cause of HBA and HCA attacks lies in the fact that CDNs do not support end-to-end HTTP/3. CDNs support HTTP/3 in client-CDN connections, but only HTTP/1.1 for CDN-website connections, even if the host website supports HTTP/3. As a result, when forwarding requests, CDNs must convert HTTP/3 requests to HTTP/1.1. HTTP/3 offers significant efficiency through features like QPACK header compression and multiplexing, but these benefits are lost during this conversion. Worse still, an attacker can then exploit the HTTP/3-to-HTTP/1.1 conversion and HTTP/3 features to launch amplification attacks. D. Mitigation Both HBA and HCA attacks stem from the HTTP/3-toHTTP/1.1 conversion behavior exhibited by CDNs. This conversion persists because CDN providers see a low return on investment for supporting HTTP/3 in CDN-website connections. More critically, current HTTP/3 specifications [5] do not provide clear guidance on securing the HTTP/3-to-HTTP/1.1 conversion behavior. Based on our analysis, we derive the following design principles and concrete mitigations for improving the reliability of CDN services under heterogeneous protocol deployments. Principle 1: Bound the amplification ratio at the protocol conversion layer. The HBA attack exploits the CDN’s conversion of compact QPACK-indexed HTTP/3 headers into verbose HTTP/1.1 headers, resulting in significant bandwidth amplification. To mitigate this, CDNs should enforce limits at three levels: (1) Limit the size of individual HTTP headers in the dynamic table. CDNs should cap the maximum size of any single header field entry that can be inserted into the QPACK dynamic table (e.g., 512B per entry, about the size of a typical
cookie). This prevents attackers from inserting extremely large headers that are later referenced by small index values. Tencent has deployed this mitigation following our disclosure. (2) Restrict the number of times the same header index can be referenced within a single stream. An attacker can reference the same large header hundreds of times within one stream to maximize the amplification factor. CDNs should impose a per-stream reference limit (e.g., no more than 10 references to the same dynamic table entry per stream). This directly caps the amplification ratio regardless of header size. (3) Enforce a maximum decompressed request size. CDNs should set an upper bound on the total decompressed HTTP/1.1 request size (e.g., 64KB). Any request exceeding this threshold after QPACK decompression should be rejected before forwarding to the host website. Principle 2: Validate complete requests before establishing backend connections. The HCA attack exploits the CDN’s eager connection establishment behavior: most CDNs immediately open a CDN-website TCP connection upon receiving an HTTP/3 HEADERS frame, before the full request body arrives. This allows attackers to hold backend connections open indefinitely by slowly trickling DATA frames. We recommend three complementary strategies: (1) Store-then-forward. CDNs should buffer the complete HTTP/3 request (both HEADERS and DATA frames) before establishing a CDN-website connection. This is the approach already adopted by Cloudflare, which makes it immune to the HCA attack, as confirmed by our experiments (Table IV). (2) Limit per-connection backend fan-out. CDNs should restrict the number of CDN-website connections that a single HTTP/3 client connection can trigger. Fastly already implements this strategy by limiting backend connections to the first 10 streams per HTTP/3 connection, which significantly reduces the HCA amplification effect. (3) Enforce CDN-website connection timeouts. CDNs should set strict timeout values for CDN-website connections that are independent of the client-CDN connection lifetime. For example, if no meaningful data is forwarded to the host website within 30 seconds, the CDN-website connection should be terminated. This prevents attackers from holding connections open for arbitrarily long periods (e.g., 300+ seconds in our experiments). E. Anonymity and Cost One may argue that launching these attacks in the real world is unlikely due to associated costs and the risk of exposing the attacker’s identity. However, CDN vendors, presumably for competitive reasons, provide much convenience for their prospective customers (and thus for attackers). Table VII shows the registration information required to begin using the free or free-trial services of the CDN vendors in our study. Three out of six CDN vendors (Baidu, Cloudflare, Fastly) require only a valid email address. CloudFront requires a valid credit card (could be a gift card or stolen). Tencent requires a valid phone number (could be anonymous or disposable). Alibaba requires users to verify their identity through a valid debit card, which takes an attacker more effort to keep
TABLE VII CDN REGISTRATION REQUIREMENTS , COST, AND WEBSITE VERIFICATION .
Requirements Alibaba C1, C2, C4 Baidu C1 Cloudflare C1 CloudFront C1, C3 Fastly C1 Tencent C2
Price
Website Verification
Free trial Free trial Free service Free trial Free service Free trial
No Verification No Verification Domain Blacklist No Verification No Verification No Verification
†
C1 means an email address is required to register an account. C2 means a phone number is required to register an account. ∥ C3 means a credit card is required to register an account. ∗ C4 means a debit card is required to register an account. ‡
anonymous. Moreover, all six vendors offer free or freetrial services, and none of them (except Cloudflare’s domain blacklist) verify website ownership, meaning an attacker can register a victim’s website on the CDN without the victim’s knowledge. Even if CDNs widely adopted website ownership verification, an attacker could still attack any host website that enables HTTP/3 and is hosted on a vulnerable CDN, since such host websites can be targeted directly without registering the victim’s domain. Combined with the minimal bandwidth required on the attacker side (less than 500Kbps for HBA with dynamic tables), the total attack cost is negligible. VI. R ELATED W ORK We describe three categories of related work: CDN security, amplification attacks, and HTTP/3 and QUIC security. A. CDN Security Content Delivery Networks (CDNs) are essential to the modern Internet, handling nearly a fifth of all web traffic. Their critical role has made their security a major research focus. While CDNs are often lauded for their DDoS protection [17], [20], their complex infrastructure and diverse implementations present numerous vulnerabilities that attackers can exploit. This has made studying attacks on CDNs and their host websites a key topic in network security. Previous studies have revealed a wide range of security issues in CDN ecosystems. Previous researchers have explored TLS key management issues on CDN platforms, such as private key sharing and inefficient revocation [7], [26]. Furthermore, attackers can exploit inconsistencies in the interpretation of HTTP header fields between CDNs and websites to manipulate caching mechanisms, leading to cache poisoning [10], cache-poisoned Denial-of-Service (CPDoS) [34], and web cache deception (WCD) attacks [32]. In parallel, researchers have shown that the high reputation and relative invisibility of CDNs can be abused to circumvent Internet censorship, through techniques such as domain fronting [14], domain borrowing [39], domain takeover [27], and domain shadowing [37], which remain in constant competition with evolving censorship mechanisms.
B. Amplification Attack Amplification attacks constitute a well-established area of research within the realm of cybersecurity. Triukose et al. [36] proposed an attack that exhausts the host website’s bandwidth by quickly disconnecting the client-CDN connection. Chen et al. [11] demonstrated that inconsistencies in HTTP request handling policies across CDN vendors could be abused to create request loops among CDN nodes, repeatedly processing malicious traffic and degrading availability. Li et al. [25] demonstrated that amplification attacks exploiting the HTTP Range Request mechanism can achieve amplification factors as high as 43,000 times. Guo et al. [16] found that the compressed headers can be amplified when HTTP/2 downgrades to HTTP/1.1, which causes an amplification attack. Guo et al. [15] further uncovered architectural flaws that allow adversaries to orchestrate pulse-style attack waves against websites through CDN infrastructures. Lin et al. [29] revealed that attackers can abuse format transformation in CDN to drain both website and CDN bandwidth. Lin et al. [28] further uncovered that CDNs’ back-to-origin strategies can be exploited to achieve amplification factors over 100,000. While previous CDN amplification attacks can achieve very high amplification factors, they typically depend on specific configurations or resources on the victim’s side, which significantly limits their real-world attack surface. For example, RangeAmp [25] requires the victim website to enable HTTP Range Request support and host large files (e.g., video or software packages) on the host website; without these prerequisites, the attack cannot be launched. Similarly, CDN Cannon [28] achieves its high amplification factor (over 100,000×) by relying on the victim enabling image optimization features on the CDN and hosting large images (e.g., 4K images) on the host website. CDN Judo [16] exploits the HTTP/2-toHTTP/1.1 header compression conversion, achieving amplification factors of approximately 44× (static table) and 166× (dynamic table). Our HBA attack leverages the analogous HTTP/3-to-HTTP/1.1 conversion but achieves significantly higher amplification factors of up to 66× (static table) and 350× (dynamic table), more than doubling CDN Judo’s results through optimized exploitation of the QPACK dynamic table. In contrast, our attacks impose no special configuration requirements on the victim. The only prerequisite is that the victim website is hosted on a CDN with HTTP/3 support enabled. Critically, as shown in Table I, HTTP/3 is enabled by default on major CDN providers such as Cloudflare and CloudFront, meaning that victims may be vulnerable without any explicit action. This fundamental difference in attack prerequisites results in a significantly broader real-world attack surface: our measurement identifies 42,330 potentially vulnerable subdomains across the Tranco Top 1M, all of which satisfy the attack prerequisites without any victim-side configuration changes. C. HTTP/3 and QUIC Security The security of the QUIC transport protocol and HTTP/3 has attracted growing research attention. Chatzoglou et al. [9]
presented the first comprehensive review of QUIC security and conducted fuzz testing against six production-grade QUIC servers, identifying several zero-day vulnerabilities that can lead to server resource exhaustion. In a follow-up study, Chatzoglou et al. [8] systematically migrated known HTTP/2 attacks to HTTP/3, testing them against six HTTP/3-enabled servers and discovering critical vulnerabilities (e.g., CVE2022-30592). Kosek et al. [22] proposed QUICLORIS, a slow-rate DoS attack targeting the QUIC protocol itself by exploiting slow connection establishment. In a subsequent work, Kosek et al. [23] further analyzed security and service vulnerabilities inherent to HTTP/3 and their implications for network middleboxes. At the transport layer, Nawrocki et al. [33] quantified realworld QUIC-based reflective amplification attacks, demonstrating that QUIC servers are prone to resource exhaustion through spoofed Initial packets. Jabbari et al. [19] proposed QFAM, a mitigation scheme for QUIC handshake flooding attacks, showing that QUIC servers suffer a CPU amplification factor of up to 4.6× compared to TCP. While these studies focus on vulnerabilities in QUIC implementations or the HTTP/3 protocol itself, our work addresses a fundamentally different attack surface: the HTTP/3to-HTTP/1.1 protocol conversion at the CDN layer. None of the above works examine how CDNs’ heterogeneous protocol deployment can be exploited to amplify attacks against host websites. VII. C ONCLUSION In this paper, we present the first study of DoS attacks that exploit the HTTP/3-to-HTTP/1.1 protocol conversion at the CDN layer. We design two novel amplification attacks: the HTTP/3 Bandwidth Amplification (HBA) attack, which achieves amplification factors of up to 66× with the QPACK static table and 350× with the dynamic table, and the HTTP/3 Connection Amplification (HCA) attack, which exploits HTTP/3 multiplexing combined with slow DATA frame transmission to exhaust all available connection resources of the host website. We evaluated both attacks against six major CDN providers: all six are vulnerable to the HBA attack, and five are vulnerable to the HCA attack. A largescale measurement across the Tranco Top 1M domain list identified 151,685 subdomains hosted by vulnerable CDNs, of which 42,330 have HTTP/3 enabled and are potentially vulnerable to our attacks. The root cause lies in the heterogeneous protocol deployment where CDNs support HTTP/3 for client-CDN connections but only HTTP/1.1 for CDN-website connections. Based on this insight, we propose two design principles: bounding the amplification ratio at the conversion layer (against HBA) and validating complete requests before opening backend connections (against HCA), deployed by both Baidu and Tencent following our disclosure. ACKNOWLEDGEMENT We thank all anonymous reviewers for their valuable comments. This work is supported by the Science and Tech-
nology Innovation Key R&D Program of Chongqing (No. CSTB2024TIAD-STX0022) and by the Open Topics from the Lion Rock Labs of Cyberspace Security under project LRL24006. R EFERENCES [1] “User Datagram Protocol,” RFC 768, Aug. 1980. [Online]. Available: https://www.rfc-editor.org/info/rfc768 [2] Akamai, “A coordinated response to madeyoureset http/2 protocol attacks,” 2025, https://www.akamai.com/blog/security/ response-madeyoureset-http2-protocol-attacks. [3] 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 [4] 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,” in 26th USENIX Security Symposium, USENIX Security 2017, Vancouver, BC, Canada, August 16-18, 2017. USENIX Association, 2017, pp. 1093–1110. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity17/technical-sessions/presentation/antonakakis [5] M. Bishop, “HTTP/3,” RFC 9114, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9114 [6] Builtwith, “Content delivery network usage statistics,” 2024, https: //trends.builtwith.com/CDN/Content-Delivery-Network. [7] F. Cangialosi, T. Chung, D. R. Choffnes, D. Levin, B. M. Maggs, A. Mislove, and C. Wilson, “Measurement and analysis of private key sharing in the HTTPS ecosystem,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016. ACM, 2016, pp. 628–640. [Online]. Available: https://doi.org/10.1145/2976749.2978301 [8] 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. [9] E. Chatzoglou, V. Kouliaridis, G. Kambourakis, and C. Kolias, “Revisiting QUIC attacks: a comprehensive review on QUIC security and a hands-on study,” International Journal of Information Security, vol. 22, pp. 1037–1053, 2023. [10] J. Chen, J. Jiang, H. Duan, N. Weaver, T. Wan, and V. Paxson, “Host of troubles: Multiple host ambiguities in HTTP implementations,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016. ACM, 2016, pp. 1516–1527. [Online]. Available: https: //doi.org/10.1145/2976749.2978394 [11] J. Chen, X. Zheng, H. Duan, J. Liang, J. Jiang, K. Li, T. Wan, and V. Paxson, “Forwarding-loop attacks in content delivery networks,” in 23rd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016. The Internet Society, 2016. [Online]. Available: http://wp.internetsociety.org/ndss/wp-content/uploads/sites/ 25/2017/09/forwarding-loop-attacks-content-delivery-networks.pdf [12] Cloudflare, “The cloudflare support http/3.” 2024, https://developers. cloudflare.com/speed/optimization/protocol/http3/. [13] W. Eddy, “Transmission Control Protocol (TCP),” RFC 9293, Aug. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9293 [14] 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 [15] 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,” in 32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023. USENIX Association, 2023. [Online]. Available: https://www.usenix. org/conference/usenixsecurity23/presentation/guo-run
[16] 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 Internet Society, 2020. [Online]. Available: https://www.ndss-symposium.org/ ndss-paper/cdn-judo-breaking-the-cdn-dos-protection-with-itself/ [17] 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. [18] 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 [19] 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. [20] 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. [21] A. Karasaridis, B. Rexroad, and D. A. Hoeflin, “Wide-scale botnet detection and characterization,” in First Workshop on Hot Topics in Understanding Botnets, HotBots’07, Cambridge, MA, USA, April 10, 2007. USENIX Association, 2007. [Online]. Available: https://www.usenix.org/conference/hotbots-07/ wide-scale-botnet-detection-and-characterization [22] M. Kosek, J. S. Kotimur, and V. Bajpai, “QUICLORIS: A slow denialof-service attack on the QUIC protocol,” in Proceedings of the ACM SIGCOMM 2023 Workshop on Protocols for Future Large-scale, Diverse, Real-time Networks. ACM, 2023. [23] M. Kosek, J. S. Kotimur, T. Marshburn, A. Perrig, and V. Bajpai, “Security and service vulnerabilities with HTTP/3,” in 2024 IEEE 13th International Conference on Cloud Networking (CloudNet). IEEE, 2024. [24] 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 [25] W. Li, K. Shen, R. Guo, B. Liu, J. Zhang, and H. D. et al., “CDN backfired: Amplification attacks based on HTTP range requests,” in 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, DSN 2020, Valencia, Spain, June 29 - July 2, 2020. IEEE, 2020, pp. 14–25. [Online]. Available: https://doi.org/10.1109/DSN48063.2020.00022 [26] J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, “When HTTPS meets CDN: A case of authentication in delegated service,” in 2014 IEEE Symposium on Security and Privacy, SP 2014, Berkeley, CA, USA, May 18-21, 2014. IEEE Computer Society, 2014, pp. 67–82. [Online]. Available: https://doi.org/10.1109/SP.2014.12 [27] 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. [28] 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,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 5717–5734. [29] Z. Lin, Z. Lin, X. Liu, Z. Ying, and C. Chen, “Unveiling the bandwidth nightmare: Cdn compression format conversion attacks,” in 2024 2nd International Conference on Big Data and Privacy Computing (BDPC). IEEE, 2024, pp. 97–106. [30] T. List, 2024, https://tranco-list.eu/. [31] Z. Liu, H. Namkung, G. Nikolaidis, J. Lee, C. Kim, X. Jin, V. Braverman, M. Yu, and V. Sekar, “Jaqen: A highperformance switch-native approach for detecting and mitigating volumetric ddos attacks with programmable switches,” in 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, M. Bailey and R. Greenstadt, Eds. USENIX Association, 2021, pp. 3829–3846. [Online]. Available: https: //www.usenix.org/conference/usenixsecurity21/presentation/liu-zaoxing [32] S. A. Mirheidari, S. Arshad, K. Onarlioglu, B. Crispo, E. Kirda, and W. Robertson, “Cached and confused: Web cache deception in the wild,” in 29th USENIX Security Symposium, USENIX Security 2020, August 12-14, 2020. USENIX Association, 2020, pp. 665–682. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity20/presentation/mirheidari
[33] M. Nawrocki, R. Hiesgen, T. C. Schmidt, and M. Wählisch, “QUICsand: Quantifying QUIC reconnaissance scans and DoS flooding events,” in Proceedings of the 21st ACM Internet Measurement Conference (IMC). ACM, 2021, pp. 260–275. [34] H. V. Nguyen, L. L. Iacono, and H. Federrath, “Your cache has fallen: Cache-poisoned denial-of-service attack,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS 2019, London, UK, November 11-15, 2019. ACM, 2019, pp. 1915– 1936. [Online]. Available: https://doi.org/10.1145/3319535.3354215 [35] W. T. Surveys, “Usage statistics of http/3 for websites,” 2025, https: //w3techs.com/technologies/details/ce-http3. [36] S. Triukose, Z. Al-Qudah, and M. Rabinovich, “Content delivery networks: Protection or threat?” in Computer Security - ESORICS 2009, 14th European Symposium on Research in Computer Security, Saint-Malo, France, September 21-23, 2009. Proceedings, ser. Lecture Notes in Computer Science, vol. 5789. Springer, 2009, pp. 371–389. [Online]. Available: https://doi.org/10.1007/978-3-642-04444-1 23 [37] M. Wei, “Domain shadowing: Leveraging content delivery networks for robust blocking-resistant communications,” in 30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021. USENIX Association, 2021, pp. 3327–3343. [Online]. Available: https://www.usenix.org/conference/usenixsecurity21/presentation/wei [38] 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 [39] 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.