Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The blocking of 1.1.1.1 in China, starting from 2023-10-01 #295

Open
gfw-report opened this issue Oct 1, 2023 · 13 comments
Open

The blocking of 1.1.1.1 in China, starting from 2023-10-01 #295

gfw-report opened this issue Oct 1, 2023 · 13 comments
Labels
China

Comments

@gfw-report
Copy link
Contributor

gfw-report commented Oct 1, 2023 •
edited
Loading

There have been many reports of a blocking of 1.1.1.1 in China, starting from October 1, 2023.

As discussed in issues #285, China injected TCP RST packets to block 1.1.1.1:443 from September 5 to 20, 2023.

Major observations

Below is our observation from a VPS in Tencent Cloud Beijing (ASN AS45090) on October 1, 2023:

  • Different from @5e2t 's observation, we have not been able to observe the TCP RSTs on the 1.1.1.1:443 from our vantage point. In particular, we can successfully retrieve a complete webpage using curl -v https://1.1.1.1. This shows inconsistency of this new censorship incident across different geo-locations or ASes.
  • We observed that there was a chance that the TCP port 80 of 1.1.1.1 got injected with a "302 Moved Temporarily" or "301 Moved Permanently" message, attempting to redirect users to the National Anti-Fraud Center website (wiki).

Analysis on the injection to 1.1.1.1:80

Here is one example when no injection happens:

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80...
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: cloudflare
< Date: Sun, 01 Oct 2023 22:49:54 GMT
< Content-Type: text/html
< Content-Length: 167
< Connection: keep-alive
< Location: https://1.1.1.1/
< CF-RAY: **REDACTED**-SJC
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
* Connection #0 to host 1.1.1.1 left intact

This is one example when the "302 Moved Temporarily" got injected.

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80...
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
< Connection: close
< Location: http://182.43.124.6/fzyujing?parameter2=REDACTED
<
* Closing connection 0

In particular, the redacted parameter in the output consists of 319 characters. Querying from the same vantage point across time, only the 129th to 150th characters (22 characters) and the 257th to 278th characters (22 characters) in the 319 character message got changed. It is still unclear to us what information got encoded in this parameter.

The real 301 Moved Permanently response from the 1.1.1.1 will eventually get to the client (but arrived later than the injected message), indicating the censor doesn't drop the real response from 1.1.1.1:80.

The ASN of the IP 182.43.124.6 that hosts the National Anti-Fraud Center website:

host asn asname cc registry
182.43.124.6 AS58519 CHINATELECOM-CTCLOUD Cloud Computing Corporation, CN CN apnic
@5e2t
Copy link

5e2t commented Oct 2, 2023

Screenshot from 2023-10-02 08-48-19

My location is Henan , but the RST I received is not from Henan GFW's censorship equipment.
It's from ShangHai exit GFW's censorship equipment.
because the latency between me and ShangHai exit is 28ms,
traceroute also shows network path is through ShangHai exit.

@5e2t
Copy link

5e2t commented Oct 2, 2023 •
edited
Loading

when I curl -v http://1.1.1.1
I received this in 30ms after HTTP GET sent.

HTTP/1.1 301 Moved Permanently
Location: http://106.74.25.198/
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 0

Screenshot from 2023-10-02 09-02-39

@5e2t
Copy link

5e2t commented Oct 2, 2023

content of http://106.74.25.198/
Screenshot from 2023-10-02 09-28-32

@UjuiUjuMandan
Copy link

content of http://106.74.25.198/

I really dialed the complaint number they provided, but no one answered (the first 2 numbers), and it "cannot go through" (the last one).

@Fallen-Breath Fallen-Breath mentioned this issue Oct 3, 2023
Closed
@wkrp wkrp added the China label Oct 4, 2023
@klzgrad
Copy link

klzgrad commented Oct 6, 2023

Injected HTTP/1.1 301 Moved Permanently packets have IP ids of 0x99d1, 0x99d2, 0x99d3, 0x99d4. Injected HTTP/1.1 302 Moved Temporarily packets have IP id of 0x4c57. They also have consistent TTLs.

GET requests with invalid Host fields, e.g. printf 'GET / HTTP/1.1\r\n\r\n' | nc -v 1.1.1.1 80 or printf 'GET / HTTP/1.1\r\nHost: \r\n\r\n' | nc -v 1.1.1.1 80 will yield a RST/ACK with the same IP ids and TTL as the injected HTTP 301 packets.

@UjuiUjuMandan
Copy link

The tampering was lifted since morning in my area.

@gaukas
Copy link

gaukas commented Oct 6, 2023

will yield a RST/ACK with the same IP ids and TTL as the injected HTTP 301 packets.

That's a really intriguing behavior. It could imply that these HTTP 301 responses were actually issued by a (group of) real HTTP server by redirecting/copying HTTP requests for it to handle, instead of hard-coded/crafted in advance.

It might be nice if it is possible to further exploit this mechanism in some ways? 😼

@gfw-report
Copy link
Contributor Author

gfw-report commented Oct 6, 2023 •
edited
Loading

We conducted an ongoing experiment from a vantage point in Tencent Cloud Beijing (ASN AS45090). Specifically, we curl https://1.1.1.1 and curl http://1.1.1.1 every minute and capture the network traffic.

Below is an analyis based on the data we collected between Sunday, October 1, 2023 19:54 PM (Beijing Time, UTC+8) and Friday, October 6, 2023 2:43 PM (Beijing Time, UTC+8). In total, we made 6169 HTTP requests. We received 559 HTTP/1.1 301 Moved Permanently injected packets and 1760 HTTP/1.1 302 Moved Temporarily.

This table summarizes all possible values seen in each type of injected responses:

HTTP Status Code 301 302
Total Number of Injections 559 1760
Injection Ratio (over 6169 requests) 9.06% 28.5%
IP ID 0X99b3 0x4c57
IP TTL 251 251
IP Flags 0x0 0x0
TCP Flags 0x18 (PSH+ACK) 0x19 (PSH+ACK+FIN)
TCP Window Size 502 65535

In comparision with @klzgrad 's observation that:

Injected HTTP/1.1 301 Moved Permanently packets have IP ids of 0x99d1, 0x99d2, 0x99d3, 0x99d4. Injected HTTP/1.1 302 Moved Temporarily packets have IP id of 0x4c57.

We only observed one IP ID value 0x99b3 for the HTTP/1.1 301 Moved Permanently injection, which is dffierent from the four reported values.

They also have consistent TTLs.

We also observed consistent TTLs and its value is the same as the packets sent by the real 1.1.1.1 server.

The figure below shows the number of injections we received in each hour. We send around 60 requests in each hour and the average injection rate for 301 and 302 responses are only 9.06% and 28.5% respectively:

figure

@klzgrad
Copy link

klzgrad commented Oct 6, 2023

IP TTL 251 251

My HTTP 301 packets have TTLs of 249. But my HTTP 302 packets have TTLs of 119.

its value is the same as the packets sent by the real 1.1.1.1 server.

This must be a typo because the real 1.1.1.1 server returns TTLs of 64 - $hops, 55 in my testing.

were actually issued by a (group of) real HTTP server

Unlikely.

printf 'GET /\r\nHost: "\r\n\r\n' | nc -v 1.1.1.1 80: RST/ACK
printf 'GET /\r\nHost: ""\r\n\r\n' | nc -v 1.1.1.1 80: Location: http://182.43.124.6/fzyujing?
printf 'GET /\r\nHost: .\r\n\r\n' | nc -v 1.1.1.1 80: RST/ACK
printf 'GET /\r\nHost: ..\r\n\r\n' | nc -v 1.1.1.1 80: Location: http://182.43.124.6/fzyujing?

@gfw-report
Copy link
Contributor Author

My HTTP 301 packets have TTLs of 249. But my HTTP 302 packets have TTLs of 119.
...
... the real 1.1.1.1 server returns TTLs of 64 - $hops, 55 in my testing.

Thank you for pointing this out. It's very likely that there are some middleboxes, which are 4 hops away from our TecentCloud VPS (possibly as part of the TecentCloud infrastructure), rewriting all the IP TTL to 255 for packets coming to our VPS. The IP TTL of packets sent out from our VPS did not get rewritten.

We know this because we sent packets with initial IP TTL 64 between two hosts, and still observed packets coming to our VPS have the IP TTL 251.

In the pcap I captured, all 49,977 packets sent or got injected from 1.1.1.1:80 indeed have the same IP TTL 251:

tshark -Y "ip.src == 1.1.1.1 and tcp.srcport == 80" -r 1.1.1.1.pcap -Tfields -e ip.ttl | sort | uniq -c
  49977 251

including those 2,319 injected packets:

tshark -Y "ip.src == 1.1.1.1 and tcp.srcport == 80 and tcp.len != 0 and (not tcp.payload contains 43:46:2d:52:41:59)" -r 1.1.1.1.pcap -Tfields -e ip.ttl | sort | uniq -c
   2319 251

@wkrp
Copy link
Member

wkrp commented Oct 30, 2023

The tampering was lifted since morning [2023-10-06] in my area.

I also received a separate report that the blocking stopped on 2023-10-04 about 07:30 UTC.

Here's an HTTP GET test from today, showing general reachability, I think:
https://17ce.com/site/http/20231030_89f5d95076db11eeae206dcaa1273080:1.html (archive)

Screenshot of 17ce.com GET test for http://1.1.1.1, a map of China showing access times of between 0 and 3 seconds for most provinces.

@klzgrad klzgrad mentioned this issue Nov 9, 2023
Open
@I-I-IT
Copy link

I-I-IT commented Nov 27, 2023

From Zhejiang Province : works seamlessly with wifi. Speed of 20-30 mbps. However, many websites block IPs from China.

@wkrp
Copy link
Member

wkrp commented Aug 21, 2024

  • We observed that there was a chance that the TCP port 80 of 1.1.1.1 got injected with a "302 Moved Temporarily" or "301 Moved Permanently" message, attempting to redirect users to the National Anti-Fraud Center website (wiki).

The 2024 research paper GFWeb: Measuring the Great Firewall's Web Censorship at Scale has a section about the anti-fraud center redirections.

https://www.usenix.org/system/files/usenixsecurity24-hoang.pdf#page=12

6.2 China’s “Anti-Fraud” Redirection

In late 2021, there were some reports of new network interference events across major state-owned ISPs [26, 73], including three largest operators: China Telecom, China Unicom, and China Mobile [51]. Many users reported that their browsing sessions were redirected to a warning page showing an “Anti-Fraud” message. As indicated in Figure 10, the warning page advises users that the site they are trying to access is suspected of fraud and asks them to install an app developed by the State Anti-Fraud Center from the Android or the Apple app stores. GFWeb has also observed this network interference. Applying the limited time-to-live (TTL) probing approach used in prior works [11, 65], we confirm that it is indeed caused by the ISPs. While we did not have direct access to vantage points within these ISPs, one of our measurement machines in China is located in a data center whose upstream provider is China Telecom, allowing us to observe the redirection injected by this ISP’s middleboxes. Similarly to the GFW, they can inspect and inject packets bidirectionally. They are also deployed as on-path devices and have a loss-tolerant design (i.e., can be triggered without a complete TCP handshake).

GFWeb observed a total of 2.3M redirection attempts caused by China Telecom’s middleboxes. In addition to two URLs reported on the Tor Project’s GitLab [73] (i.e., URLs 1 and 2 in Table 4), we have also observed six other URLs that share the same pattern but were injected with lower frequency. Our data also indicates that URLs ending with parameter1 and parameter2 were not deployed until February 2023.

Table 4 also lists some injected URLs that we deem as “buggy” because they contain either an invalid or non-routable IP address (i.e., 0.0.0.*). We believe that these URLs are a result of misconfiguration because the injection of these URLs will not lead to any redirection, and thus they are not effective for the ISP’s intended purpose.

GFWeb observed 478K unique FQDNs that trigger these injections. Still, we could not find any patterns that could explain why these domains were targeted, since they only triggered the redirection for a short period of time. Looking up the IP addresses of these domains, we find that less than half of them are associated with an IP address, while the remaining are either not associated with any IP address or not existing (i.e., NXDOMAIN [21]). Instead of targeting specific domains that are truly associated with fraud, this observation suggests that the redirection could have been randomly triggered in an opportunistic manner to redirect users to the warning page, persuading them to install the government’s “anti-fraud” app. This is evident by the fact that one of the trigger domains was baidu.com [73], which is obviously not fraudulent.

The original anecdote [73] also reported that OONI [38] and Censored Planet [64] observed this network interference happened via DNS injection as well. However, we could not reproduce redirection cases caused by DNS injection of 182.43.124.6 anymore. This strengthens our hypothesis that the redirection is performed in an opportunistic manner and does not target any particular domains for a long period of time. At the time of writing, we are still observing this network interference from China Telecom and will continue monitoring for any change in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
China
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@gaukas @klzgrad @wkrp @gfw-report @I-I-IT @5e2t @UjuiUjuMandan