search

URenko / Accesser

🌏一个解决SNI RST导致维基百科、Pixiv等站点无法访问的工具 | A tool for solving SNI RST
GNU General Public License v3.0
873 stars 77 forks source link

GFW动态和未来展望 #42

Open URenko opened 5 years ago

URenko commented 5 years ago

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

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

macronut commented 4 years ago

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

URenko commented 4 years ago

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

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

macronut commented 4 years ago

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

URenko commented 4 years ago

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

linsui commented 4 years ago

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

road0001 commented 4 years ago

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

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

linsui commented 4 years ago

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

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

Xmader commented 3 years ago

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 commented 3 years ago

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

SeaHOH commented 3 years ago

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

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

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

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

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

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

ghost commented 3 years ago

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

103

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

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

ghost commented 2 years ago

103 中的屏蔽方法看起来已经用到 store.steampowered.com 上。见 V2EX 一天前的帖子

Steam 商店 store.steampowered.com 疑似 443 端口被干扰？ ICMP 80 端口均正常 存档 : https://archive.ph/ggtUT

louiesun commented 2 weeks ago

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

moi-si commented 2 weeks ago

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

linsui commented 2 weeks ago

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

moi-si commented 2 weeks ago

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

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

moi-si commented 2 weeks ago

https://www.gov.cn/yaowen/liebiao/202408/content_6971464.htm

审议通过《加快完善海河流域防洪体系实施方案》和 《网络数据安全管理条例（草案）》，讨论《中华人民共和国海商法（修订草案）》。

我急了，其实这个草案是不是征求意见稿还未知。

louiesun commented 1 week ago

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

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

louiesun commented 1 week ago

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

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

确定不是http3 怼上去的？

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

moi-si commented 1 week ago

确定不是http3 怼上去的？

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