使用Google新部署的W开头的中间证书签发的网站在TLS 1.2下100%阻断 / Sites issued with Google's newly deployed intermediate certificates starting with W are 100% blocked under TLS 1.2

[toorich]

本人在大约两个月前发现了标题所述现象（当时还在V2EX发了贴：https://www.v2ex.com/t/1043955 ），当时发现*.doubleclick.net（并非被墙的域名）通过安卓手机连接谷歌的海外节点时会被阻断，随着近期原由GTS CA 1C3、GTS CA 1D4和GTS CA 1P5签发的证书陆续到期（谷歌签发的证书的有效期是84天），新的证书陆续改由WR2、WR3、WE1签发，这些网站本人测试在TLS 1.2下都会被阻断，并且与域名无关，被阻断的是IP。据本人测试除了使用1.3之外减小MTU可能可以规避该阻断正常访问。

I discovered the phenomenon described in the title about two months ago (I also posted on V2EX at that time: https://www.v2ex.com/t/1043955), at that time, I found that `.doubleclick.net(not a walled domain name) would be blocked when connecting to Google's overseas nodes via Android phones, and with the recent expiration of the certificates originally issued byGTS CA 1C3,GTS CA 1D4andGTS CA 1P5certificates have been expired one after another (the validity of the certificate issued by Google is 84 days), and the new certificates have been changed toWR2,WR3, andWE1`, these websites will be blocked under TLS 1.2, and it is not related to the domain name, it is the IP that is blocked. According to my test, besides using 1.3, reducing the MTU may be able to circumvent the blocking and access normally.*

[wkrp]

Based on the symptoms you've described, the blocking must happen after the Server Certificate message, because that's where the intermediate certificates would appear.

I thought, perhaps, it might have to do with OCSP, but in that case, it would probably also fail with TLS 1.3.

[intmain0]

我也遇到了同样的现象，这是我的抓包结果 I'm experiencing the same phenomenon, and here's the result of my packet capture.

[intmain0]

本人在大约两个月前发现了标题所述现象（当时还在V2EX发了贴：https://www.v2ex.com/t/1043955 ），当时发现*.doubleclick.net（并非被墙的域名）通过安卓手机连接谷歌的海外节点时会被阻断，随着近期原由GTS CA 1C3、GTS CA 1D4和GTS CA 1P5签发的证书陆续到期（谷歌签发的证书的有效期是84天），新的证书陆续改由WR2、WR3、WE1签发，这些网站本人测试在TLS 1.2下都会被阻断，并且与域名无关，被阻断的是IP。据本人测试除了使用1.3之外减小MTU可能可以规避该阻断正常访问。

I discovered the phenomenon described in the title about two months ago (I also posted on V2EX at that time: https://www.v2ex.com/t/1043955), at that time, I found that *.doubleclick.net (not a walled domain name) would be blocked when connecting to Google's overseas nodes via Android phones, and with the recent expiration of the certificates originally issued by GTS CA 1C3, GTS CA 1D4 and GTS CA 1P5 certificates have been expired one after another (the validity of the certificate issued by Google is 84 days), and the new certificates have been changed to WR2, WR3, and WE1, these websites will be blocked under TLS 1.2, and it is not related to the domain name, it is the IP that is blocked. According to my test, besides using 1.3, reducing the MTU may be able to circumvent the blocking and access normally.

方便加个tg细聊吗

Is it convenient to add a tg to chat more?

[wkrp]

我也遇到了同样的现象，这是我的抓包结果 I'm experiencing the same phenomenon, and here's the result of my packet capture.

Okay, from this it indeed appears that the connection is blocked some time after the server's Certificate message. We also see the server sending Certificate Status, Server Key Exchange, and Server Hello Done messages, then we see the client trying and failing to send (retransmitting) its next message. The blocking looks like packet dropping, not RST injection. Quite often with blocking by packet dropping in China, we see that packets are dropped in only one direction, so it may be that the connection was blocked after the Certificate message, and the client was able to receive the server's message, but not send messages to the server.

[intmain0]

我是在windows下使用curl测试的。多尝试几次后，该域名对应的ip将无法被ping通，在几分钟后又恢复。这个问题是区域性的，我使用腾讯云上海服务器和其他省份的网络测试，并没有这个问题。 I tested it using curl on Windows. After several attempts, the IP corresponding to the domain name becomes unreachable by ping, but it recovers after a few minutes. This issue is regional. I tested it using Tencent Cloud's server in Shanghai and networks from other provinces, and there was no such issue.

[intmain0]

尝试运行openssl s_client -connect gost.run:443 --tls1_2 -status和openssl s_client -connect gost.run:443 --tls1_2，丢包的位置完全一样，所以应该可以排除ocsp的问题？ I tried running these two openssl commands, and the packet loss occurs at the exact same location, so the OCSP issue can probably be ruled out.

[toorich]

I thought, perhaps, it might have to do with OCSP, but in that case, it would probably also fail with TLS 1.3.

然而并不是。我在TLS 1.3下从未遇到过上述情况。因为TLS 1.2在握手阶段证书是明文传输的，我更倾向于是通过证书的特征封。

But NO. I have never encountered the above case under TLS 1.3. Because TLS 1.2 transmits certificates in the clear during the handshake phase, I prefer to block it by the characteristics of the certificate.