We confirm that the Great Firewall of China has blocked google.com and all its subdomains *.google.com, affecting more than 1,100 domains and a large number of popular services. In this post, we introduce the two major censorship actions we observed. We share instructions on detecting common website censorship in China, encouraging more people to detect and expose censorship independently.

The censors first started SNI-based censorship on google.com and *.google.com on Thursday, September 22, 2022, sometime between between 6:23 AM and 7:33 PM Beijing Time (UTC+8). Specifically, the censor looks for SNI values in TLS ClientHello messages, and when a SNI value matches the blacklist rules, the censor sends forged TCP RST packets to tear down the connections.

Eight days later, the censors started DNS-based censorship on google.com and *.google.com on Friday, September 30, 2022, sometime between between 1:56 PM and 2:35 PM Beijing Time (UTC+8). That is, the censor check the query name in DNS queries against the blacklist rules and injects forged DNS responses containing wrong IP addresses.

Below are a list of frequently asked questions:

Q: What domains are censored?

Any domain matches google.com or *.google.com are censored. For example, translate.google.com has been censored.

We also confirm that *google.com and google.com.* are not part of the blacklist rules. For example, madgoogle.com and translate.google.com.co are not censored in China.

Q: What is the impact of this blocking?

More than 1,100 domains are censored, including a large number of popular services, for example: firebase.google.com, translate.google.com, maps.google.com, scholar.google.com, feedburner.google.com, and ads.google.com.

We attached a list of affected domains to this post.

Q: Did you observe any whitelisting rules?

No. All 1,147 *.google.com domains we tested were blocked without exception.

Q: What else have you observed about the blocking?

The start of SNI-based and DNS-based blocking both happened durin the business hours in China.
google.com is censored by all three DNS injectors; *.google.com is censored by DNS Injector 2 and 3, but not Injector 1. (See Table 3 in this paper for each Injector's fingerprint.)

Q: How did you know about the blocking?

We have been continuously monitoring the website censorship in China by sending DNS queries with different query names and ClientHello with different SNI values. We thus keep a record of newly censored domains.

We encourage you to test and monitor the censorship yourselves independently because the more people keep an eye the censorship, the quicker we spot a censorship event collectively.

To monitor DNS-based censorship, you can send a DNS query to a non- DNS server, which passes the GFW. Because destination server is not a DNS server, if you received any DNS responses, they must be forged (by the GFW). For example, if you are inside China and want to test if google.com is censored or not, you can try:

dig @23.197.152.0 google.com

If you received any DNS response, it means google.com is censored.

To monitor SNI-based censorship, if you are inside China, you can send a TLS Clienthello message with to an open port of a server outside of China. If you received TCP RST packets, it is likely the connect got censored. For example, if you are inside China and want to test if google.com is censored or not, you can try:

openssl s_client -servername google.com -tlsextdebug -msg -connect 96.17.116.205:80

If you receive a message write:errno=104, it means your connection gets RSTed, and is likely that google.com is censored. We say "likely" because there may be some false positive. You'd better to have a control group with SNI sets to some non-censored domains, for example, baidu.com, and see if you receive any TCP RST packets from the same port of the same server.

Oct 01 '22 11:10 gfw-report

中国的防火长城屏蔽了google.com及其所有的子域名

我们证实中国的防火长城已经屏蔽了google.com及其所有的子域名。这一封锁策略影响超过1100个相关域名以及大量的流行服务。在这篇文章中，我们介绍观察到的审查者的两次大动作。我们同时分享测量网站审查的方法，以鼓励更多人独立地检测并曝光审查行为。

审查者首先在北京时间2022年9月22日星期四，早上6点23分到晚上7点33分之间的某一时刻将google.com和*.google.com加入到SNI黑名单中。GFW会检查所有TLS ClientHello包，如果其中的SNI与黑名单匹配，GFW就会立即发送伪造的TCP RST包来切断TCP连接。

八天之后，审查者又在北京时间2022年9月30日星期五，下午1点56分到下午2点35分之间的某一刻将google.com和*.google.com加入到DNS黑名单中。GFW会检查所有DNS请求包，如果请求的域名与黑名单相匹配，GFW就会立即发送伪造的、含有错误IP地址的应答包给客户端。

下面是一些常见问题：

Q: 被审查的域名都有哪些？

所有符合google.com或*.google.com规则的域名都受到了审查。比如，谷歌翻译的域名translate.google.com就被审查了。

我们还确认*google.com和google.com.*还不是黑名单规则。比如说，madgoogle.com还有translate.google.com.co就还没被审查。

Q: 这次审查有何影响？

包括一些热门服务在内的超过1100个域名受到了审查。比如说，firebase.google.com，translate.google.com，maps.google.com，scholar.google.com，feedburner.google.com，还有ads.google.com。

我们已经将受到影响的域名附在了这篇帖子上。

Q: 你们有没有观察到被白名单豁免的域名?

没有。我们测试的1147个*.google.com域名全都被屏蔽了，无一例外。

Q: 你们还观察到了什么？

SNI审查和DNS审查的开始时间均在中国的工作时间内。
google.com被GFW的三种不同的DNS审查机器列入黑名单；而*.google.com则只被2号和3号机器列入黑名单。(每个机器发的DNS伪造包的指纹详见这篇论文的Table 3。)

Q: 你们是怎么知道这次屏蔽事件的？

我们通过发送含有不同域名的DNS请求包和含有不用SNI的ClientHello包，来持续地监测中国的网站审查。当新的域名遭到审查时，我们就留下了相应的记录。

我们鼓励读者你也独立地测量和监控互联网审查。因为独立测量审查的人越多，我们作为一个集体就越能更快速地发现新的审查事件。

测量一个域名是否受到DNS审查的办法是：向境外的非DNS服务器发送一个含有该域名的请求包。选择境外服务器是为了让你的包经过国际网络出口，从而让GFW看到。因为你发送请求的目的地服务器不是DNS服务器，因此如果你收到了任何DNS应答包，那么都是中间人伪造的（常见的中间人就是GFW）。比如说如果你想测试google.com是否被审查了，则可以：

dig @23.197.152.0 google.com

因为23.197.152.0是一台境外的非DNS服务器，所以如果你收到了任何DNS响应包的话，就证明google.com被审查了。

测量一个域名是否受到SNI审查的办法是：向境外服务器的开放端口发送一个含有该域名的TLS Clienthello包。选择境外服务器是为了让你的包经过国际网络出口，从而让GFW看到。如果你收到了TCP RST包，那么有可能是因为你的连接被GFW阻断了。比如说如果你想测试google.com是否被审查了，则可以：

openssl s_client -servername google.com -tlsextdebug -msg -connect 96.17.116.205:80

其中96.17.116.205是一台境外服务器，80是它的一个开放的端口。

如果openssl报错write:errno=104，那么说明你的连接被TCP重置了。而这就证明google.com有可能被审查了。我们说“有可能”是因为有假阳性的可能。为了减少假阳性的可能，你应该用一个不太可能被审查的域名设置一个对照组（比如用baidu.com）。然后观察向同一个服务器的同一个端口发送含有baidu.comSNI的ClientHello，连接是不是就不会被重置。

Oct 01 '22 11:10 gfw-report

👀

Oct 01 '22 12:10 SekiBetu

原来如此，那么FCM的域名 mtalk.google.com 是被连带封锁了喔。

Google FCM 被屏蔽 on Solidot.org

还有 dl.google.com 这个解析地址在国内的也被屏蔽了，这下 Chrome 都下载不了了。

I see, so the block of the FCM domain mtalk.google.com is in connection with that.

Google FCM blocked on Solidot.org

And dl.google.com this resolution address in the country is also blocked, now Chrome can not be downloaded.

Oct 01 '22 14:10 ghost

fcm用的主域名 mtalk.google.com mtalk4.google.com 被污染了，但其它几个备用的好像没事，所以fcm依然是正常工作的，只是连的会慢一些

The main domain names mtalk.google.com and mtalk4.google.com used by fcm are contaminated, but several other alternate ones seem to be fine, so fcm is still working properly, but the connection will be slower.

Oct 01 '22 15:10 ayanamist

@gfw-report Thank you for your detailed report!

From someone with limited knowledge about GFW: My impression was that a variety of Google services have been unavailable in China for decades. If SNI and DNS-based blocking just started now, how did GFW block Google before (is it IP-based?)

Considering the number of services affected by blocking *.google.com (e.g., FCM), do you expect the blocking for services like Google Scholar, translation, FCM messaging to be lifted sometime soon (e.g., after the party conference)?

Oct 01 '22 16:10 diwenx

fcm用的主域名 mtalk.google.com mtalk4.google.com 被污染了，但其它几个备用的好像没事，所以fcm依然是正常工作的，只是连的会慢一些

请问你尝试的是哪个备用域名呢？从我这里看，所有fcm的域名（https://firebase.google.com/docs/cloud-messaging/concept-options）都可以触发SNI的TCP RST.

mtalk.google.com
mtalk4.google.com
mtalk-staging.google.com
mtalk-dev.google.com
alt1-mtalk.google.com
alt2-mtalk.google.com
alt3-mtalk.google.com
alt4-mtalk.google.com
alt5-mtalk.google.com
alt6-mtalk.google.com
alt7-mtalk.google.com
alt8-mtalk.google.com
android.apis.google.com
device-provisioning.googleapis.com
firebaseinstallations.googleapis.com

The main domain names mtalk.google.com and mtalk4.google.com used by fcm are contaminated, but several other alternate ones seem to be fine, so fcm is still working properly, but the connection will be slower.

May I ask which alternate domain you are trying? From what I can see, all fcm domains (https://firebase.google.com/docs/cloud-messaging/concept-options) can trigger SNI TCP RST.

Oct 01 '22 16:10 diwenx

@diwenx 看起来到Google服务器的HTTPS连接某种程度上被“白名单”了。具体表现是

curl -v https://alt6-mtalk.google.com --connect-to ::un.org

可以收到 RST ，然而

curl -v https://alt6-mtalk.google.com --connect-to ::108.177.97.188

（108.177.97.188 是 Google 的 IP）却能正常连接，无法看到RST。

10.2 更新：好奇怪，现在上面两个都收不到RST了。

@diwenx It seems that HTTPS connections to Google servers are somehow "whitelisted". This is evidenced by the fact that

curl -v https://alt6-mtalk.google.com --connect-to ::un.org

receive RST, while

curl -v https://alt6-mtalk.google.com --connect-to ::108.177.97.188

(108.177.97.188 is Google's IP) can connect normally and does not see a RST.

2022-10-02 Update: So strange, now the above two do not receive RST.

Oct 01 '22 16:10 ghost

I'm also confused. What exactly is the new finding? Google has been blocked in China for years (and, as far as I know, was a motivation for the Google Transparency Report)

Oct 01 '22 20:10 fortuna

See https://www.theguardian.com/technology/2012/nov/09/google-services-blocked-china-gmail

Oct 01 '22 21:10 fortuna

I'm also confused. What exactly is the new finding? Google has been blocked in China for years (and, as far as I know, was a motivation for the Google Transparency Report)

Many services like Google Ads, Google Translate and Google Chrome Download, which contain no politically sensitive content, remained available until yesterday. However, from now on, they are no longer available.

Oct 02 '22 00:10 asdetycv1zzc

dl.google.com已恢复

dl.google.com is restored.

Oct 02 '22 01:10 Admirepowered

FCM is back to normal and can be viewed by typing *#*#426#*#*

Oct 02 '22 02:10 SekiBetu

谷歌浏览器官网那不是？

Google Chrome is not?

Oct 02 '22 05:10 ZXAS007

我在国内，我用不了谷歌翻译，全程靠着TCPionner。

I'm in China and I can't use Google Translate, I rely on TCPionner every time.

Oct 02 '22 07:10 MomijiHanako

我在国内，我用不了谷歌翻译，全程靠着TCPionner。

这是什么神器，有啥用处

What is this magic tool, what is the use of it

Oct 02 '22 13:10 getr00t

我在国内，我用不了谷歌翻译，全程靠着TCPionner。

这是什么神器，有啥用处

https://github.com/macronut/ghostcp

Oct 02 '22 13:10 Admirepowered

广东移动的FCM工作挺正常的，Telegram的信息还是能秒收

Guangdong Mobile's FCM works fine, Telegram messages can still be received in seconds

90bc62e909338f4eb87b28c97b2d088

Oct 03 '22 07:10 ying727

我在国内，我用不了谷歌翻译，全程靠着TCPionner。

这是什么神器，有啥用处

https://github.com/macronut/ghostcp

哦，不会用，这是干嘛的，咋用啊😯

Oh, can't use, what is this for, how to use ah😯

Oct 04 '22 08:10 getr00t

广东移动的FCM工作挺正常的，Telegram的信息还是能秒收

Guangdong Mobile's FCM works fine, Telegram messages can still be received in seconds

这个我也能看到，就是不知道这是干嘛的

I can also see this, just do not know what this is for

Oct 04 '22 08:10 getr00t

That's not a big deal, since Google's services are already almost universally unavailable in China.

Of course, as professionals, we could have used "DNS hijacking" and "TCP/IP attacks" tech to bypass the GFW and access Google directly from mainland China instead of setting up VPN/forward proxies.

If you directly connect to google.com through normal channels, it will be blocked by the GFW for SNI sniffing. However, you can solve this problem by using the methods mentioned above.

However, it has the problem of personal safety in terms of administration. Since it is directly connected to Google from mainland China, CCP can grasp the real IPAddress and PORT mapping information of users who commit illegal wall-hopping.

And it is not without problems, if you want to achieve must seek the google.com IP address can be connected in mainland China, usually IP addresses are not alive too long

Oct 05 '22 03:10 liulilittle

似乎GFW已改变对GOOGLE的DNS策略。

刚才我在墙内环境使用了 dig ，得到了正确的解析结果。如果指定虚假的DNS则会超时。

Seems that GFW has changed its DNS strategy on Google.

I've just tried dig and got correct resolution result. If specifying fake DNS, it would time-out.

Dec 05 '22 10:12 bcegkmqs23

Protesters have made more or least transnational corporations leaving China. App is planning leaving.[https://archive.ph/7bP4j]

From: bcegkmqs23 @.> To: net4people/bbs @.> CC: Subscribed @.*> *Date: *Dec 5, 2022 10:36:06 *Subject: *Re: [net4people/bbs] The Great Firewall of China has blocked google.com[https://google.com] and all its subdomains (Issue #128)

似乎GFW已改变对GOOGLE的DNS策略。

刚才我在墙内环境使用了 dig ，得到了正确的解析结果。如果指定虚假的DNS则会超时。

Seems that GFW has changed its DNS strategy on Google.

I've just tried dig and got correct resolution result. If specifying fake DNS, it would time-out.

— Reply to this email directly, view it on GitHub[https://github.com/net4people/bbs/issues/128#issuecomment-1337108086], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYC25AUS43UOTRFEKNTWLXARLANCNFSM6AAAAAAQ2NLRWI]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYFDS6YCCBP62GA2FXLWLXARLA5CNFSM6AAAAAAQ2NLRWKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSPWKTHM.gif]Message ID: @.***>

Dec 05 '22 13:12 cross-hello

似乎GFW已改变对GOOGLE的DNS策略。

刚才我在墙内环境使用了 dig ，得到了正确的解析结果。如果指定虚假的DNS则会超时。

Seems that GFW has changed its DNS strategy on Google.

I've just tried dig and got correct resolution result. If specifying fake DNS, it would time-out.

在几年前就发现，部分时间、部分DNS会偶尔返回正确结果，估计和旧GFW的处理能力有关 It was found a few years ago that part of the time, part of the DNS will occasionally return the correct results, and it is estimated that the processing power of the old GFW is related.

Test @ 0755 `; <<>> DiG 9.10.4-P4 <<>> @202.96.134.133 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23005 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7

;; QUESTION SECTION: ;www.google.com. IN A

;; ANSWER SECTION: www.google.com. 600 IN A 150.107.3.176

;; AUTHORITY SECTION: google.com. 142231 IN NS ns1.google.com. google.com. 142231 IN NS ns3.google.com. google.com. 142231 IN NS ns4.google.com. google.com. 142231 IN NS ns2.google.com.

;; ADDITIONAL SECTION: ns4.google.com. 220162 IN A 216.239.38.10 ns1.google.com. 220248 IN A 216.239.32.10 ns3.google.com. 344860 IN A 216.239.36.10 ns4.google.com. 220169 IN AAAA 2001:4860:4802:38::a ns2.google.com. 168116 IN AAAA 2001:4860:4802:34::a ns1.google.com. 221951 IN AAAA 2001:4860:4802:32::a ns3.google.com. 168116 IN AAAA 2001:4860:4802:36::a

;; Query time: 0 msec ;; SERVER: 202.96.134.133#53(202.96.134.133) ;; WHEN: Tue Dec 06 10:23:51 中国标准时间 2022 ;; MSG SIZE rcvd: 280 `

Dec 06 '22 02:12 tec1987

I was looking at some OONI results today and I noticed that the DNS name stun.l.google.com also now apparently resolves correctly. stun.l.google.com was on the original list of affected domains from 2022-10-01:

...
stream.meet.google.com
studykit.google.com
stun.l.google.com
subdomain.google.com
suepport.google.com
...

Here's an example of testing for injection of www.google.com by sending a DNS query into China. As expected, it gets an injected response:

$ dig +short +timeout=5 @chinaunicom.com www.google.com
69.63.184.14

(The IP address 69.63.184.14 actually belongs to Facebook. The GFW's injection of real IP addresses belonging to tech companies has been well documented.)

Doing the same thing with stun.l.google.com times out; i.e., there's no injection:

$ dig +short +timeout=5 @chinaunicom.com stun.l.google.com
;; connection timed out; no servers could be reached

Here's an example of an OONI measurement showing stun.l.google.com resolving correctly. The domain is tested as part of OONI's stunreachability test. You can see the DNS resolution results under .test_keys.queries in the raw JSON data.

https://explorer.ooni.org/m/20240131152556.849592_CN_stunreachability_9ae016fee3cbcfa4

[
  {
    "answers": [
      {
        "asn": 15169,
        "as_org_name": "Google LLC",
        "answer_type": "A",
        "ipv4": "172.217.211.127",
        "ttl": null
      }
    ],
    "engine": "system",
    "failure": null,
    "hostname": "stun.l.google.com",
    "query_type": "A",
    "resolver_hostname": null,
    "resolver_port": null,
    "resolver_address": "",
    "t": 0.006968385,
    "tags": null
  },
  {
    "answers": [
      {
        "asn": 15169,
        "as_org_name": "Google LLC",
        "answer_type": "AAAA",
        "ipv6": "2404:6800:400a:1002::7f",
        "ttl": null
      }
    ],
    "engine": "system",
    "failure": null,
    "hostname": "stun.l.google.com",
    "query_type": "AAAA",
    "resolver_hostname": null,
    "resolver_port": null,
    "resolver_address": "",
    "t": 0.006968385,
    "tags": null
  }
]

Jan 31 '24 22:01 wkrp

^ Can confirm (China Mobile)

Feb 01 '24 00:02 xtexx

I confirm that the *.google.com is not part of the blocking rules anymore as of Feb. 1, 2023. I tested by sending DNS queries of type A and AAAA from a machine outside of China, to a single IP addresses in China (AS4837;CHINA169-BACKBONE CHINA UNICOM China169 Backbone, CN). For each of the 1147 domains in this list (https://github.com/net4people/bbs/files/9690188/affected_google_domains.txt), I sent ten DNS queries.

In total, there were 47 domains that were censored as of Feb. 1, 2023. he censorship is consistent for both A and AAAA type queries:

2019docs.google.com
222.plus.google.com
accounts.google.com
amp.sites.google.com
beta.sites.google.com
comunicacionestrategicarosario.sites.google.com
cpateca.sites.google.com
docs.google.com
drive.google.com
encrypted.google.com
facebook.sites.google.com
google.com
groups.google.com
http.drive.google.com
ipv6.google.com
link.drive.google.com
linkplus.google.com
linkurlplus.google.com
linplus.google.com
mifrageplus.google.com
mobile.sites.google.com
m.plus.google.com
odzyskiwanie-danych-rybnik.sites.google.com
odzyskiwanie-danych-witkowo.sites.google.com
odzyskiwanie-danych-wloclawek.sites.google.com
play.google.com
play.sites.google.com
plus.google.com
r1---sn-2gb7ln76.c.docs.google.com
r1---sn-nv47lned.c.docs.google.com
r2---sn-n4v7knll.c.drive.google.com
r4---sn-25ge7ns7.c.drive.google.com
r4---sn-cxg7ene7.c.docs.google.com
r5---sn-5hn7su7l.c.docs.google.com
r6---sn-cvh76n7k.c.docs.google.com
saludos.sites.google.com
school.sites.google.com
sites.google.com
sites.sites.google.com
tmpdrive.google.com
ultimateweavessites.google.com
web.sites.google.com
website.sites.google.com
webs.sites.google.com
ww.sites.google.com
www.plus.google.com
www.sites.google.com

Feb 01 '24 00:02 gfw-report

bbs
bbs copied to clipboard

The Great Firewall of China has blocked google.com and all its subdomains

Q: What domains are censored?

Q: What is the impact of this blocking?

Q: Did you observe any whitelisting rules?

Q: What else have you observed about the blocking?

Q: How did you know about the blocking?

中国的防火长城屏蔽了google.com及其所有的子域名

Q: 被审查的域名都有哪些？

Q: 这次审查有何影响？

Q: 你们有没有观察到被白名单豁免的域名?

Q: 你们还观察到了什么？

Q: 你们是怎么知道这次屏蔽事件的？

bbs bbs copied to clipboard

The Great Firewall of China has blocked google.com and all its subdomains

Q: What domains are censored?

Q: What is the impact of this blocking?

Q: Did you observe any whitelisting rules?

Q: What else have you observed about the blocking?

Q: How did you know about the blocking?

中国的防火长城屏蔽了google.com及其所有的子域名

Q: 被审查的域名都有哪些？

Q: 这次审查有何影响？

Q: 你们有没有观察到被白名单豁免的域名?

Q: 你们还观察到了什么？

Q: 你们是怎么知道这次屏蔽事件的？

bbs
bbs copied to clipboard