This thread is to consolidate reports from other threads, particularly #280 (comment) 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.
- The new behavior started on 2023-09-05 (ref ref).
- Only the IP address 1.1.1.1 is affected. The alternative IPv4 address 1.0.0.1 (ref) and the IPv6 addresses 2606:4700:4700::1111 and 2606:4700:4700::1001 (ref) are not affected.
- Only TCP port 443 on 1.1.1.1 is affected. TCP to other ports, such as 53 and 80, as well as UDP, are not affected (ref ref ref).
- Besides being a DoH resolver, 1.1.1.1 is also the home of Cloudflare WARP, which is a VPN-like service. But WARP is apparently unaffected by the new blocking (ref).
- The injection happens whether or not SNI is present. If SNI is present, the value does not matter (ref).
- The injection is triggered by the client's SYN packet.
- This is different from the SNI filtering that has been documented in the past, which is triggered not by the SYN packet but by the TLS Client Hello (which is where the SNI is).
- It is also different from the "interruption" (阻断) of connections to certain IP addresses on TCP port 443, which was triggered by byte pattern matches for TLS, not by the SNI value. (It's not clear to me now whether that TLS "interruption" was done by packet dropping or RST injection.)
- However, see one piece of contrary evidence in this OONI measurement from AS4134 on 2023-09-07, which was reset only after the Client Hello.
- I will make a separate post with specific details of the nature of the RST injection. To summarize:
- Different injection patterns are seen in different packet captures.
- Some have a pattern of 3 RST+ACK packets, sent in response to both the client's SYN and the server's SYN+ACK, with no packet dropping. Within a salvo of 3 injected packets, the IP TTL and TCP window size (ref) are incremental (base, base+1, base+2). The IP ID fields are not incremental but are pretty closely spaced (within a few thousand of each other).
- The 3 RST+ACK packets with incremental TTL and window size match the description of the "type-2 reset" described in "Your State is Not Mine" from 2017, except that all 3 packet have the same sequence number, not different sequence numbers.
- It is also similar to the description in "Ignoring the Great Firewall of China" from way back in 2006, except that then only the RST flag was set (not the ACK flag), as well as the sequence numbers in the 3 packets being different.
- Others have a pattern of 1 RST+ACK in response to the client's SYN, and some form of packet dropping such that the server's SYN+ACK does not arrive at the client. But if the client's SYN does get through (as it does in a small number of cases), then the server's SYN+ACK gets 3 RST+ACKs with incremental IP TTL and TCP window size as in the previous point.
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).
This thread is to consolidate reports from other threads, particularly #280 (comment) 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).