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 且签名对就没问题。

[SeaHOH]

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

[URenko]

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

好主意

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

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

[SeaHOH]

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

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

[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]

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

[linsui]

@URenko 谢谢，我明白了

[SeaHOH]

有些时候一些基本概念很容易就预设双方都了解，实际上却不一定，所以对于基本概念鼓励大家先自行搜索。 比如搜索 TLS 握手，就能找到许多详解过程的文章。

[Xmader]

只有 ClientHello 包含 SNI，但在握手结束前需要发送整个握手过程的校验信息。虽然 ClientHello 是明文，但校验信息是以加密传输的。

On Aug. 28, 2019 11:07, linsui notifications@github.com wrote:

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

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

[linsui]

@SeaHOH @Xmader 谢谢 （复活了？？？看来只是删除了相关的仓库）

Encrypted Handshake Message(Server)

这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。

之前直接搜索 SNI 防篡改就很难搜到。

[Xmader]

不过，前者是基于旧版火狐，不清楚当前版本的火狐是否还提供实现此功能所需要的 API。

Escape 确信已经无法使用，因为 Escape 使用了 XUL，而 XUL/XPCOM API 从 firefox 57 开始被移除了。firefox 的分支 Pale Moon 浏览器仍然支持 XUL/XPCOM 附加组件 API，应该可以在上面安装。

[SeaHOH]

Escape 本身是没法用了，但它主要功能是使用的 NSS API，对新版火狐不熟悉，所以不清楚是否还提供 NSS API。

[SeaHOH]

@Xmader 还是无法访问，请问方便分享下原因或者 github 的回复吗？

[tec1987]

早就听说过自己改内核编译的firefox，有现成的用了么？

[backup53]

https://github.com/revolter-firefox/revolter-firefox 我这里有 Xmader 大大的项目的备份，希望各位有志之士和我一起重启项目开发

[SeaHOH]

@backup53 你这看起来也不靠谱啊，真名？

[backup53]

@backup53 你这看起来也不靠谱啊，真名？

和老婆移民美帝手续办好了，怕啥？

[SeaHOH]

胆挺肥 :+1: ， 希望你跑快些，不要被最后一颗子弹击中。。。

[tec1987]

。。。。恭喜了，祝一切顺利@backup53

[tec1987]

想自己动手的请参考： https://zh.wikipedia.org/zh-hans/Help_talk:%E5%A6%82%E4%BD%95%E8%AE%BF%E9%97%AE%E7%BB%B4%E5%9F%BA%E7

对我来说改源码容易，折腾编译环境太麻烦了。。。

[mraandtux]

维基IP：198.35.26.96今天突然超时，Accesser如何对相应网站增加IP地址（像以前的版本），绕过DNSCrypt-Proxy提供的结果？ http://ping.chinaz.com/198.35.26.96

[linsui]

可以直接配置 dnscrypt-proxy 返回指定结果

[URenko]

维基IP：198.35.26.96今天突然超时，Accesser如何对相应网站增加IP地址（像以前的版本），绕过DNSCrypt-Proxy提供的结果？ http://ping.chinaz.com/198.35.26.96

前几天就发现了，我还以为是我这里的网络间隙性抽风，原来都是这样，可以修改dnscrypt/cloaking-rules.txt里的内容。新版本已经修复IP。

修改SNI的技术终究会失效（尤其对于维基百科这种IP只有几个的网站），各位且行且珍惜。

[linsui]

目前 dnscrypt-proxy 支持 doh server，可以使用 ESNI ，有支持计划吗？

[URenko]

目前 dnscrypt-proxy 支持 doh server，可以使用 ESNI ，有支持计划吗？

大致地看了一下，似乎Firefox可以直接使用（指无需额外的程序），这样的话就没有额外支持的必要。

[linsui]

Firefox 可以直接使用，但这样和 Accesser 是不兼容的，需要额外配置分流。不知道 Accesser 有没有可能支持出站 ESNI ，这样所有使用 Accesser 的应用都可以使用 ESNI 了。

[URenko]

出站ESNI？指Accesser和远程服务器之间吗？另外这个不兼容的问题好像就是 #15 。

[linsui]

是的，如果 Accesser 可以作为 ESNI 客户端与服务器握手，就可以作为 ESNI 代理。但不知道有没有 python 的 ESNI 实现。 #15 应该就是不兼容导致的，所以目前只能在浏览器端分流。如果 Accesser 支持 ESNI，那么就可以在浏览器不使用 ESNI 达到相同效果。浏览器到 Accesser 这段就无所谓了。

[URenko]

这个与Python关系不大，与底层的OpenSSL是否有ESNI实现有关（当然也可能存在OpenSSL实现了但是Python不提供相应开关的可能，但是就目前而言OpenSSL并未实现，但是也有人做，如https://defo.ie ），包括不兼容大概也与此有关，所以Accesser是不会去主动实现/兼容ESNI的，如果OpenSSL支持了ESNI并且Python使用了这一版本的OpenSSL那么更新Python即可。

[Xmader]

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

[gomggx]

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

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