In March 2015, two GitHub pages run by GreatFire.org came under a distributed denial-of-service attack. The same pattern had hit GreatFire’s rented servers earlier that month. The initial public explanation was intuitive: the Great Firewall of China had escalated. Citizen Lab’s subsequent analysis, published in April 2015 and expanded in a USENIX FOCI paper, argued for a narrower and more consequential reading. The attack came from a separate system, co-located with the firewall but architecturally distinct. Citizen Lab named it the Great Cannon.

The distinction is not semantic. It is the difference between a censorship device that can inject packets and an attack device that can drop them, replace them, and use the resulting position to conscript third parties. That difference is what the artifacts actually show, and it is the part most often lost when the episode is retold as “the firewall, weaponized.”

On-path versus in-path: the load-bearing distinction

Citizen Lab describes the Great Firewall as an on-path system. It sits beside the traffic, observes it, and when it sees a request for banned content, it injects forged TCP Reset packets telling both endpoints to stop communicating. The architectural limitation is explicit in the report: on-path systems “can inject additional packets, [but] they cannot prevent in-flight packets (packets that have already been sent) from reaching their destination.” That is why a packet capture of a firewall-triggered block shows both the injected reset and the legitimate server reply arriving afterward.

The Great Cannon, by contrast, is described as an in-path system: “capable of not only injecting traffic but also directly suppressing traffic, acting as a full ‘man-in-the-middle’ for targeted flows.” The researchers demonstrated the suppression capability directly. After receiving a malicious response, they retransmitted the same request over the same connection with the same sequence numbers. Baidu responded normally, treating the retransmission as new data. The original request had never reached Baidu. The Cannon had dropped it.

This is the capability that matters. A censorship middlebox that can only add packets is a filtering device. A middlebox that can remove and replace packets is an interception device. The same physical link can host both, and in the measured paths it did, but they are not the same instrument.

What the Cannon actually did

The observed design is specific, and each design choice has a power consequence.

Targeted by destination IP. The Cannon did not examine all traffic on the link. It intercepted traffic to a set of targeted addresses. When the researchers probed an IP adjacent to the Baidu server (123.125.65.121), the Cannon ignored the requests entirely, while the firewall still acted on censorable requests to that host. Targeting is what made the system tractable at line rate, and it is also what made it selective: the capability was aimed, not ambient.

First data packet only, no reassembly. For a given source address and port, the Cannon examined only the first data packet of a connection. It did not reassemble TCP bytestreams the way the firewall does. It would act on “naked” requests sent without a preceding SYN. The report reads this as more primitive content analysis with significant performance advantages. It also means the trigger condition was shallow enough to be characterized and, in principle, evaded by anyone who understood it.

A flow cache. To avoid re-examining connections, the Cannon kept a flow cache. The researchers’ attempt to fill it suggested capacity of around 16,000 entries for a single sending IP address in their test. This is an implementation detail with an operational implication: the system’s memory of what it had already handled was finite and measurable from outside.

Probabilistic action. In one test, the Cannon ignored all traffic from one of four measurement IP addresses and responded to only 526 of 30,000 requests across the other three, about 1.75%. Censorship systems are normally deterministic; this one was not, at least during this attack. The researchers argue the probabilistic choice occurred at the decision to act on a particular flow, not as a pre-filter. Probabilism complicates characterization from any single vantage point while still producing aggregate volume. It is a design feature, not an anomaly.

The conscription mechanism

The attack worked through ordinary web infrastructure. The Cannon intercepted traffic to Baidu servers hosting commonly used analytics, social, or advertising scripts. When it saw a request for certain JavaScript files on those servers, it took one of two actions: it passed the request through unmolested roughly 98.25% of the time, or it dropped the request before it reached Baidu and returned a malicious script to the requesting user roughly 1.75% of the time.

The requesting user was, in the report’s description, an individual outside China browsing a website that loaded a Baidu-hosted script. The malicious script enlisted that browser as an unwitting participant in the DDoS against GreatFire.org and GitHub. Citizen Lab’s summary is precise: the Cannon “manipulates the traffic of ‘bystander’ systems outside China, silently programming their browsers to create a massive DDoS attack.”

The leverage here was not a state secret. It was the ordinary practice of loading unencrypted third-party scripts from a reachable origin. Any site that embedded such a script made its visitors reachable by whoever could intercept the path to that origin. The Cannon did not need to compromise Baidu’s servers; Baidu denied that its servers were compromised, and the technical evidence is consistent with interception on the path rather than server compromise. The attack surface was the inclusion decision, made by site operators who had no reason to think of it as a security decision.

What was demonstrated and what was inferred

The sources are careful about the boundary, and it is worth preserving.

Demonstrated: the Cannon acted as an in-path system on measured paths, dropping requests before they reached Baidu. It was localized to the same link as the firewall on those paths, between hops 17 and 18 on one path and between hops 12 and 13 on another, at the China Telecom and China Unicom entry points. It shared the firewall’s peculiar TTL side-channel, which the researchers read as evidence of shared code. It acted only on specific destination IPs, only on first data packets, and probabilistically.

Not demonstrated: that the Cannon and the firewall share the same injector device. The researchers checked and “found no evidence that they do.” The shared TTL side-channel is evidence of common code, not of a common device or a single command chain. Collapsing these into “the firewall did it” overstates what the packet captures show.

Attributed with appropriate hedging: the report attributes the system as likely operated by the Chinese government. The Council on Foreign Relations entry describes the actors as “believed to be associated with the government of China.” That is the evidentiary posture, and it should not be hardened into a named unit or individual.

Why the architecture is the governance question

The usual policy conversation after an incident like this asks what a state can do. The more useful question, and the one the artifacts support, is what made the capability effective.

Three things did. First, the Cannon was in-path, which let it suppress and replace rather than merely add. Second, it was targeted, which made it tractable and selective. Third, and most importantly for anyone who operates a website, the attack surface was created by unencrypted third-party script inclusion. The Cannon did not need to reach GitHub’s users directly. It reached them through scripts those users’ browsers were already loading from a third-party origin.

This reframes the governance problem. The relevant question is not only whether a state possesses in-path interception capability. It is also why so much of the web’s ordinary operation routes executable code from third-party origins over paths that any in-path system can rewrite. The Cannon’s operators did not invent that arrangement. They used it.

The sources are narrower than a general “HTTPS solves this” claim. Citizen Lab writes that the capability affords the opportunity to deliver exploits targeting “any foreign computer that communicates with any China-based website not fully utilizing HTTPS,” and elsewhere “not fully protected by HTTPS.” That is a statement about the specific gap, not a universal guarantee. A site that loads scripts over plain HTTP from a reachable origin is exposed in a way that a site loading them over authenticated TLS is not, but the qualification “fully” is doing real work and should not be flattened.

What the episode does not prove

It does not prove a pattern of subsequent use. The retrieved sources document the March 2015 episode and the capability inferences drawn from it. They do not establish that the Cannon has been used in later, unrelated incidents, and the brief should not be extended to claim so.

It does not establish the number of affected users, the geographic distribution of victims, or total attack volume beyond what the quoted passages state. GitHub’s own characterization of the attack’s scale is not in the retrieved set; the blog post from March 2015 was unavailable at retrieval, and secondary summaries should not be substituted for it.

It does not establish a Chinese government statement or response. None is in the retrieved material.

The question it leaves open

The Cannon demonstrated that an in-path system co-located with a censorship middlebox can conscript bystander browsers through the ordinary practice of unencrypted third-party script inclusion. The architectural distinction between on-path and in-path is what made the attack possible; the web’s script-inclusion habits are what made it scalable.

What the episode does not settle is whether the capability was a one-off instrument built for a specific campaign or a durable piece of infrastructure that persists on those links. The packet captures show what it did in March and April 2015. They do not show what it is doing now, and the sources are careful not to claim otherwise. The question that remains is the one the artifacts cannot answer: whether the design choices observed here, targeted, first-packet, probabilistic, and in-path, describe a tool that was stood up for one fight or a permanent addition to the path.

Sources

Total
0
Shares
Share 0
Tweet 0
Pin it 0
Share 0