Analysis of the GFW's Unconditional Port 443 Block on August 20, 2025

Authors: Mingshi Wu

Date: Wednesday, August 20, 2025

中文版：2025年8月20日中国防火长城GFW对443端口实施无条件封禁的分析

This report was first published on GFW Report. We have also synchronously updated this report on net4people.

1. Introduction

Between approximately 00:34 and 01:48 (Beijing Time, UTC+8) on August 20, 2025, the Great Firewall of China (GFW) exhibited anomalous behavior by unconditionally injecting forged TCP RST+ACK packets to disrupt all connections on TCP port 443. This incident caused massive disruption of the Internet connections between China and the rest of the world (source1 and source2).

This report documents our measurements and analysis of this temporary, widespread blocking event. Our primary findings are:

The unconditional RST+ACK injections was on TCP port 443, but not on other common ports like 22, 80, 8443.
The unconditional RST+ACK injection disrupted connections both to and from China, but the trigger mechanism was asymmetrical. For traffic originating from inside China, the SYN packet from the client and the SYN+ACK packet could each trigger three injected RST+ACK packets. For traffic to inside China, only the server's SYN+ACK response, not the client's SYN packet, could trigger the RST+ACK packets.
The responsible device does not match the fingerprints of any known GFW devices, suggesting that the incident was caused by either a new GFW device or a known device operating in a novel or misconfigured state.

It is important to note that our analysis was limited by the short duration of the incident (approximately 74 minutes). We encourage others in the community to share their observations to build a more complete picture of this event.

2. Triggering the blocking

We first confirmed the blocking by sending probes from a vantage points inside of China (AS45090, Tencent Cloud, Beijing), and from multiple vantage points outside of China.

2.1 Inside-out triggering

In particular, we used the following command to try to establish a TCP handshake with a $NON_CN_IP:

nc -vn $NON_CN_IP 443
nc: connect to $NON_CN_IP port 443 (tcp) failed: Connection refused

We simultaneously used tcpdump to capture traffic:

tcpdump -n host $NON_CN_IP

It appears that the SYN packet triggered three forged RST+ACK packets, each with a relative sequence number 0, as well as incremental TCP window sizes of 1980, 1981, and 1982.

And the SYN+ACK packet sent by the server also triggered three RST+ACK packets, each with a relative sequence number 1, as well as incremental TCP window sizes of 3293, 3294, and 3295.

sudo tcpdump -n host $NON_CN_IP

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:31:07.153262 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [S], seq 3193349615, win 64240, options [mss 1460,sackOK,TS val 318868316 ecr 0,nop,wscale 7], length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 3193349616, win 1980, length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1981, length 0
01:31:07.160021 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1982, length 0
01:31:07.274422 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [S.], seq 2837031664, ack 3193349616, win 65160, options [mss 1424,sackOK,TS val 80839422 ecr 318868316,nop,wscale 7], length 0
01:31:07.274442 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [R], seq 3193349616, win 0, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3295, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3293, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3294, length 0

2.2 Outside-in triggering

Similarly, the RST+ACK packets can be triggered from outside of China. The $CN_IP is an IP address of baidu.com:

11:44:41.194853 IP (tos 0x0, ttl 64, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.162.34500 > $CN_IP.443: Flags [S], cksum 0x418a (incorrect -> 0x252a), seq 3455861170, win 64240, options [mss 1460,sackOK,TS val 134891089 ecr 0,nop,wscale 7], length 0
11:44:41.440817 IP (tos 0x0, ttl 46, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.443 > 192.168.0.162.34500: Flags [S.], cksum 0xd4a2 (correct), seq 1580408478, ack 3455861171, win 8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
11:44:41.440817 IP (tos 0x0, ttl 96, id 40305, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515b (correct), seq 1, ack 1, win 2072, length 0
11:44:41.440817 IP (tos 0x0, ttl 97, id 39808, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515a (correct), seq 1, ack 1, win 2073, length 0
11:44:41.440817 IP (tos 0x0, ttl 98, id 38891, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x5159 (correct), seq 1, ack 1, win 2074, length 0
11:44:41.440901 IP (tos 0x0, ttl 64, id 48748, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.0.162.34500 > $CN_IP.443: Flags [.], cksum 0x4176 (incorrect -> 0x5781), seq 1, ack 1, win 502, length 0

The client outside of China received only three TCP RST+ACK packets, not six. The relative sequence number 1 suggests that the GFW was triggered by the SYN+ACK packet responded by the Chinese server, and the SYN packet didn't trigger the blocking. Indeed, we couldn't trigger the blocking when the sending SYN packets to a Chinese IP address within the same /24 subnet as $CN_IP which didn't have an open port (and thus did not send any SYN+ACK packet back to the client.)

2.3 Affected ports

The RST+ACK injection was confirmed to be specific to TCP port 443. We conducted a partial port scan from a machine inside China (AS45090, Tencent Cloud, Beijing) to an external IP address. We confirmed that other common ports, including 1-72, 22, 80, 444, and 8443, were not affected and did not receive a TCP RST.

nping -4 -c 0 --tcp-connect $NON_CN_IP -p 1-65535

We also ran a scan to probe all ports from 1-65535, but by the time we ran it at 01:48 CST 2025-08-20, we could no longer trigger the blocking anymore:

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

3. Attribution and Device Fingerprinting

The Great Firewall of China (GFW) is not a single entity but a complex system composed of various network devices that perform censorship. Previous research has established that different components, such as those responsible for HTTP Host-based and TLS SNI-based filtering, exhibit unique packet-level fingerprints when injecting TCP RST packets. The goal of this analysis was to identify which specific GFW component was responsible for the anomalous behavior observed during the incident.

To fingerprint the responsible device, after the incident had concluded, we sent probes from the vantage point in China to the IP address that triggered the unconditional RSTs. We used the same destination IP address so that our probe packets would be more likely to traverse the same network path and interact with the same set of censorship middleboxes, allowing for a consistent fingerprint analysis.

Our analysis of the probe results revealed that no captured packet fingerprint exactly matched the characteristics observed during the incident—specifically.

Since the unconditionally injection contain three RST+ACK packets with the IP Flag DF (Don't Fragment) on, they are similar, but not identical, to MB-1 identified by Niere et al. (see Figure 4); and they are also similar to, but not identical to, GFW (II) identified by Wu et al. (see Table 4).

However, a key difference exists: the known middlebox injector sends three identical TCP RST+ACK packets. In contrast, the packets observed during this incident contained fields that were clearly incremental, not identical. This discrepancy suggests that the incident was caused by either a previously uncatalogued GFW device or a known device operating in a novel or misconfigured state.

3.1 Fingerprints of GFW's Unconditional RST+ACK packets

The unconditional RST+ACK packets comes in three packets, with an incrementally increasing IP TTL and an incrementally increasing TCP window size. We limited data, we were not able to identify the IP ID of it.

IP Flag	IP ID	IP TTL	TCP Relative Sequence Number	TCP Flags	TCP Window Size
Don't Fragment	40305 (0x9D71)	96	1	RST+ACK	2072
Don't Fragment	39808 (0x9B80)	97	1	RST+ACK	2073
Don't Fragment	38891 (0x97E3)	98	1	RST+ACK	2074

Table 1: Characteristics of Unconditionally Injected TCP RST Packets

3.2 Fingerprints of the RST packets by GFW's HTTP Host-based censorship devices

curl --resolve youtube.com:80:$NON_CN_IP http://youtube.com

sudo tcpdump -v port 80

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:27:09.790274 IP (tos 0x0, ttl 64, id 12103, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.51506 > $NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [S], cksum 0x630f (correct), seq 3187873750, win 64240, options [mss 1460,sackOK,TS val 329430953 ecr 0,nop,wscale 7], length 0
04:27:09.919296 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [S.], cksum 0xaf88 (correct), seq 155578285, ack 3187873751, win 65160, options [mss 1424,sackOK,TS val 2237542832 ecr 329430953,nop,wscale 7], length 0
04:27:09.919331 IP (tos 0x0, ttl 64, id 12104, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [.], cksum 0xda42 (correct), ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 0
04:27:09.919414 IP (tos 0x0, ttl 64, id 12105, offset 0, flags [DF], proto TCP (6), length 127)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [P.], cksum 0x0926 (correct), seq 1:76, ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 75: HTTP, length: 75
        GET / HTTP/1.1
        Host: youtube.com
        User-Agent: curl/7.81.0
        Accept: */*

04:27:09.923159 IP (tos 0x68, ttl 251, id 31725, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R], cksum 0xc7c6 (correct), seq 155578286, win 42571, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924510 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:10.048400 IP (tos 0x68, ttl 251, id 34753, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [.], cksum 0xd96f (correct), ack 76, win 509, options [nop,nop,TS val 2237542961 ecr 329431082], length 0
04:27:10.048426 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [R], cksum 0x90e0 (correct), seq 3187873826, win 0, length 0

3.3 Fingerprints of the RST packets by GFW's TLS SNI-based censorship devices

curl --resolve youtube.com:443:$NON_CN_IP https://youtube.com

sudo tcpdump -v port 443

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:25:15.234561 IP (tos 0x0, ttl 64, id 59308, offset 0, flags [DF], proto TCP (6), length 60)                                                                                    [0/966]
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [S], cksum 0x579d (correct), seq 2971216783, win 64240, options [mss 1460,sackOK,TS val 329316397 ecr 0,nop,wscale 7], length 0
04:25:15.365226 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [S.], cksum 0x4c87 (correct), seq 2839767305, ack 2971216784, win 65160, options [mss 1424,sackOK,TS val 91287507 ecr 329316397,nop,wscale 7], length 0
04:25:15.365257 IP (tos 0x0, ttl 64, id 59309, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [.], cksum 0x773f (correct), ack 1, win 502, options [nop,nop,TS val 329316528 ecr 91287507], length 0
04:25:15.428628 IP (tos 0x0, ttl 64, id 59310, offset 0, flags [DF], proto TCP (6), length 569)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [P.], cksum 0x9a41 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 329316591
ecr 91287507], length 517
04:25:15.433547 IP (tos 0x68, ttl 251, id 47980, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R], cksum 0x7ed4 (correct), seq 2839767306, win 4547, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434709 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.435139 IP (tos 0x68, ttl 251, id 42431, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xaac5 (correct), seq 1, ack 518, win 1811, length 0
04:25:15.559257 IP (tos 0x68, ttl 251, id 29047, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [.], cksum 0x7435 (correct), ack 518, win 506, options [nop,nop,TS val 91287701 ecr 3293165
91], length 0
04:25:15.559269 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [R], cksum 0xc436 (correct), seq 2971217301, win 0, length 0

4. Ending time

The unconditional RST appeared to stop prior to 2025-08-20 01:48 UTC+8, making the entire incident last for around 74 minutes (between 00:34 and 01:48 UTC+8).

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

Starting Nmap 7.80 ( https://nmap.org ) at 2025-08-20 01:48 CST
Nmap scan report for $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP)
Host is up.
All 65535 scanned ports on $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP) are filtered

5. Acknowledgments

We are grateful to the many users and readers who promptly reported censorship incidents to us. In particular, this censorship event was of a very short duration, and without their timely notifications, it would have been impossible for us to conduct measurements in such a short period. We also thank Eric Wustrow for providing some of the measurement data sent from abroad to within the country.

6. Contact Us

This report was first published on GFW Report. We have also synchronously updated this report on net4people.

We encourage you to share questions, comments, or evidence related to the findings and hypotheses in this report, either publicly or privately. Our private contact information can be found in the footer of the GFW Report website.

Aug 19 '25 23:08 gfw-report

Yeserday, that time, when I use itdog.cn to test, most provinces are fully unaccessible, but some of them are available(means at least one isp ). (I forget to use long time test, sorry).

Aug 20 '25 01:08 maoist2009

I was affected by that port block.

I observed that existing cross-border Internet connections were not affected, while both new IPv4 and IPv6 connections were reset.

Aug 20 '25 02:08 showgood163

Ask them why,

CNCERT/CC contact: [email protected]

Aug 20 '25 03:08 UjuiUjuMandan

disrupt all connections on TCP port 443

All new connections.

I checked my logs and some long running TCP connections were not affected during the reported time.

Aug 20 '25 11:08 klzgrad

Same time interrent connectivity went down in Pakistan on Backbone Provider PTCL AS17557 as noticed by Cloudflare. They also use DPI based Firewall in Pakistan, is this some how related? Source: https://x.com/CloudflareRadar/status/1958138814133920163 and https://x.com/netblocks/status/1957848390349287686

Aug 20 '25 12:08 AzizKamboh

If that's related. Now Pakistani authorities need to be rather cautious. They're handing out their Internet gateway to China, or say, China-based cybersecurity companies.

#510

Aug 20 '25 13:08 UjuiUjuMandan

Same time interrent connectivity went down in Pakistan on Backbone Provider PTCL AS17557 as noticed by Cloudflare. They also use DPI based Firewall in Pakistan, is this some how related?

Wow—good observation, and interesting in light of #510.

The timing of the outage in AS17557 almost lines up with the 443 block in China. But if anything, the outage in AS17557 starts a little earlier. It also lasts longer, several hours.

Network	Cloudflare Radar traffic trends
CN
AS17557

The IODA regional active probing signals for AS17557 are interesting. The regions of Azad Kashmir and Baluchistan do not show any change. The Federal Capital Territory (FCT), North-West Frontier Province (NWFP), Punjab, and Sind show signs of the outage.

The PTCL Twitter account noted the anomaly at 2025-08-19 16:31 and said it was over in another post at 2025-08-20 01:29.

https://x.com/PTCLOfficial/status/1957873019084255347 (archive)

PTCL @PTCLOfficial

Dear Customers,

We are currently facing data connectivity challenges on our PTCL and Ufone services. Our Teams are diligently working to restore the services as quickly as possible. We regret any inconvenience caused.

Aug 19, 2025 · 6:31 PM UTC

https://x.com/PTCLOfficial/status/1957977425377391076 (archive)

PTCL @PTCLOfficial

Dear Customers,

PTCL and Ufone data connectivity has been fully restored. Thank you for your patience.

Aug 20, 2025 · 1:26 AM UTC

Aug 20 '25 14:08 wkrp

@wkrp is it possible that the Firewall Vendor which is Huawei in case of Pakistan pushed some faulty Configuration that also pushed to some Gateways in China. Pakistan does not have regional filtering on Provincial level, its on the National Gateway in Karachi at Submarine Cable Landing Stations. There are two Landing stations under PTCL and one under Transworld. which are only two backbones in Pakistan connecting to outer World. Maybe only one Station under PTCL got hit and China Recovered earlier but PTCL took time as vendor might have prioritized Chinese regions. Source:https://www.intelligenceonline.com/government-intelligence/2025/04/23/china-to-replicate-its--great-digital-firewall--in-pakistan,110438400-art https://www.techradar.com/vpn/vpn-privacy-security/china-is-helping-pakistan-build-a-great-firewall-like-internet-censorship-system-heres-what-you-need-to-know

Aug 20 '25 15:08 AzizKamboh