GFW动态和未来展望

[URenko]

前情提要：IPv6的实现应该没有问题，但是IPv6用于翻墙的可用性有较大地域差别，故将计入 #36

此Issue改为GFW动态和未来展望

[miaomiaosoft]

各地IPV6的GFW影响和IPV4应该都是一样的，听说教育网对谷歌家的网站封锁放宽了些
在我这DNS污染，IP封锁，HTTP重置，HTTPS SNI重置，IPV4上有的IPV6也一个不落
没普及IPV6前想着有了IPV6谷歌访问就有望了，然而真有了却发现IP也一样被封，就算不封IP还有SNI重置终极大法等着你
谷歌的QUIC协议曾经撑过一段时间，然而最终还是会被GFW干扰阻断

目前的状态是偶尔能直连谷歌，F12发现走的是QUIC协议，然而，不一会当被GFW发现时当前谷歌IP会被超时90秒，基本上等于不可用
Accesser在谷歌上无效，可能因为禁用了域前置

dropbox、脸书、telegram有IPV6，之前测试是可以用Accesser访问的

[URenko]

Accesser在谷歌上无效，可能因为禁用了域前置

我这里测试似乎未发现禁用域前置，能提供下连接所使用的Google的IP和Accesser的错误提示吗

[miaomiaosoft]

谷歌和亚马逊都关了域前置，这是有新闻报道过
现在谷歌的IPV6封的比IPV4还干净，要测试的话只能用IPV4测了
172.217.14.81 / 172.217.160.81

该网页无法正常运作 www.google.com 未发送任何数据。
ERR_EMPTY_RESPONSE

`2019-05-11 19:19:27 WARNING Accesser: ("hostname 'clients2.google.com' doesn't match either of '.appspot.com', '.a.run.app', '.thinkwithgoogle.com', '.withgoogle.com', '*.withyoutube.com', 'appspot.com', 'run.app', 'thinkwithgoogle.com', 'withgoogle.com', 'withyoutube.com'",)

2019-05-11 19:19:29 WARNING Accesser: ("hostname 'clients2.googleusercontent.com' doesn't match either of '.appspot.com', '.a.run.app', '.thinkwithgoogle.com', '.withgoogle.com', '*.withyoutube.com', 'appspot.com', 'run.app', 'thinkwithgoogle.com', 'withgoogle.com', 'withyoutube.com'",)

2019-05-11 19:19:59 WARNING tornado.access: 404 GET /favicon.ico (127.0.0.1) 1.00ms

2019-05-11 19:21:35 INFO Accesser: server started at 127.0.0.1:7655`

[URenko]

关闭证书校验呢？我这里也出现证书匹配问题，关闭证书校验就可以访问（注意安全）。

根据 #19 的现象，拒绝域前置应该表现为直接结束握手，连证书也不会发。

[miaomiaosoft]

不行哦，Accesser的证书校验一直是关闭的

似乎和浏览器有关？我一直是用谷歌浏览器测试，刚用火狐试了下发现如你所说能打开，但此时GFW干扰厉害，完整网页都出不来

但当我关掉火狐，干扰消失

[P-256]

现在v6的干扰比v4还严重，而且v6还乱墙ip，甚至于APNIC和EA，NVADIA都有几个IP被墙。
尤其是维基百科我这边干扰很严重。使用accesser测试貌似有时候不行（雾）但昨天开始没法复现了。用wikimedia.org的证书缓存会话复用可以进www.wikipedia.org，进不去其它的子域名（都是被ERR_Closed）（意外终止了连接，经常在用SNI反代被拦截的时候看到，居然在v6的无证书检测网站上再现了）
顺便一提v6的证书检测貌似还没正式投产，fb还可以用。
而且v4 google（hk）我用的是hosts，关闭QUIC，打开accesser，测试环境chrome74，电信（QUIC已经被干扰了，用QUIC的话直接超时）用的IP是172.217.160.0，也是关了域前置，未发送数据。
whatsapp也是没用，整个whatsapp.net享受和google一样的证书检测级待遇，还没搞清关没关域前置。
2019.5.14更新：
dropbox居然ojbk了

[SeaHOH]

关于证书校验，其中有些可以不校验主机名。
例如，谷歌就是使用自己的中间 CA 来发行网站证书，只要是这个中间 CA 且签名对就没问题。

[URenko]

关于证书校验，其中有些可以不校验主机名。
例如，谷歌就是使用自己的中间 CA 来发行网站证书，只要是这个中间 CA 且签名对就没问题。

好主意

还有一个情况就是：近期墙的策略调整频繁，非常不稳定。
局域网络经常会错封很多 IP，一段时间后又会恢复正常，4 和 6 都一样。
不过此症状正在减弱，怀疑和机器学习有关。

我以为是前段敏感时期的激进操作，何以判断和机器学习有关？

[URenko]

我以为是前段敏感时期的激进操作，何以判断和机器学习有关？

据我观察到的现象，错封某个 IP 并非是全国性的，各区域遇到的情况都不相同，而且反复间断性的错封和恢复，但错封一直存在，只是频率在减少。
具体机制不了解，但是这看起来比较像是机器学习在训练，也就是说，把没完全成熟的 AI 投入了实践，以实际运作来反馈促进。

确实有可能

[P-256]

我以为是前段敏感时期的激进操作，何以判断和机器学习有关？
据我观察到的现象，错封某个 IP 并非是全国性的，各区域遇到的情况都不相同，而且反复间断性的错封和恢复，但错封一直存在，只是频率在减少。
具体机制不了解，但是这看起来比较像是机器学习在训练，也就是说，把没完全成熟的 AI 投入了实践，以实际运作来反馈促进。

确实有可能

最近GFW的策略是对网站激进，对IP冷静
IP的话最近更多的不是IP被墙，而是遭到了各种莫名奇妙的干扰，比如ss的无加密auth_chain_a就莫名奇妙的被干扰
网站最近被墙的一堆，大多数都是很精确的（新闻网站），但其他的内容GFW的AI实在是太脑残了。某游戏破解补丁网站（服务器在CF），winrar，7-zip（均为英文官网）（都托管在虚拟云主机），甚至于软碟通（sg阿里云）都被墙了，更奇葩的是几天后后面三个又貌似被人工干预解封了。
其实我猜测是之前一直没能用的那篇论文
The Random Forest based Detection of Shadowsock's Traffic
配合强大的超算（其实从证书检测开始GFW可能已经在引入超算了）
可以用了
当然随机森林算法不仅可以用在ss，还可以其他用途。猜测最近网站封得不准可能是精度低，单纯无脑采集tag和敏感词。
AI的成长速度极快，照这种趋势如果GFW铁心要做两三年就可以达到比较高的精度了。甚至于内部爬虫采集网站内的内容然后审查+屏蔽。

[URenko]

SS被识别是很有可能的，不过超算似乎太夸张了（训练阶段除外），这种专用的硬件更合适吧，尤其是证书检测（未研究过，仅为猜测）。我的猜想是那几个网站是同IP/主机连带被墙的。

[SeaHOH]

GWF 是依附于骨干网各个节点，真要用超算，远程处理响应速度达不到要求。那么本地建超算？不太可能，这不是浪费么，其实用不着这么大的通用计算能力，几个小型的专用设备集群就能满足。
不过虽然超算不可能参与直接处理，但是可用于整合和规划。
网络资源都掌握在上层，还是需要有革新性的技术来突破这种掌控，现在能看到的都尚未脱去藩篱。

关于域前置，其实并没有这种技术，这只是 SNI 的副作用，算是漏洞吧。
所谓关闭域前置，无非两种做法。
一是直接检查 SNI，这种会拒绝握手，一般服务商不会这么做；
二是将主机名检查留给后端，这种就不存在拒绝握手，这才是正常做法。
握手被拒绝是因为其它原因，如协议版本或算法不匹配等，GFW 的 RST 另算；
主动拒绝握手一般就是证书验证失败。

[P-256]

超算的话是当初搞出证书检测后有人猜测的，不过细细想想可能性也不大。
不过如果要学习速度还要快在核心层搞几台还是合理的（毕竟当年GFW搞硬件就占了国家某计划一大笔经费）
顺便@URenko 出事时后面那三个IP都没事，全是最低级的DNS污染。
而且目前经过我和另外一个朋友的测试，火绒和一堆国产软件会收集ss信息或者是干扰ss降低破网效率（提高丢包）

[URenko]

顺便@URenko 出事时后面那三个IP都没事，全是最低级的DNS污染。

“后面那三个”是指winrar、7-zip、软碟通吗

[P-256]

是的
顺便统计了一下当时和他们一起被墙的还有fb2000，apache（除了achive.apache.org未解封，原因不明，不过这只是个旧版下载地址无公害，不知为何没解封），idm，xnview
以外国软件为主，可能是ai的首次封禁

[zhixingheyi666]

小白请教个问题，VPN和我们这个Accesser相比有什么不可比拟的优势，以至于被宣布非法，导致很多做这个的被责罚。能从原理上简单解答一下吗？

[linsui]

https://steemit.com/cn/@v2ray/sni

Domain Fronting 实际上并不要求 MITM，只要实时修改 TLS 握手信息即可。但 V2Ray 还不支持这么做，只能通过上述的方式变向去支持它。由于 Domain Fronting 的应用场景越来越小，我们也就不打算花很多精力去简化它的配置了。

这里提到直接修改 SNI，不知道是否可行？如果 SNI 没有校验机制应该是可以的？

[SeaHOH]

@linsui 这文章已经讲解地比较详细。
最后说不需要中间人，意思是发出请求的程序自己就能定制包括 SNI 在内的整个 TLS 握手过程。

SNI 是 TLS 的一个扩展，它的用途就是区分服务器，和 Host 并没有内在联系。如果服务器接受 SNI，那么客户端只需要验证 Host 和证书相符，而 SNI 是什么内容就无所谓了。
所谓域前置，就是服务器把 Host 当作 SNI 使用了，是为了支持没有包含 SNI 扩展的握手。这通常用于 CDN，属于实践中的改良技术，把 SNI 的逻辑从 TLS 握手移动到了 HTTP 处理。其安全性由 CDN 服务商确保，客户端只需遵循 RFC 标准即可。
https://zh.wikipedia.org/wiki/服务器名称指示

如 https://hal.inria.fr/hal-01202712/document 这篇论文在实验中制作的火狐扩展 Escape，还有 https://github.com/Xmader/revolter-firefox 就是一个支持 SNI 定制的火狐特别版本。
不过，前者是基于旧版火狐，不清楚当前版本的火狐是否还提供实现此功能所需要的 API。后者已移入 https://github.com/Xu-Ming/revolter-firefox 暂时无法访问。

这里讲个题外话。CDN 服务商和主机服务商不同，它们的权利特别大，可以完全掌握你的托管内容（因为干的就是内容分发），插入、改写什么的都不在话下，所以它们通常也表现地特别在乎声誉，当然信不信就随你了。

[linsui]

@SeaHOH 感谢科普。（Xmader 的项目 star 数并不是很多，居然会被盯上，相比之下，ss-libev 真是奇迹。）
所以不解密 TSL 数据，仅修改 SNI 是否能做到？

[URenko]

@linsui 不能，除非直接修改浏览器，进行TLS前就改掉

[SeaHOH]

你给出的文章讲的很清楚，SNI 是作为 TLS 扩展加入整个握手过程的，所以只能用中间人来修改其它程序的 https 请求。

[linsui]

@URenko @SeaHOH 谢谢。

SNI 是作为 TLS 扩展加入整个握手过程的

所以不仅仅是 ClientHello 包含 SNI，其后的握手包中也有 SNI 所以不能直接改。不知道我理解正确吗？或是有其他校验机制？

[URenko]

不是，握手最后有个对整个握手过程的校验码，你改了到最后就握手失败了

[Xmader]

目前只有 Firefox 的 NSS 支持 ESNI ，并且需要服务端支持。 Wikipedia 不支持 ESNI ，所以需要去掉 SNI ，可以参考 revolter 的实现。 cloudflare 上的网站默认启用 ESNI。

[gomggx]

不是，握手最后有个对整个握手过程的校验码，你改了到最后就握手失败了

经实际测试，剥离 ClientHello 内的 SNI，确实握手失败，感谢讲解

[macronut]

SNI放入TCP Fastopen是可以避免检测的，且Wikipedia支持TFO
但是系统不能稳定的让TFO有效，除非底层介入TCP的数据包，这点比较头疼

[URenko]

SNI放入TCP Fastopen是可以避免检测的，且Wikipedia支持TFO
但是系统不能稳定的让TFO有效，除非底层介入TCP的数据包，这点比较头疼

似乎有些运营商的支持就不好（shadowsocks/shadowsocks-libev#1669 ，这是2018年，不知道现在如何）

[macronut]

如果没有劫持，只是IP地址池或NAT等问题放弃TFO带来的好处只用来规避也行，先发送不带payload的SYN打通NAT再发送带payload的SYN完成连接也是可以的实际等同于3次握手，但同样必须修改TCP包

[URenko]

几天前Firefox自带的DoH（mozilla.cloudflare-dns.com）出现SNI RST

[linsui]

似乎 esni 也受到干扰了。大概是没有 sni 的cloudflare 连接都被阻断了。

[road0001]

似乎 esni 也受到干扰了。大概是没有 sni 的cloudflare 连接都被阻断了。

我抓包实验了一下，并不是被干扰，而是CF那边的锅。在不带SNI、或者带一个假的人畜无害的SNI时，没有出现RST ACK的情况，而是看到了CF返回的结果：“Level: Fatal, Description: Handshake Failure”，将SNI换成正确的就能访问了。

[linsui]

我抓包实验了一下，并不是被干扰，而是CF那边的锅。在不带SNI、或者带一个假的人畜无害的SNI时，没有出现RST ACK的情况，而是看到了CF返回的结果：“Level: Fatal, Description: Handshake Failure”，将SNI换成正确的就能访问了。

我是使用 dnscrypt-proxy 提供的方法使用 esni 的，相比之前，连接成功率低了很多。也有可能是 dnscrypt-proxy 的锅，返回的地址连接性不好 😂

[Xmader]

Update: CloudFlare 只接受长度 小于等于254 作为 servername

GFW 看起来无法处理字符长度 大于 254 的 SNI

https://fars.ee/qzs4.sh/bash

使用: bash ct.sh exhentai.org

可以将 255 改到别的值试试看

根据规范，域名最长是 255 个字节

https://tools.ietf.org/html/rfc1035#section-2.3.4

[nejidev]

我在 apache2.4 上面发布了2个 https 网站，如果不开启 SNI 那么，必须要用2个不同的端口，因为它不知道，你在访问哪个网站。
去掉 SNI 对网站有没有影响，要看服务器是怎么配置的，可以肯定的是： 一个ip 上面挂多个 https 网站的话，不发送 SNI 肯定是不行的。
去掉 SNI 的方法可以，用开源的 Chromium 去掉 openssl 添加 SNI 的底层调用，如果想做的好的话，还可以自己弄个白名单啥的，倒是不太费劲。
关键是去了 SNI @就真的没有其它限制了？

[SeaHOH]

可以肯定的是： 一个ip 上面挂多个 https 网站的话，不发送 SNI 肯定是不行的。

上面提到的所谓域前置模式不会检查 SNI，而是直接根据 Host 路由。

关键是去了 SNI @就真的没有其它限制了？

就像你指出的，主要看服务器端限制，再就是墙的 IP 黑洞。部分服务器限制可以通过伪造的 SNI 绕过。

大的站点如果不是特意限制 (主要是为了安全) 还是比较容易绕过 SNI RST，反倒是使用了免费空间和免费 CDN 的小站会受到域前置禁用的影响而无法使用此方法。

TLS 使用 ECH，QUIC 使用 TLS，HTTP/3 使用 QUIC。现在就看墙如何对待 ECH，估计还是封杀，就像 ESNI 那样，最后大家还是只能伪造 SNI，不过那时就该伪装 HTTP/3 了。

[ghost]

刚才测试GitHub的屏蔽情况和普通的RST有所不同。
#103

github.com 第一次HTTPS握手并不会收到 RST ，但是看起来之后的到对应端口的连接都被路由黑洞屏蔽。

这样的屏蔽方式，在 Greatfire 测试器不会看到被屏蔽（媒体没办法说中国屏蔽了Github），但是用户确实不能使用了。

[ghost]

#103 中的屏蔽方法看起来已经用到 store.steampowered.com 上。见 V2EX 一天前的帖子
Steam 商店 store.steampowered.com 疑似 443 端口被干扰？ ICMP 80 端口均正常
存档 : https://archive.ph/ggtUT

[louiesun]

Cloudflare现在又开始支持ECH了，看看能坚持多久。

[moi-si]

有办法不抓包知道网站是否支持 ECH 吗？

[linsui]

https://test.defo.ie/domainechprobe.php 用这个试试？

[moi-si]

https://test.defo.ie/domainechprobe.php 用这个试试？

几小时前测 www.pixiv.net 能 TLS 1.3 连，应该支持的，但那个说没发布 HTTPS RR。

[louiesun]

有办法不抓包知道网站是否支持 ECH 吗？

一个充分条件是换cloudflare DoH。
在 chrome://net-internals/#dns 查，看看有没有显示公钥。

[louiesun]

https://test.defo.ie/domainechprobe.php 用这个试试？

几小时前测 www.pixiv.net 能 TLS 1.3 连，应该支持的，但那个说没发布 HTTPS RR。

确定不是http3 怼上去的？

Cloudflare原话好像是：
强制为免费计划开启，晚些时候为其他计划提供开启开关。

[moi-si]

确定不是http3 怼上去的？

用的是狐猴，显示 TLS 1.3，不过禁用 QUIC 就失败了，确实是 HTTP/3。

[louiesun]

确定不是http3 怼上去的？

用的是狐猴，显示 TLS 1.3，不过禁用 QUIC 就失败了，确实是 HTTP/3。

xxx.com/cdn-cgi/trace

[jonm58]

除了 pixiv.net , *.pixiv.net 应该都可以上H3,比如:
www.pixiv.net
source.pixiv.net
accounts.pixiv.net
sketch.pixiv.net
imp.pixiv.net
ns1.pixiv.net
ns2.pixiv.net

[jonm58]

有什么网站可以测 TCP Fast Open 吗?

[MDZZ-123]

除了 pixiv.net , *.pixiv.net 应该都可以上H3,比如: www.pixiv.net source.pixiv.net accounts.pixiv.net sketch.pixiv.net imp.pixiv.net ns1.pixiv.net ns2.pixiv.net

能强制浏览器只使用H3吗，不然他一回落到H2又要被RST了

[jonm58]

除了 pixiv.net , *.pixiv.net 应该都可以上H3,比如: www.pixiv.net source.pixiv.net accounts.pixiv.net sketch.pixiv.net imp.pixiv.net ns1.pixiv.net ns2.pixiv.net

能强制浏览器只使用H3吗，不然他一回落到H2又要被RST了

不太可能

[louiesun]

除了 pixiv.net , *.pixiv.net 应该都可以上H3,比如: www.pixiv.net source.pixiv.net accounts.pixiv.net sketch.pixiv.net imp.pixiv.net ns1.pixiv.net ns2.pixiv.net

能强制浏览器只使用H3吗，不然他一回落到H2又要被RST了

不太可能

dns记录的alpn可能有用
chromium 一个command line flag： --origin-to-force-quic-on
参考：https://www.nodeseek.com/post-11469-1

[MDZZ-123]

除了 pixiv.net , *.pixiv.net 应该都可以上H3,比如: www.pixiv.net source.pixiv.net accounts.pixiv.net sketch.pixiv.net imp.pixiv.net ns1.pixiv.net ns2.pixiv.net

能强制浏览器只使用H3吗，不然他一回落到H2又要被RST了

不太可能

dns记录的alpn可能有用 chromium 一个command line flag： --origin-to-force-quic-on 参考：https://www.nodeseek.com/post-11469-1

我是用的火狐。。。
找到一个类似的设置，network.http.http3.alt-svc-mapping-for-testing
不过一旦开了代理，还是会直接变成H2，折腾了几天，发现只有用TUN模式才可能实现H2走代理，H3直连

[maoist2009]

tls标准里有个重协商，如果墙只审查第一个tcp数据包就能用。但是也得看服务器支持。
但明文成这样还不如套万能的tls分片

[louiesun]

话说tls协议返回的证书有加密吗？墙会不会把证书当rst依据？