A second look at how connections die
Consider a phone call that drops the instant the other party picks up. Neither caller gets an explanation, and both are left guessing whether the line was faulty, the receiver hung up, or someone deliberately intervened. On the Internet, that abrupt silence happens far more often than most people realize.
Cloudflare’s position in the network stack gives us a rare vantage point for diagnosing these failures. When a connection dies before any useful data is exchanged, the sequence of TCP resets and timeouts often leaves a detectable trace. These traces are not always accidental; an external party that intentionally interrupts a connection usually leaves behind clues in the protocol that can be used to identify tampering.
Not all tampering is government censorship. Enterprises block outbound connections to phishing and spam domains. ISPs enforce court orders or regulatory mandates. Governments impose large-scale information controls. Whatever the motivation, the practice has been widely acknowledged but never so thoroughly measured across jurisdictions. We believe closing that gap matters for transparency and for the long-term health of the Internet.
Our full methodology was peer-reviewed and published as “Global, Passive Detection of Connection Tampering” at ACM SIGCOMM. We are also releasing a Cloudflare Radar dashboard and API that provides near real-time visibility into the two dominant tampering mechanisms: connection resets and timeouts.
The global baseline
About 20% of all connections to Cloudflare’s network close before any useful data is exchanged. That figure is surprisingly consistent across the globe.
Via Cloudflare Radar
Not all of those failures are tampering, of course. The challenge is separating intentional interference from the routine noise of a congested or faulty network.
To do that, we analyzed the TCP behavior of every connection to our network and identified 19 distinct patterns that could be signatures of tampering. Of those, 14 had been previously reported by active, on-the-ground measurement efforts. That prior reporting gave us an opportunity to validate our macro-level approach: if our passive signatures align with the same locations where active measurements found tampering, we can trust those signatures in places where no measurements have been taken. To avoid confirmation bias, we scanned globally rather than focusing on known hotspots.
What the signatures show
The table below, from our peer-reviewed study, plots the prevalence of each signature by country of origin. The data covers a two-week interval beginning January 26, 2023. The column labeled ⟨PSH → RST;RST0⟩, for instance, shows that signature appearing almost exclusively on connections from China.
Figure 1: The proportion of connections matching each signature, broken down by country of origin.
Comparing our results with prior public reports shows a strong overlap, which gives us confidence that the methodology is sound. But normalizing by population rather than raw connection counts surfaces more useful patterns.
The three most populous countries by number of Internet users—China, India, and the United States—each contribute substantial portions of signature matches. China appears among the top sources for nine signatures, reinforcing prior findings that the Great Firewall is not a single system but a patchwork of different blocking implementations. India also shows up significantly across nine signatures, five of which overlap with China's. The United States shows a visible but smaller proportion of matches on nearly every signature except two.
Looking at signature distribution per country, rather than global volume, reveals more granular patterns.
Figure 4: Percentage of connections from a select country matching a particular signature or showing no signs of tampering.
Ignoring the noisiest signature ⟨SYN → ∅⟩, which often reflects low-rate SYN floods rather than tampering, several countries stand out. Turkmenistan matches a tampering signature on roughly 80% of connections; Iran on 40%, and Russia and China on about 30%. Peru and Mexico show surprisingly high match rates of roughly 50% and 25%, respectively, which deeper analysis of individual networks suggests is tied to zero-rating in mobile and cellular plans: ISPs may be permitting connections to whitelisted services while interrupting others. By contrast, Great Britain, the United States, and Germany all sit below the global average at around 10%.
Connection tampering, it turns out, is not only widespread but often closer to users than most realize. Understanding its signatures is the first step toward measuring, and ultimately relying on, the Internet as an open and dependable medium.
Tampering by name, not by number
Connection tampering is a blunt instrument: a third party can only suppress access to a specific identity — most often a domain name — even when its real intention is to block a category of content. This is possible only because of an accident of protocol design. The domain name a client wants is transmitted in cleartext in the TLS server name indication (SNI) field, visible to any observer on the path.
The architecture that makes this observable is easier to grasp with a telephone analogy. The Internet’s connection-oriented protocols behave more like the plain old telephone system than like the postal system. A TCP connection is initiated to an IP address — the “number” being dialed — and only after the connection is established does the client reveal the name it seeks, in the SNI. The connection itself is logical, identified by metadata that does not name the parties, and a new connection is required for each subsequent visit, just as a new call is required to speak again.
A telephone company ordered to prevent calls to a particular party has limited options. It can manipulate directories so callers never obtain the number — the equivalent of DNS filtering. Or it can block the number outright, which has collateral damage just like IP blocking. But once a call is underway, the only way to know who is actually being called is to listen for the caller to ask for a person by name. That is because the number dialed has never guaranteed who answers; a parent may give a child a phone, or a taxi company may leave its phone with whoever is on shift. So the phone company must listen in, and when it hears a forbidden name it can cut the call, leaving both sides in the dark. That is precisely connection tampering on the Internet.
On the Internet, the third party must likewise “look inside” packets as they flow. Instead of listening for a name, it watches for the SNI, which is exposed as an unintended side effect of the encryption handshake. When the name is objectionable, the third party drops packets or injects crafted messages that cause one or both devices to abort the connection.
The mechanisms begin with deep packet inspection (DPI), which examines data beyond the addressing and connection metadata. DPI is not cheap; whether run on an ISP’s router or a parental proxy, it becomes more expensive at scale and at high speed. And the same weaknesses that plague telephone tampering appear here: the sound of “Jean” and “Gene” are indistinguishable, just as a rule targeting Twitter’s shortener t.co has been known to hit unrelated domains like microsoft.com.
A live view during the Mahsa Amini protests
Transparency motivated this effort, but it was the data observed during the Mahsa Amini protests in Iran in 2022 that drove Cloudflare to commit to publishing tampering signals on Radar. The figure below shows connections from Iran over 17 days overlapping the protests, tracking signatures of different types of connection tampering. The data predates the Radar service and comes from a peer-reviewed paper; it was the first visual illustration of what the data could show if shared publicly.
Two observations stand out. First, the signature-match rates are stable before the protests and rise after they begin. Second, the lines diverge over time — notably the light gray, dark purple, and dark green traces — suggesting the underlying mechanisms, or the traffic that triggers them, changed. A signature match alone does not prove tampering, but in Iran in 2022 public reports documented SNI-based blocking of content, and those reports matched what is visible in the figure.
The current Radar view for the twelve months from August 2023 to August 2024 tells a more nuanced story. TCP connection anomalies in Iran are below worldwide averages overall, but the “Post ACK” phase — the light-blue region often associated with SNI-based blocking — is significantly elevated. The changing proportions of the traces since mid-December 2023 indicate that the techniques in use have been evolving over time.
Passive measurement in an open community
This work builds directly on the censorship measurement community, and was produced in collaboration with researchers at the University of Maryland, École Polytechnique Fédérale de Lausanne, and the University of Michigan. Most prior measurement efforts are active: researchers send crafted probes into networks to identify blocking behavior. Active measurement has known strengths and weaknesses, as detailed in the paper.
The project’s focus is passive measurement — an “observe and do nothing” approach that depends on having a vantage point inside a large network operator. Passive measurement alone cannot see everything, but it is most effective when combined with active methods to paint a more complete picture of the impact on users. Whatever the method, the safety of the measurement must be evaluated carefully, since the risks imposed on people and networks are often indirect or hidden.
What the data can and cannot show
As passive observers of connections to the Cloudflare network — and only that network — the insights are bounded by three limits:
- Signs of tampering, but not where it happened. Any device between the client and the server can tamper, from purpose-built systems to enterprise firewalls, home broadband routers, or protection software on personal computers. Only the connection’s origin can be inferred, and geolocation is inherently imprecise.
- Often, but not always, what triggered tampering — but not why. Tampering systems are typically rule-based, triggered by domains, keywords, or regular expressions. Repetition and manual inspection may reveal the likely trigger, but not the reason it was chosen. The
t.coexample above shows how easily such systems produce unintended consequences. - Who and what is affected, but not who or what could be affected. If 1000 out of 1001 connections to
example.comshow signs of tampering, it is reasonable to expect the next attempt will also fail. But that observation says nothing about connections toanother-example.com.
How to separate tampering from ordinary failures
The detection methodology rests on inspecting sets of packets within a TCP connection against a catalog of 19 hand-crafted connection tampering signatures. These were derived from patterns in prior research and from manual analysis of anomalous connections to Cloudflare’s network — that is, connections that closed early and ungracefully via a reset or timeout within the first 10 packets from the client. In samples reviewed, those 19 patterns accounted for 86.9% of all possibly tampered connections.
Beyond the raw patterns, the signatures group by which point in a connection’s lifetime tampering appears, and each stage says something about the responsible party:
- Post-SYN (mid-handshake): The likely trigger is the destination IP address, since the middlebox typically has not seen application data yet — that data only flows after the handshake completes.
- Post-ACK (immediately after handshake): The connection is established and then immediately closed before any data is exchanged. The middlebox has probably seen at least one data packet carrying something like an HTTP host header or a TLS SNI field.
- Post-PSH (after first data packet): The middlebox has definitely seen the first data packet, and may have been waiting for one with the PSH flag set (which indicates the data should be delivered to the application immediately). This points to a monster-on-the-side: the offending packet was allowed through to the destination before the reset was sent.
- Later-in-flow (after several data packets, but still within the first 10): Tampering this late is the least likely stage for encrypted TLS traffic, since a middlebox would need some way to see inside the connection. Plausible triggers are cleartext keywords appearing later in HTTP traffic, or software like enterprise proxies and parental controls that can inspect encrypted traffic and reset on certain content.
Ruling out innocent explanations
Passive observation means no full visibility into client behavior, so absolute positives are unattainable. Instead, the goal is strong positive evidence of tampering, which begins by identifying false positives. Several sources of client-side behavior can mimic tampering, and all but the last occur before any data packets are received:
- Scanners probe servers to elicit responses; some use fixed header bits to self-identify, which simplifies filtering. For example, Zmap accounts for about 1% of all
⟨SYN → RST⟩signature matches. - SYN flood attacks could also match Post-SYN signatures like
⟨SYN → ∅⟩and⟨SYN → RST⟩, though these are less likely in data collected after DDoS protection systems have already intervened. - Happy Eyeballs clients start IPv6 and IPv4 connections concurrently and keep the winner. Clients that kill the loser with a RST instead of a FIN can produce the
⟨SYN → RST⟩signature. - Browser-triggered RSTs (for example, from closing a tab) can occur at any stage, especially later in a flow, but they are unlikely to be biased toward particular services or websites, unlike targeted tampering.
Isolating these false positives from real third-party interference requires looking at individual bits in the IP header for corroborating evidence.
Evidence in the headers
A signature match alone is not a determination. If tampering is targeted, there should be other markers in common across matching connections — in location, in time, or in the headers of adjacent packets.
Two header fields provide particularly strong supporting evidence. The IP-ID field in IPv4 is usually a fixed per-connection value, often incremented by the client for each subsequent packet. Large jumps in IP-ID between consecutive packets from the same client are unexpected in normal flows and indicate packet injection — visible at marker (a) in the figure above for a subset of signatures.
The Time-to-Live (TTL) field offers a second clue. Most client implementations set the same initial TTL (commonly 64 or 128), decremented at each router hop. If a RST packet arrives with a TTL different from other packets in the same connection, it strongly suggests a third party injected it — see marker (b) in the figure.
High maximum IP-ID and TTL differences are positive evidence of tampering. But absence of these signals is not proof that tampering did not happen: some middlebox implementations are known to copy IP-ID and TTL values from packets in the original connection. The headers are a check for indicative value in the dataset, not a complete proof.
Finally, the signatures themselves have blind spots. Tampering that occurs after the first 10 packets escapes detection entirely (the sample window stops there). Other gaps include FIN injection — a less common alternative to RST — connections where all packets are dropped before they reach Cloudflare, and UDP-based protocols such as QUIC, to which these TCP-oriented signatures do not apply. Expanding coverage for those cases is noted as future work.
Connection Anomalies in the Wild
To illustrate what third-party connection tampering looks like in practice, we compared Cloudflare's network data against OONI reports of connection disruptions in several countries. These case studies show how server-side TCP anomaly patterns align with independently documented blocking events.
Pakistan: A Sudden Shift in Mobile Traffic
Reports from within Pakistan described changing Internet conditions throughout August 2024. Cloudflare data confirms a dramatic shift beginning August 9, 2024, when Post-ACK connection anomalies — connections that appear to be disrupted after the TCP handshake completes — spiked sharply.
This spike is almost entirely attributable to AS56167 (Pak Telecom Mobile Limited). Post-ACK anomalies for that network jumped from under 5% to over 70% of all connections and have remained elevated since. At the same time, the number of successful HTTP requests reaching Cloudflare from AS56167 clients dropped significantly — a clear indication that connections were being actively disrupted.
This case highlights the importance of corroborating user-side reports with network-side observations, a theme discussed in more detail in the Radar dataset release.
Tanzania: Timeouts After Client Hello
An OONI report from April 2024 described targeted connection tampering in Tanzania. The report characterized the blocking as client-side connection timeouts following the Client Hello message during the TLS handshake — a pattern consistent with a middlebox silently dropping the packet containing the Client Hello.
From the server side, such tampering manifests as Post-ACK timeouts, since the PSH packet carrying the Client Hello never arrives. Cloudflare's data matches this description: close to 30% of all new TCP connections from Tanzania appear as Post-ACK anomalies. Of those, roughly one-third are timeouts (consistent with the OONI report), with the remainder being RSTs.
Ethiopia: Elevated Post-PSH Anomalies
Ethiopia has also been previously identified as a location with connection tampering. Cloudflare's data shows elevated rates of Post-PSH TCP anomalies across Ethiopian networks, with RSTs accounting for the majority of these anomalies and timeouts also present.
Most traffic arriving at Cloudflare from Ethiopian IP addresses originates from AS24757 (Ethio Telecom), so its anomaly distribution closely mirrors the country-wide picture. Meanwhile, AS328988 (SAFARICOM TELECOMMUNICATIONS ETHIOPIA PLC) shows a higher proportional rate of Post-PSH anomalies, affecting over 33% of all connections from that network.
Looking Forward
Connection tampering is a pervasive blocking mechanism deployed in many forms across the Internet. While network-level data helps detect and understand these disruptions globally, the user experience remains as individual as an interrupted phone call.
It's worth noting that much of this tampering is possible by accident of protocol design — it works because domain names in the TLS handshake are visible in cleartext. That may not always be the case. Encrypted Client Hello (ECH), an emerging standard, encrypts the SNI field and could close this visibility gap.
Additional connection anomaly data is now available on Cloudflare Radar, along with the accompanying blog post. For deeper technical detail, see the peer-reviewed paper and its 15-minute summary talk. Regions and networks not covered here can be explored via the new Radar datasets.
