wkrp
commented
9 months ago I will make a separate post with specific details of the nature of the RST injection.
The fact of the GFW terminating TCP connections by injecting 3 RST packets has been documented repeatedly. However, this recent injection regarding 1.1.1.1:443 is different from what I remember having been reported before. (Please correct me if I am wrong.) The main difference is that, instead of the 3 injected packets all having different sequence numbers, separated by certain intervals, in this case all 3 have the same sequence number. Also, I believe that both the client's SYN and the server's SYN+ACK triggers 3 RSTs, for 6 injected packets in total.
"Ignoring the Great Firewall of China" (2006) described 3 RST packets being sent in both directions (3 to the client, 3 to the server), with sequence numbers base, base+1460, base+4380.
The first three reset packets had sequence values that corresponded to the sequence number at the start of the GET packet, that value plus 1460 and that value plus 4380 (3 × 1460). We believe that the firewall sends three different values to try and ensure that the reset is accepted by the sender, even if the sender has already received ACKs for “full-size” (1460 byte) packets from the destination. Setting the sequence value of the reset packet “correctly” is necessary because many implementations of TCP/IP now apply strict checks that the value is within the expected “window”.
We also examined this blocked connection from the point of view of the Chinese webserver… As can be seen, when the “bad” packet was detected, the firewall also sent resets to the Chinese machine…
"Your State is Not Mine" (2017) reports something similar, which they call a "type-2 reset". The difference is that now the RST+ACK flags are set, not just RST. They also describe a "type-1 reset", which is sent 1 at a time, not 3, and does not have the ACK flag set. The spacing between sequence numbers is the same base, base+1460, base+4380 as in 2006. The "type-2 resets" are also noted to have IP TTLs and TCP window sizes that are incremental (base, base+1, base+2) within a salvo of 3.
Once any sensitive content is detected, the GFW injects RST (type-1) and RST/ACK (type-2) packets to both the corresponding client and the server to disrupt the ongoing connection and sustains the disruption for a certain period (90 seconds as per our measurements). …
According to previous work [3, 25] and our measurements, RST (type-1) and RST/ACK (type-2) are likely from two types of GFW instances that usually exist together. … Type-1 reset has only the RST flag set, and random TTL value and window sizes, while type-2 reset has the RST and ACK flags set, and cyclically increasing TTL value and window sizes.
Once a sensitive keyword detected, the GFW sends one type-1 RST and three type-2 RST/ACK with sequence numbers X, X+1460 and X+4380 (X is the current server-side sequence number).
Some other pieces of research that discuss GFW RST injection: https://censorbib.nymity.ch/#Crandall2007a, https://censorbib.nymity.ch/#Park2010a, https://censorbib.nymity.ch/#Xu2011a.
The pcap I have looked at (captured at the client in China) has two noteworthy features:
- There are 3 RST+ACK packets after the client's SYN. All 3 have a seq number equal to 0 and an ack number equal to the client's initial sequence number + 1.
- There are another 3 RST+ACK packets after the server's SYN+ACK. (Because this form of censorship uses only injection, and not packet dropping, the firewall does not prevent the client's SYN from reaching the real server, nor the server's real SYN+ACK from reaching the client.) All 3 have a seq number equal to the server's initial sequence number + 1, and an ack number equal to the client's initial sequence number + 1.
As noted above, the fact that sequence numbers are the same within each salvo of 3 injected packets is different from what has been seen before. It also appears to me that both the client's SYN and the server's SYN+ACK are triggers for injection. The injected packets are sent in both directions, so each side is likely to see 3 + 3 = 6 total injected RST+ACK packets.
Apart from the sequence numbers, TCP window sizes and IP TTLs are incremental within each salvo of 3, which is consistent with "Your State is Not Mine." Here is a summary of the pcap, showing 3 connection attempts:
| trial # | timestamp | direction | flags | seq | ack | win | ttl | comment |
|---|---|---|---|---|---|---|---|---|
| 1 | 0.000 | C→S | SYN | cseq1 | 0 | 64240 | 64 | client's real SYN |
| 1 | 0.008 | S→C | RST+ACK | 0 | cseq1+1 | 4229 | 65 | injected |
| 1 | 0.008 | S→C | RST+ACK | 0 | cseq1+1 | 4231 | 67 | injected |
| 1 | 0.008 | S→C | RST+ACK | 0 | cseq1+1 | 4230 | 66 | injected |
| 1 | 0.248 | S→C | SYN+ACK | sseq1 | cseq1+1 | 65160 | 47 | server's real SYN+ACK |
| 1 | 0.248 | C→S | RST | cseq1+1 | 0 | 0 | 64 | client's real RST |
| 1 | 0.250 | S→C | RST+ACK | sseq1+1 | cseq1+1 | 162 | 191 | injected |
| 1 | 0.250 | S→C | RST+ACK | sseq1+1 | cseq1+1 | 163 | 192 | injected |
| 1 | 0.250 | S→C | RST+ACK | sseq1+1 | cseq1+1 | 164 | 193 | injected |
| 2 | 2.288 | C→S | SYN | cseq2 | 0 | 64240 | 64 | client's real SYN |
| 2 | 2.296 | S→C | RST+ACK | 0 | cseq2+1 | 3909 | 145 | injected |
| 2 | 2.296 | S→C | RST+ACK | 0 | cseq2+1 | 3910 | 146 | injected |
| 2 | 2.296 | S→C | RST+ACK | 0 | cseq2+1 | 3911 | 147 | injected |
| 2 | 2.508 | S→C | SYN+ACK | sseq2 | cseq2+1 | 65160 | 47 | server's real SYN+ACK |
| 2 | 2.508 | C→S | RST | cseq2+1 | 0 | 0 | 64 | client's real RST |
| 2 | 2.511 | S→C | RST+ACK | sseq2+1 | cseq2+1 | 187 | 216 | injected |
| 2 | 2.511 | S→C | RST+ACK | sseq2+1 | cseq2+1 | 188 | 217 | injected |
| 2 | 2.511 | S→C | RST+ACK | sseq2+1 | cseq2+1 | 189 | 218 | injected |
| 3 | 3.428 | C→S | SYN | cseq3 | 0 | 64240 | 64 | client's real SYN |
| 3 | 3.435 | S→C | RST+ACK | 0 | cseq3+1 | 3631 | 67 | injected |
| 3 | 3.435 | S→C | RST+ACK | 0 | cseq3+1 | 3632 | 68 | injected |
| 3 | 3.435 | S→C | RST+ACK | 0 | cseq3+1 | 3633 | 69 | injected |
| 3 | 3.668 | S→C | SYN+ACK | sseq3 | cseq3+1 | 65160 | 47 | server's real SYN+ACK |
| 3 | 3.668 | C→S | RST | cseq3+1 | 0 | 0 | 64 | client's real RST |
| 3 | 3.670 | S→C | RST+ACK | sseq3+1 | cseq3+1 | 199 | 228 | injected |
| 3 | 3.670 | S→C | RST+ACK | sseq3+1 | cseq3+1 | 200 | 229 | injected |
| 3 | 3.670 | S→C | RST+ACK | sseq3+1 | cseq3+1 | 201 | 230 | injected |
Notice that the injected packets' seq values are equal within a salvo, and that win and ttl values are incremental (e.g. win=3909,3910,3911; ttl=145,146,147). It's also interesting that the window sizes are in the 3000–5000 range for the C→S direction, and in the 100–300 range in the S→C direction; I don't know if that pattern holds in general.
At https://github.com/net4people/bbs/issues/280#issuecomment-1712403769 it was reported that the injected RSTs' seq value could all be either 0 or a fixed value. (See the follow-up note about relative sequence numbers: what was reported as a sequence number of "1" actually means the client's initial sequence number + 1.) If my guess is right, the cases with seq=0 were triggered by the client's SYN, and the cases where seq is some other fixed value were triggered by the server's SYN+ACK.
RPRX
flowerinsnowdh
klzgrad
mmmray
bmixonba
5e2t
This thread is to consolidate reports from other threads, particularly https://github.com/net4people/bbs/issues/280#issuecomment-1706267069 and #284, as well as information received privately.
In summary: since 2023-09-05 (about 06:00 UTC), there is new RST injection of https://1.1.1.1/ (which, notably, is a DNS over HTTPS resolver. 1.1.1.1 may have been blocked in other ways in some regions before; but there was definitely a change starting 2023-09-05. The RST injection resembles some of the "classic" RST injection that has been documented in China in the past, but there are some differences. It also differs from the well-known SNI filtering, in that the injection is triggered by the client's TCP SYN packet, not the TLS Client Hello.
Blocking of 8.8.8.8:443 (Google's DNS over HTTP resolver) is unrelated. It is blocked by packet dropping / null routing, not RST injection (ref).