-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
一些实验,完成编辑(请仔细阅读说明和说明中给出的链接) #87
Comments
哇!为大神送水递毛巾。 |
嗯,这个好,让世界明白是咋回事!! |
这样看来,防火墙确实高明了不少。 |
所以啊就很迷XD 继续实验分析中 |
我抓包也发现收到大量伪造包,这些包有同一特征:TTL大于64(本地发包TTL=64)。有没有试验过,在本地与服务器上,丢弃掉TTL大于64的伪造数据包,看看效果如何? |
0.0可以试试233我去做个饭先 |
https://www.v2ex.com/t/395195#reply3 |
@lrinQVQ 大佬要不要试试不用443端口的hosts,就是手机(443)->手机的iptables(443->23333)->国外sni(2333)->手机的iptables(23333->443)->手机(443) PS:安卓上的iptables不懂配置,,,, |
问题是国外运营商的sni并没有提供转发端口功能。 |
@Sharkkkk 不用 443 端口的话估计就需要 https://github.com/googlehosts/chromium 了…… |
不不不,我的意思是想学会这种方法,sni我也是自己搭的,你说的SS我搭了SSR,毕竟手机嘛,开着个SSR耗电耗内存,有了升级版的hosts上网舒服多了,和上国内的一样。@SerCom-KC @SY618 我觉得只需一台手机一台海外服务器即可搞定升级版的hosts。平时也就上上应用商店,搜搜资料而已,其他的基本没有需求 |
0.0这样子的话也不是不可以 昂我看看 |
搬好小板凳等大佬的试验结果和配置教程,弄出来真的是安卓google党的一大福音 |
不过好像我的IP23333端口被ban了 |
233333 |
@ lrinQVQ a 不會又是GFW 自動檢測再block吧 這次監控所有端口?? 2333查了好像是SNAPP的port 不知道 應該避開用過的port (210 端口也沒人用) |
From the outside of SSL, you can only see the server name (client sends it as part of the Server Name Indication extension in the early stages of the SSL handshake; and it also appears in the certificate sent by the server); this may be sufficient to filter out some "URL". E.g. in your example, you can see that the connection is SSL and for www.facebook.com; if you want to block the whole of Facebook, this is sufficient information; the actual URL is not needed. |
@lrinQVQ不會又是GFW 自動檢測再block吧 這次監控所有端口?? 2333查了好像是SNAPP的port 不知道 應該避開用過的port (210 端口也沒人用) |
我猜也是這樣 就是沒試過 這樣的化 GFW 應該監控所有packet 看有沒有google domain 的明文 |
@daiaji ps:本项目ss不支持任何ssr及其衍生的客户端,win请留意dns污染 android请开启DNS转发,openwrt请留意dns污染 |
This comment has been minimized.
This comment has been minimized.
@daiaji 昂很抱歉我的主机没有抗ban能力 我使用的是shadowsokcs-libev而不是所谓的ssr兼容 请无视我的建议 就此停止吧 |
@beyondgfw 好的 您继续使用v2 ss一直没有停止过更新 我们就此停止这个话题 |
非100%确认,只做提醒 |
@SerCom-KC cloudflared是CF Doh的代理软件的名称啦x |
现在对于遭到SNI RST的网站应该是放弃TLS1.3和ESNI而确定使用QUIC协议解决了吧?不知道这项推广需要多长时间以及是否需要各网站的跟进?还有就是浏览器的兼容情况?毕竟如果全都要按照现在访问谷歌(HK)的方法设置的话真的太麻烦了,对于这方面有没有确定的消息? |
@123ysys 基本上都会跟进 新的标准 到时候并不需要按照现在这样设置我会出新的说明 |
@123ysys 参考QUIC Proxy的配置 并不麻烦 |
感谢大佬的解释以及……定心丸。 |
也不是说麻烦,就是感觉在目标那一项下写一连串的网址,太长了。 |
2333不不不我指的 |
4个字:图片挂了 |
没挂啊0.0 |
@123ysys QUIC是一码事 HTTP/3是一码事 |
这个我不确定。
可以啊,现在QUIC被封是因为UDP 443端口受到了干扰,并不是SNI RST的原因。 |
我看QUIC的一些资料 说有些报文还是明文的 |
@tec1987 我第一次知道韩国审查成人内容… |
Google 正式完成并部署了新的TLS后量子密钥交换协议 CECPQ2(HRSS + X25519) |
@lrinQVQ 没毛病 chrome dev可以上 |
Update:2020.1.13 |
NND,前些天github的图片都加载不出来,浏览器一连这几个IP就reset。这是想逼网民造反么? |
是不是可以认为各个省的黑洞路由都有了? |
@123ysys 速度还没这么快 不过估计也不久了 |
Update:2020.1.13
一些封锁方式升级说明:
现在GFW对TCP的干扰更不容易被发现:利用静态路由对指定TCP/UDP端口进行黑洞路由(BGP劫持)
近期发现过两次类似做法
2019.3.8
对部分Telegram中间代理服务器的TCP 8888端口进行劫持
2019.12.29
对部分Github中raw.githubusercontent.com使用的fastly的CDN节点(151.101.228.133,151.101.0.133)的TCP 443端口进行劫持
其表现为,被劫持的TCP端口的RTT非常低,几乎接近访问同省/市网络的速度(猜测黑洞服务器位于同省/市位置) 跟踪任何没被劫持的端口/协议表现都是正常的
Update:2019.11.24
Google 正式完成并部署了新的TLS后量子密钥交换协议 CECPQ2(HRSS + X25519)
欢迎使用Chrome/Chromium Dev/Canary 最新版本的浏览器并且配合本项目hosts对 https://www.google.com/ncr 进行测试
Update:2018.10.16
非100%确认,只做提醒
经过几天的观测
GFW在部分地区开始对无SNI的1.1.1.1 https连接进行丢包 or 连接重置 (针对DoH)
概率:调查的10位中有8位出现
其中6位测试了使用浏览器打开https://1.1.1.1 没有被rst
使用cloudflared 作为DNS代理时出现丢包 or 连接重置的情况
104.16.111.25和104.16.112.25可能也会继续更进(1位报告有无法解析的情况)
Update time:2018.10.23
咩做了一系列测试来验证最近的封锁情况
如果不想看后面的实验内容我就简单的说明下:
GFW根据rfc6066 第3章节Server Name Indication中要求client hello中包含server_name(比如:你访问的是www.google.com,这里的server_name就是www.google.com 如果需要验证 请看下面的实验) 并且这部分为明文,gfw只需要根据此这部分信息进行过滤即可(如果需要验证 请看下面的实验)
解决方案:QUIC
解决方案:TLS1.3+ [ESNI?](个人并不认可现在cloudflare的DNS ESNI方案,过于依赖DNS) 完成在更新时(2018.10.23)的ESNI草案就是类似与域前置的方案
我依然坚持基于PSK的跟进实现:https://github.com/QVQNetwork/ssl-patch
如果近期急用可以暂时使用:https://github.com/googlehosts/hosts/wiki/%E5%AE%9E%E9%AA%8C%E5%AE%A4#shadowsocks
测试环境:
OS: Ubuntu 18.04
Network:China Telecom
Software: Wireshark v2.9.0 hping3
SNI Server Software:
Chrome: 版本 70.0.3528.4(正式版本)dev (64 位)
结论:见最开始说明
1.首先我拿纽约时报的中文域名做了测试
hping3不断尝试向443端口发送SYN(-S[既TCP握手第一步建立连接])并没有被完全阻断,但是能明显看rtt=0.0 ms无法握手 网页被RST
并且间歇性的可以握手
2.接下来就该实际访问测试了
我们使用Chrome强制https://cn.nytimes.com/
Wireshark 中我们可以明显看到在Client Hello后ACK环节直接RST重置,GG 关于这一块去看看维基百科的无状态TCP协议连接重置介绍就知道了我也不多做说明
找到了原因让我们想一想gfw是如何判断这个IP是友军还是敌人呢昂
我先把最关键的提到前面
猜想四
我们在访问一个https网站时 第一步就是发送Client Hello,而RST也正好发生在Client Hello之后,那我们来看看Client Hello的时候到底发生了什么
我们可以直接在二进制内容中看到明文的cn.nytimes.com Server Name信息
GFW不需要任何解密 只需要根据明文的Server Name中的域名进行判断,向客户端发送一个TCP RST的包即可
我的wireshark抓包日志:nytimes.zip
后面的实验并非关键问题,我就懒得在重新做一次了结果一样
猜想一
会不会是因为gfw利用openssl分析IP的证书从而进行封锁的呢(例如:echo | openssl s_client -connect $ip:443 2>/dev/null | openssl x509 -text | grep -A1 "Subject Alternative Name:" | tail -n1 | tr -d ' ' | tr ',' '\n'
发现有关关键字的域名就封锁,于是为了验证我的猜想,我直接拿现在这个IP进行测试
echo | openssl s_client -connect 54.182.4.198:443 2>/dev/null | openssl x509 -text | grep -A1 "Subject Alternative Name:" | tail -n1 | tr -d ' ' | tr ',' '\n'
DNS:*.predix.io
DNS:predix.io
可以说和cn.nytimes.com没有一丁点关系
为了进一步验证
我要到了一台垃圾香港服务器,IP:45.124.64.82 使用Haproxy进行代理
我的配置如下:
我强制要求了TLS1.3并且也手动编译openssl master分支支持TLS1.3 draft-21 ,并且也手动编译了Haproxy 1.8-dev2-f57a29a 以支持openssl master 和tls1.3 draft-21 ()并且我还启用了AEAD CHACHA20-POLY1305级别的加密算法
Haproxy配置文件
global
#uid root
#gid root
daemon
maxconn 100
tune.ssl.default-dh-param 2048
ssl-default-server-options force-tlsv13
ssl-default-bind-options force-tlsv13
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
ssl-default-server-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
defaults
timeout connect 1000
timeout client 5000
timeout server 5000
frontend www-https
bind :443
mode http
#option forwardfor
acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.google.com
acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.youtube.com
acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.googlevideo.com
acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.kik.com
acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.nytimes.com
reqadd X-Forwarded-Proto:\ https
default_backend google
#redirect scheme https if !{ ssl_fc }
backend google
mode http
balance roundrobin
redirect scheme https if !{ ssl_fc }
你们可以用任何方案对这个IP进行证书查询查到算我输
我自行测试的结果
openssl s_client -trace 45.124.64.82:443 2>/dev/null | openssl x509 -text
unable to load certificate
140586051438464:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:748:Expecting: TRUSTED CERTIFICATE
接着我再次修改了一下服务器的设置
加入了acl www-https hdr_reg(host) -i ^[a-zA-Z0-9_]+.nytimes.com 确保测试的一致性
然后感谢@Sharkkkk 提供的方案 忽略掉RST
客户端和服务器都加入了iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP 结果请见#64
接着我把我自己的IP带入hosts为了一致性我把ip给了cn.nytimes.com
继续hping3测试不停,并且访问网页
从截图中可以看到访问之前hping3 -S -p 443 是无干扰的
在尝试打开网页后 出现了干扰丢包的情况,并且依旧是在SYN后的第二步ACK确定是否做了正确的应答的时候,就很明显没有了,然后直接RST重置,GG
所以很明显不怪CA证书
猜想二
TCP协议的问题(并不是TCP的锅)因为每次被重置都是在TCP握手的阶段,SYN-ACK-RST 所以我们无法排除但是也无法确认一定就是TCP的问题,这一块我也还在一点一点的测试等我有了确切的证据和验证方案我会继续更新,现在反而让我更加感觉是协议的问题了
猜想三
端口封锁(非核心原因)
感谢@Sharkkkk 提供了一个博客,里面提到了利用端口转发来处理针对端口的过滤,
首先我说说这个方案的原理,利用iptables进行端口转发
首先我们先确定我们要转发的IP和域名:
216.58.203.36 www.google.com
//在传东西稍后补图好了XD
好接下来我们在vps和手机上都进行开启ipv4转发的操作
vim /etc/sysctrl.conf加入net.ipv4.ip_forward=1
并且sysctl -p使其生效,我们可以看到
ipv4转发已经生效
android在有root的情况下直接shell:
echo 1 > /proc/sys/net/ipv4/ip_forward
开启ipv4转发
接着开始我们的骚操作233
iptables -t nat -A PREROUTING -d 45.124.64.82 -p tcp --dport 23333 -j DNAT --to-destination 216.58.203.36:443
iptables -t nat -A POSTROUTING -j MASQUERADE
首先让服务器的23333端口去中转216.58.203.36的443端口 并且修改数据包流向
然后就是Android上面的操作了
首先iptables -t nat -A OUTPUT -d 216.58.203.36 -p tcp --dport 443 -j DNAT --to-destination 45.124.64.82:23333
iptables -t nat -A INPUT -d 45.124.64.82 -p tcp --dport 23333 -j SNAT --to-source 216.58.203.36
将216.58.203.36 443端口的请求转发至45.124.64.82:23333
接着
端口之间的互相转发完成啦~
让我们实际测试下
curl -av https://216.58.203.36
输出
curl -av https://216.58.203.36
CApath: /system/etc/security/cacerts
curl: (51) SSL: no alternative certificate subject name matches target host name '216.58.203.36'
看来TLS部分一切顺利啊
然后我用Chrome实际进行了访问,确实能够正常访问,然而只是第一次可行
接着我们再次进行curl -av https://216.58.203.36 测试
就卡在了
51|capricorn:/ $ curl -av https://216.58.203.36
curl: (7) Failed to connect to 216.58.203.36 port 443: Connection timed out
于是又一次gg bomm
2333怀疑是公开测试的问题于是我私下换了端口 把23333 换到了 2333
然后还是之前的配置
第一次curl -av https://216.58.203.36尝试依旧成功
然后继续打开Chrome~成功访问web
接着再次curl -av https://216.58.203.36
capricorn:/ $ curl -av https://216.58.203.36
curl: (7) Failed to connect to 216.58.203.36 port 443: Connection timed out
然后我又去换了一个新的IP继续测试
还是之前的配置
第一次curl -av https://216.58.203.36尝试依旧成功
然后继续打开Chrome~成功访问网页
然后再次curl -av https://216.58.203.36
curl -av https://216.58.203.36
CApath: /system/etc/security/cacerts
curl: (35) Unknown SSL protocol error in connection to 216.58.203.36:443
TLS握手完成(很玄学第一次完成了的),然后gg
The text was updated successfully, but these errors were encountered: