ThEWiZaRd0fBsoD

官网SSL证书链异常

2

如图，FireFox Mainline版本访问时，会提示中间证书丢失而不受信任。   原因是服务器并没有发送中间证书（如图三，SSL Labs的测试结果所示）。  解决方法：将中间证书补全到服务器上的SSL证书即可（MySSL提供证书链修复工具）。 https://myssl.com/chain_download.html 

Please enable NR dual mode (enable both NR SA and NR NSA simultaneously)

7

Phone model: Xiaomi Note 9 5G (Cannon China Edition)   I'm using a China Unicom SIM card, and China Unicom removed NSA base stations a long time ago. However, this firmware...

OpenVPN supports "equal" validation of fingerprints (hashes) between client and server, which provides stronger security than validating CA certificate names and certificate usage. This setting can more effectively resist man-in-the-middle...

Can we restrict I2P peer connections from 'strict countries'?

9

I2P peers in the strict country list will force-enable hidden mode, and I2P peers in this mode should not participate in tunnel creation. Can we implement similar restrictions on I2P...

中国河南省地区的运营商似乎对IPV6没有那么强的审查力度/The operators in Henan Province, China, seem to have less stringent censorship regarding IPV6.

25

如题，我在中国河南省（使用的ISP：中国联通）居住。 当我在IPV6网络上连接obfs4 IAT-MODE=0的网桥时，这些网桥全部都可以正常连接。但反之切换到IPV4会立即失败。  类似的，我也直接使用Shadowsocks Stream加密，也不会遭到封锁。 我想知道这是否只是某个省份的个例，还是说在其他省份也可以复现？ As mentioned, I live in Henan Province, China (ISP used: China Unicom). When I connect to obfs4 bridges with IAT-MODE=0 on an IPV6...

在启用TCP Timestamp（TCP时间戳）后，GFW对obfs4的审查无效 / After enabling TCP Timestamp, GFW's censorship of obfs4 is rendered ineffective

21

（我太兴奋了，重写一下，之前有大量错误，并且重新进行实验） 在之前我看到这么一篇[博客文章](https://blog.tsinbei.com/archives/1361/)，提到TCP时间戳选项会影响河南省墙的判断。 我对这个说法保持怀疑，但想到如果头部多出十个字节的明文，那么应该可以干扰GFW对obfs4的判断（众所周知，obfs4在中国已经被屏蔽很长一段时间）。 于是我自己配置了一个obfs4 iat-mode=2的网桥，将Windows设置为同时启用TCP窗口和TCP时间戳。 `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts（设置为3）` 很有趣的是：obfs4网桥就此恢复正常使用，就好像GFW从来没有侦测到过它一样。 这里是[抓包文件](https://drive.google.com/file/d/15jf1O-JjZNYc4j3fcrVet2bQrNCVjDiw/view?usp=sharing)，其他人能很明显地发现，到达网桥的通信（TCP 17120端口）从未被干扰/阻止。 即使在我已经在听歌，这段通信依旧未被阻止。  网桥地址：obfs4 172.236.211.247:17120 126E14CC2C03133E70FBBF306D76D75AA96D47EB cert=ubysetrGTVF+eux3IDgjC/w9u6xjGGNUnz89U2zkuDFCF3lQsWb0FuB9qfG6TzN1AL73HA iat-mode=2 --- *(I'm so excited, I've rewritten it, there were a lot of mistakes before,...

GFW的确存在某种形式的数据报文长度检查 / The GFW does indeed perform some form of data packet length checking

5

地理位置：中国河南省安阳市。 运营商：中国联通。 复现方法： 将[Cloak](https://github.com/cbeuw/Cloak)的连接复用NumConn设置为0（禁用连接复用）后，Tor无法通过Cloak保护的代理连接到Tor网络。 但一旦打开Cloak的连接复用（哪怕NumConn设置为2），Tor依然可以通过Cloak保护的代理连接到Tor网络。 分享的目的： GFW被认为存在数据包长度检查多年，但都是缺乏直观体现的案例，且缺少可以准确复现的情况。 这能从直观的角度证实数据包长度检查的存在（Tor是一种使用TLS 1.3传输的[软件](https://spec.torproject.org/tor-spec/negotiating-channels.html)）。 也能直观的解释你的代理到底是哪里出了问题被拉黑，说的就是那群懒得开mux（多路复用/连接复用）的人。 （我知道使用Fake TLS类代理测试并不“标准”，但GFW似乎照常对其进行了TLS in TLS检测并识别出来了这是Tor）。 没有截图，但是有视频： https://youtu.be/6zwcvxelgPk --- *Location: Anyang City, Henan Province, China. Operator: China Unicom.* *Reproduction method: After setting...