For years, I’ve been immersed in the world of network monitoring systems (Lawful Interception system also), both building them and finding ways to circumvent them. This dual perspective gives me a unique lens to appreciate the monumental work done by the GFW Report team (https://gfw.report/publications/usenixsecurity25/en/?utm_source=Securitylab.ru). Their study, presented at the USENIX Security Symposium 2025, titled “Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China,” dives deep into how China’s Great Firewall (GFW) tackles the QUIC protocol. I can confirm they nailed it—describing exactly how it works. For instance, I’ve seen firsthand that at night, when network traffic is low, it’s far easier to filter, restrict, or even capture data than during the day when data flows are massive. In this article, I’ll walk you through how GFW censors QUIC, its vulnerabilities, and the clever ways anti-censorship communities are bypassing it.
What Is QUIC and Why It Matters
QUIC (Quick UDP Internet Connections) is a cutting-edge transport protocol, developed by Google and standardized by the IETF in 2021 (RFC 9000). It powers HTTP/3, offering low latency, full packet encryption, and congestion control at the browser level. According to Cloudflare, by 2024, over 30% of web requests ran on QUIC, making it a cornerstone of the modern internet.
Having worked with network protocols, I can tell you QUIC is a leap forward from TLS over TCP. It runs on UDP, reducing delays, and encrypts all packets, including the initial one (QUIC Initial), which carries the TLS Client Hello with the Server Name Indication (SNI) field, specifying the server’s domain name. Here’s the catch: while the QUIC Initial packet is encrypted, its key can be derived from public data—Destination Connection ID (DCID) and a version-specific salt. This makes QUIC vulnerable to analysis by passive observers like the GFW.
How the GFW Censors QUIC
In April 2024, I learned about a new GFW tactic: instead of blanket-blocking the QUIC protocol, as it did before, the firewall started selectively censoring connections based on SNI. The GFW Report team confirmed that the GFW now:
Decrypts QUIC Initial packets on the fly: Using the DCID and salt, it extracts the TLS Client Hello contents, including the SNI.
Applies heuristic filters: If the SNI matches a blacklisted domain, the GFW blocks all subsequent UDP packets from the client to the server for 180 seconds.
Blocks based on a tuple: The block uses a combination of (source IP, destination IP, destination port). Server-to-client packets, however, pass through unaffected.
This approach blew me away with its technical sophistication. The GFW isn’t just intercepting packets—it’s analyzing them in real time, which demands serious computational power. But, like any complex system, it has weak spots, which I’ll get to shortly.
The Daily Rhythm of Censorship
My experience tells me that network filters’ effectiveness hinges on traffic load. The GFW Report team found a clear daily cycle: at night (00:00–06:00 China time), when traffic is low, censorship is nearly flawless. During the day, under peak loads, a significant chunk of QUIC connections with blacklisted SNIs slips through. This is due to the high computational cost of decrypting QUIC Initial packets. I’ve noticed this myself—filtering and restricting data is much smoother at night when traffic is light compared to the daytime data deluge.
Port Filtering and Other Quirks
The GFW uses a clever filter: it only blocks connections where the source port is higher than the destination port (e.g., client port > 443). This helps it ignore server traffic, as clients typically use high ephemeral ports (32768–65535). Another quirk is that the GFW doesn’t reassemble fragmented QUIC Initial packets, leaving it vulnerable to bypasses that split SNI across packets. Also, censorship only targets QUIC version 1 (byte pattern 0x00000001), leaving QUIC version 2 unaffected.
The researchers tested non-standard packets and found that the GFW:
Blocks packets with zero-length CRYPTO frames if they contain a blacklisted SNI.
Ignores packets with invalid protocol versions or incorrect authentication tags.
Doesn’t analyze domains in other TLS extensions, like ALPN.
These simplifications remind me of approaches I’ve seen in HTTPS monitoring systems, where SNI is also the primary target. The GFW clearly prioritizes speed over precision, a trade-off I’ve encountered in similar systems.
GFW’s Vulnerabilities: Denial and Degradation Attacks
Availability Attack
One of the most alarming discoveries by the GFW Report team is how the QUIC censorship mechanism can be weaponized for denial-of-service attacks. An attacker forging a victim’s IP address can send a QUIC Initial packet with a blacklisted SNI, triggering a 180-second block of all UDP connections from the victim to the target server. By repeating these packets, the block can be sustained indefinitely.
I was stunned by their experiment:
They spoofed QUIC Initial packets from 32 AWS EC2 instances worldwide, targeting a server in Guangzhou.
In 17 cases, connections were fully blocked; in 7, partially blocked due to asymmetric routes or different GFW nodes. The remaining 8 were unaffected, likely due to varying network paths.
Such an attack could, for example, block external DNS resolvers, causing widespread internet disruptions.
I’ve encountered similar vulnerabilities in filtering systems, and they’re always a concern. The GFW Report team responsibly disclosed this to CNCERT on January 22, 2025. While no direct response came, by March 13, 2025, the GFW stopped blocking incoming QUIC connections, partially mitigating the issue. However, the attack remains viable for traffic originating in China.
Degradation Attack
Another vulnerability that caught my eye is the degradation attack. The GFW Report team showed that flooding the GFW with QUIC Initial packets (even with non-censored SNIs) can overwhelm it, reducing its ability to block connections. Their experiment:
From a U.S. node, they sent packets to a /14 network containing a Chinese server, at rates from 100 to 1500 kpps.
At 1200 kpps, over 60% of connections with blacklisted SNIs went unblocked.
Control tests with random UDP packets of the same length didn’t cause degradation, confirming the issue lies in QUIC processing.
This reminds me of techniques I’ve used to stress-test monitoring systems. The high computational load of decryption makes the GFW vulnerable, especially during peak hours.
Bypassing the Censorship
Having worked on bypassing filtering systems, I always look for ways to exploit architectural weaknesses. The GFW Report team proposed several effective methods, now adopted by anti-censorship communities:
High destination ports: If the destination port is ≥ the source port, the GFW ignores the connection. This can be implemented using iptables to redirect traffic to a high port (e.g., 65535).
Preceding UDP packet: Sending a random UDP packet before the QUIC Initial makes the GFW treat it as the stream’s first packet, ignoring subsequent QUIC packets.
QUIC Initial fragmentation: Splitting SNI across multiple UDP datagrams or QUIC frames prevents GFW analysis. Mozilla Firefox (version 137) and quic-go (v0.52.0) have adopted this.
Connection migration: QUIC allows changing network parameters (IP or port) after the 1-RTT handshake, bypassing blocks.
Encrypted Client Hello (ECH): ECH encrypts SNI with an asymmetric key, invisible to the GFW. It’s unblocked as long as the outer SNI isn’t blacklisted.
Version negotiation: Sending a QUIC Initial with an unsupported version (e.g., QUIC v2) triggers a Version Negotiation packet, and the GFW ignores subsequent packets.
I’ve seen similar tactics work against other censorship systems. Packet fragmentation, for instance, is a classic way to evade deep packet inspection (DPI). The GFW Report team shared these findings with developers of Mozilla Firefox, quic-go, Hysteria, V2Ray, and others. By May 2025, quic-go v0.52.0 implemented SNI-slicing, enabling many tools to bypass censorship seamlessly.
Comparing QUIC Censorship to Other Mechanisms
Analyzing GFW’s blacklists, I noticed the QUIC blacklist covers about 58,000 domains (out of 7 million in the Tranco list), smaller than DNS (107,000), HTTP (105,000), and TLS-SNI (102,000) lists. About 40,000 domains overlap across all lists, while 11,000 are unique to QUIC, with only 2,300 supporting QUIC. This suggests preemptive blocking, anticipating future QUIC adoption.
My experience points to a decentralized GFW architecture. Different censorship mechanisms likely run under separate teams, complicating coordination but broadening coverage.
Ethics and Responsibility
Working on both sides of the censorship fence, I’ve grappled with ethical dilemmas. The GFW Report team handled this thoughtfully:
Availability attack: They tested it only on their own servers to avoid harm. Disclosing it to CNCERT was necessary to protect users.
Degradation attack: Since it only affects GFW infrastructure, they shared it with anti-censorship communities first to avoid aiding censors.
Network monitoring: Experiments used limited TTL and network metrics to avoid impacting third parties.
I share their stance: fighting censorship is justified if it minimizes harm to innocent users.
My journey in network security has taught me that even the most sophisticated systems have flaws. The GFW Report’s work exposed the GFW’s QUIC censorship as both powerful and vulnerable, due to computational limits, simplified packet processing, and port-based filtering. Their degradation and availability attacks highlight these weaknesses, while their bypass methods—from fragmentation to ECH—prove censorship can be overcome.
As someone who’s seen both sides, I’m in awe of the GFW Report team’s rigor. They didn’t just uncover how QUIC censorship works; they handed the anti-censorship community actionable solutions now helping millions. It’s a reminder that in the fight for a free internet, ingenuity and engineering will always have the upper hand.
Top comments (0)