How the Great Firewall of China ActuallyWorks: DNS Manipulation, Traffic Fingerprinting, and Active Probing
Starting With DNS
The internet is commonly described as a decentralized network, and for the most part, that description is accurate. Data may traverse infrastructure operated by numerous service providers before reaching its destination, and no single organization controls the internet as a whole. That does not mean, however, that an organization positioned along the communication path is powerless to influence what happens to that traffic.
The Great Firewall of China, commonly referred to as the GFW, provides one of the largest real-world examples of this concept. Rather than being a single firewall in the traditional sense, research has documented filtering infrastructure positioned across portions of China’s network boundary that can inspect traffic and selectively interfere with communications between networks in mainland China and the broader internet.
Large-scale measurement studies have identified filtering at multiple layers, including DNS response injection, HTTP filtering, HTTPS filtering based on information exposed during the TLS handshake, passive identification of certain encrypted protocols, and active probing of infrastructure suspected of providing censorship-circumvention services. From a cybersecurity perspective, the interesting part is therefore not simply that websites and services can be blocked. The methods used to determine what traffic should be blocked, and how that determination is made when the traffic itself is encrypted, are considerably more interesting. Taken together, these capabilities make the Great Firewall an excellent case study in an important security concept: Encrypting network traffic does not necessarily make that traffic invisible.
"That does not mean, however, that an organization positioned along the communication path is powerless to influence what happens to that traffic."
Before a client can communicate with most internet services, it first needs to determine where that service is located. If a user enters a domain such as example.com, the system will generally perform a DNS lookup to determine the IP address associated with that hostname. Once the address is obtained, the client can establish a connection to the destination. That process creates an opportunity for interference before the actual application connection has even begun. Traditional DNS was not designed to provide confidentiality. A system positioned where DNS traffic can be observed may therefore determine which domain a client is attempting to resolve. More importantly, an intermediary capable of interfering with that exchange may be able to prevent the client from receiving the correct answer.
Research into the Great Firewall has documented exactly this behavior. A large-scale study presented at USENIX Security in 2021 developed a measurement platform known as GFWatch to study China’s DNS filtering. Over nine months, the researchers tested an average of approximately 411 million domains per day and observed more than 300,000 domains affected by the GFW’s DNS filtering mechanisms. Rather than preventing the original DNS request from reaching the resolver, on-path filtering infrastructure could detect requests containing targeted domain names and inject forged DNS responses containing incorrect IP addresses. Because conventional DNS clients generally accept the first valid-looking response they receive, the forged response can win the race against the legitimate resolver. From the user’s perspective, the result is simple: the requested service does not work. From the network’s perspective, however, the filtering infrastructure did not need to compromise the destination server, decrypt an HTTPS session, or inspect the contents of the requested webpage. It interfered with the mechanism used to locate the service before the application connection was established.
More recent research published in 2025 continued to observe this DNS response-injection behavior, reinforcing that it is not simply a historical artifact of the early Great Firewall. Encrypted DNS technologies such as DNS over HTTPS (DoH) and DNS over TLS (DoT) complicate this particular method of inspection because the domain query itself can be encrypted. That does not necessarily eliminate the ability to identify the destination. It simply forces the observer to look somewhere else.
The Connection Still Has to Go Somewhere
Even when DNS is encrypted, an IP packet still needs to reach another system. Routers cannot forward traffic without knowing its destination, which means that source and destination IP addresses remain fundamental pieces of network-layer information. Filtering based on IP addresses can therefore prevent communication with known infrastructure without requiring visibility into the application protocol itself. Modern internet infrastructure makes this considerably more complicated. Cloud providers, content delivery networks, reverse proxies, and shared hosting platforms allow large numbers of unrelated services to operate behind common infrastructure. An IP address may no longer correspond neatly to a single website or application. Blocking an entire address can therefore affect services that were never intended to be blocked. The more collateral impact a filtering system wants to avoid, the more accurately it needs to understand the traffic passing through it. That is where encrypted traffic becomes particularly interesting.
HTTPS Protects Content, Not Every Characteristic of the Connection
One of the common misconceptions surrounding encrypted communications is that encryption makes a connection completely opaque to anyone positioned between the endpoints. It does not. TLS can provide strong protection for the application data exchanged between a client and server. Someone observing the traffic may be unable to determine the contents of an HTTP request, credentials submitted to an application, messages being exchanged, or files being transferred. The observer can still see the network. Source and destination addresses, ports, packet sizes, timing, connection duration, and other behavioral characteristics may remain observable. Depending on the protocol version and configuration involved, information exchanged while establishing the encrypted session may also provide valuable metadata. Historically, one particularly useful example has been the TLS Server Name Indication, or SNI. SNI allows a client to indicate which hostname it is attempting to reach when multiple websites are hosted behind the same IP address. Traditional SNI is transmitted in the TLS ClientHello before the encrypted application session has been established. Large-scale measurements associated with USENIX Security 2024 demonstrated HTTPS filtering in which the GFW inspected SNI information and interfered with connections associated with censored domains. The connection was encrypted. The destination was still identifiable. That creates an important distinction between reading traffic and classifying traffic. A filtering system does not necessarily need to know exactly what two endpoints are saying to each other. In some cases, identifying what type of communication is taking place is enough.
What If the Traffic Looks Like Nothing?
Circumvention protocols create a more difficult problem. If a protocol has an obvious handshake or unique header, a filtering system may be able to develop a signature for it. One response is therefore to remove recognizable structure entirely. Protocols such as Shadowsocks, VMess, and obfs4 have used approaches intended to make traffic appear highly randomized rather than exposing an easily identifiable protocol signature. Research published at USENIX Security 2023 found that the system did not necessarily need to positively identify exactly which encrypted protocol was being used. Instead, it could use relatively inexpensive heuristics to determine whether traffic resembled common allowed protocols. The researchers identified heuristics involving recognizable protocol fingerprints, the proportion of set bits within data, and the number, location, and proportion of printable ASCII characters in the initial TCP payload. In other words, the filtering system could effectively ask: Does this look like a protocol I recognize? If the answer was no, the fact that the traffic appeared unusually random could itself become part of the fingerprint. Instead of identifying exactly what the protocol is, the system can identify what the protocol is not. For security practitioners, this should sound familiar. Defensive security products routinely use similar reasoning. Network detection systems may not know exactly which malware family generated a connection, but the behavior may differ sufficiently from expected traffic to justify further investigation.
When the Firewall Becomes the Scanner
One of the most technically interesting capabilities documented in research on the Great Firewall is active probing. Suppose monitoring infrastructure observes a connection to an external server and characteristics of that traffic suggest the server may be operating a proxy or censorship-circumvention service. Blocking every suspicious destination immediately would risk significant false positives. Instead, another system can attempt to connect to the suspected server and observe how it responds. This is effectively service fingerprinting. Researchers have documented variations of this behavior for years. Earlier studies identified active probing associated with Tor, while later research documented a combination of passive traffic analysis and active probing against systems suspected of operating Shadowsocks and similar services. The process is conceptually straightforward: first observe the traffic, classify it as suspicious, identify the remote endpoint, connect to that endpoint, provide selected input, observe the response, and determine whether the service behaves like the suspected protocol. If you work in penetration testing, that workflow should look extremely familiar. When we discover an unknown service during an assessment, we rarely stop after identifying the open port. We interact with it. We inspect banners and protocol behavior, provide input, compare responses, and attempt to determine what
software or protocol is actually listening. The Great Firewall provides an interesting inversion of that process. Instead of an attacker fingerprinting an organization’s infrastructure, the network monitoring infrastructure is attempting to fingerprint systems communicating through it. The scale and purpose are very different, but the technical principle is remarkably similar.
Encryption Can Become a Fingerprint
Circumvention protocols have an obvious incentive to eliminate recognizable signatures. If a protocol can be identified by its handshake, remove the handshake. If packet structures are recognizable, randomize them. If a particular port is blocked, move somewhere else. But network communications must still behave like something. The 2023 research into fully encrypted traffic demonstrated that sufficiently randomized traffic can itself become identifiable because normal protocols frequently do not look completely random. This creates a continuing cycle. A protocol develops a recognizable fingerprint. The filtering system learns to detect it. The protocol changes its behavior. The filtering system identifies another characteristic. The protocol changes again. This same pattern appears throughout cybersecurity. Malware developers alter command-and-control traffic when defenders develop reliable signatures. Red teams modify infrastructure and communications as detection engineering improves. Defensive products move away from relying exclusively on static indicators because those indicators are increasingly easy to change. The result is a continuous contest between classification and concealment, and the Great Firewall provides an unusually large-scale example of that contest.
QUIC Changed the Problem Again
The evolution of QUIC provides an excellent example of how this process continues. QUIC forms the transport foundation for HTTP/3 and differs substantially from the traditional TCP and TLS model. Among other changes, QUIC encrypts portions of the initial connection establishment that previously exposed useful information to passive observers. Research presented at USENIX Security 2025 found that the Great Firewall had begun selectively censoring QUIC connections to particular domains beginning in April 2024. Although QUIC Initial packets are encrypted, the cryptographic keys necessary to decrypt an Initial packet can be derived by a passive observer from information available during connection establishment. Researchers found evidence that the Great Firewall was doing exactly that at scale. The system could derive the necessary information, decrypt the QUIC Initial packet, recover the TLS ClientHello, inspect the SNI, and apply filtering rules to the connection. This development demonstrates that protocol evolution does not simply make filtering impossible. It changes the engineering problem, and the filtering system has to become more sophisticated as well. Researchers also found that this additional complexity came with a cost: performing QUIC decryption created computational overhead that could reduce the effectiveness of the censorship mechanism under sufficient traffic load.
That is another important security lesson. More sophisticated inspection provides greater visibility, but greater visibility generally requires additional computation. At national scale, those tradeoffs matter.
Encryption and Concealment Are Different Security Properties
This is perhaps the most useful lesson from the Great Firewall for security practitioners. Encryption is designed primarily to protect the confidentiality and integrity of information. It prevents an unauthorized observer from simply reading the communication between two endpoints. Concealment is a different problem. A connection can be strongly encrypted while still revealing that communication is taking place, which systems are communicating, how frequently they communicate, how much information is being transferred, and characteristics that may indicate which protocol is being used. For an attacker attempting to maintain command-and-control infrastructure, those details matter. For a red team attempting to emulate that attacker, they matter just as much. For a defender attempting to identify malicious communications inside a large network, they can be extremely valuable. A defender may not need to decrypt a suspicious connection if the surrounding network behavior provides sufficient evidence to investigate it. DNS activity, destination infrastructure, connection timing, protocol characteristics, certificate information, endpoint telemetry, and other sources of evidence can collectively provide visibility even when the application payload remains protected. In that sense, the Great Firewall demonstrates the same principle at an unusually large scale.
You Do Not Always Need to Read the Traffic to Understand It
The Great Firewall of China is most commonly discussed in the context of internet censorship. While censorship is obviously central to its purpose, focusing exclusively on which websites are blocked overlooks much of what makes the system technically interesting. From a network-security perspective, it demonstrates what becomes possible when multiple forms of network visibility and control are combined. DNS can reveal where a client intends to communicate and, when intercepted, can provide an opportunity to redirect or disrupt that communication before it begins. Network-layer information can reveal where traffic is actually going. TLS metadata can provide information about the intended destination even when the application traffic itself is encrypted. Protocol behavior can provide clues about the application generating the traffic. Statistical analysis can identify characteristics of traffic that deliberately attempts to look random. When passive analysis is insufficient, active probing can potentially provide additional information about the remote service. As newer protocols such as QUIC remove information that was previously visible, filtering infrastructure can evolve to inspect those protocols in entirely new ways. No single technique needs to provide perfect visibility. Each provides another piece of information. That concept extends far beyond the Great Firewall. The same fundamental principles appear in network defense, intrusion detection, malware analysis, threat hunting, red-team command-and-control, and penetration testing.
Encryption remains one of the most important security controls available to us, but it is important to understand precisely what it provides. Encryption can prevent an observer from reading the conversation. It does not necessarily prevent the observer from understanding what kind of conversation is taking place. For security practitioners, that distinction matters. You do not always need to decrypt network traffic to understand it.
References
[1] Hoang et al. — “How Great is the Great Firewall? Measuring China’s DNS Censorship.” USENIX Security
Symposium, 2021. https://www.usenix.org/conference/usenixsecurity21/presentation/hoang
[2] Hoang et al. — “Measuring the Great Firewall’s Multi-layered Web Filtering Apparatus.” USENIX ;login:,
2024. https://www.usenix.org/publications/loginonline/measuring-great-firewall%E2%80%99s-multi-
layered-web-filtering-apparatus
[3] Wu et al. — “How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic.” USENIX
Security Symposium, 2023. https://www.usenix.org/conference/usenixsecurity23/presentation/wu-
mingshi
[4] Zohaib et al. — “Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China.”
USENIX Security Symposium, 2025.
https://www.usenix.org/conference/usenixsecurity25/presentation/zohaib
[5] Sheffey et al. — “I’ll Shake Your Hand: What Happens After DNS Poisoning.” FOCI, 2025.
https://gfw.report/publications/foci25/en/
Josh Poirier
Josh is a Senior Security Consultant at Rotas Security.