search

googlehosts / hosts

镜像：https://scaffrey.coding.net/p/hosts/git / https://git.qvq.network/googlehosts/hosts
Other
20.82k stars 10.21k forks source link

一些实验,完成编辑(请仔细阅读说明和说明中给出的链接) #87

Open lrinQVQ opened 7 years ago

lrinQVQ commented 7 years ago

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 2018-08-25 13-04-39 并且间歇性的可以握手 2018-08-25 13-08-26

2.接下来就该实际访问测试了 我们使用Chrome强制https://cn.nytimes.com/ 2018-08-25 13-11-21

Wireshark 中我们可以明显看到在Client Hello后ACK环节直接RST重置,GG 关于这一块去看看维基百科的无状态TCP协议连接重置介绍就知道了我也不多做说明

找到了原因让我们想一想gfw是如何判断这个IP是友军还是敌人呢昂 我先把最关键的提到前面 猜想四 我们在访问一个https网站时 第一步就是发送Client Hello,而RST也正好发生在Client Hello之后,那我们来看看Client Hello的时候到底发生了什么 2018-08-25 13-58-49 我们可以直接在二进制内容中看到明文的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 2017-10-04 20-19-50 接着我再次修改了一下服务器的设置 加入了acl www-https hdrreg(host) -i ^[a-zA-Z0-9]+.nytimes.com 确保测试的一致性 然后感谢@Sharkkkk 提供的方案 忽略掉RST 客户端和服务器都加入了iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP 结果请见https://github.com/googlehosts/hosts/issues/64 接着我把我自己的IP带入hosts为了一致性我把ip给了cn.nytimes.com 继续hping3测试不停,并且访问网页 2017-10-04 21-04-43 从截图中可以看到访问之前hping3 -S -p 443 是无干扰的 在尝试打开网页后 出现了干扰丢包的情况,并且依旧是在SYN后的第二步ACK确定是否做了正确的应答的时候,就很明显没有了,然后直接RST重置,GG 所以很明显不怪CA证书

猜想二 TCP协议的问题(并不是TCP的锅) 因为每次被重置都是在TCP握手的阶段,SYN-ACK-RST 所以我们无法排除但是也无法确认一定就是TCP的问题,这一块我也还在一点一点的测试等我有了确切的证据和验证方案我会继续更新,现在反而让我更加感觉是协议的问题了

猜想三 端口封锁(非核心原因) 感谢@Sharkkkk 提供了一个博客,里面提到了利用端口转发来处理针对端口的过滤, 首先我说说这个方案的原理,利用iptables进行端口转发 首先我们先确定我们要转发的IP和域名: 2017-10-07 20-09-54

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

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

然后我又去换了一个新的IP继续测试 还是之前的配置 第一次curl -av https://216.58.203.36尝试依旧成功 然后继续打开Chrome~成功访问网页 然后再次curl -av https://216.58.203.36 curl -av https://216.58.203.36

123ysys commented 7 years ago

哇！为大神送水递毛巾。

birdofprey commented 7 years ago

嗯，这个好，让世界明白是咋回事！！

ghost commented 7 years ago

这样看来，防火墙确实高明了不少。 能在TCP握手阶段识别并重置，按理说SYN-ACK握手包里不包含你要访问的网站详细信息。

lrinQVQ commented 7 years ago

所以啊就很迷XD 继续实验分析中 还有一种猜测也有可能是根据动态路由表 比如根据Github上公布的hosts SNI也好 官方IP也好 应该已经找到了规律并且掌握了动态路由表

ghost commented 7 years ago

我抓包也发现收到大量伪造包，这些包有同一特征：TTL大于64（本地发包TTL=64）。有没有试验过，在本地与服务器上，丢弃掉TTL大于64的伪造数据包，看看效果如何？

lrinQVQ commented 7 years ago

0.0可以试试233我去做个饭先

ghost commented 7 years ago

https://www.v2ex.com/t/395195#reply3 这个帖子的研究可以参考下

Sharkkkk commented 7 years ago

@lrinQVQ 大佬要不要试试不用443端口的hosts，就是手机（443）->手机的iptables（443->23333）->国外sni(2333)->手机的iptables（23333->443）->手机（443） PS:安卓上的iptables不懂配置，，，， 教程：http://blog.ayanamist.com/2012/06/24/android%E6%89%8B%E6%9C%BA%E4%B8%8Aiptables%E5%AE%9E%E7%8E%B0%E9%AB%98%E7%BA%A7hosts.html

ghost commented 7 years ago

问题是国外运营商的sni并没有提供转发端口功能。 要是自建sni服务器，那何不如自建成ss服务器来用更直接。

SerCom-KC commented 7 years ago

@Sharkkkk 不用 443 端口的话估计就需要 https://github.com/googlehosts/chromium 了…… 不过同意楼上，还不如自己搭代理。

Sharkkkk commented 7 years ago

不不不，我的意思是想学会这种方法，sni我也是自己搭的，你说的SS我搭了SSR，毕竟手机嘛，开着个SSR耗电耗内存，有了升级版的hosts上网舒服多了，和上国内的一样。@SerCom-KC @sy618

我觉得只需一台手机一台海外服务器即可搞定升级版的hosts。平时也就上上应用商店，搜搜资料而已，其他的基本没有需求

lrinQVQ commented 7 years ago

0.0这样子的话也不是不可以 昂我看看

Sharkkkk commented 7 years ago

搬好小板凳等大佬的试验结果和配置教程，弄出来真的是安卓google党的一大福音

lrinQVQ commented 7 years ago

按照这个逻辑我进行了漫漫测试233我总结下 貌似确实可行2333 之前网络不好差点以为失败 @Sharkkkk @sy618 2333但是有个问题 几分钟后就ban掉了对应端口

lrinQVQ commented 7 years ago

不过好像我的IP23333端口被ban了

123ysys commented 7 years ago

233333

oakaigh commented 7 years ago

@ lrinQVQ a 不會又是GFW 自動檢測再block吧 這次監控所有端口?? 2333查了好像是SNAPP的port 不知道 應該避開用過的port (210 端口也沒人用)

oakaigh commented 7 years ago

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.

https://security.stackexchange.com/questions/48077/is-there-any-solution-for-block-the-https-traffic-using-url-filtering

oakaigh commented 7 years ago

@lrinQVQ不會又是GFW 自動檢測再block吧 這次監控所有端口?? 2333查了好像是SNAPP的port 不知道 應該避開用過的port (210 端口也沒人用)

jojo729 commented 7 years ago

这分明就是ssl设计有问题，说好的加密传输，可是hello包却带上域名信息。而且检测这个信息根本不需要多少成本，只是简单的文本匹配，甚至比以前的http匹配还要简单。 不过通过ip也是能知道大概访问了什么网站的，so, 带不带域名信息也就无关紧要了，尴尬...... 会开完了，如果还不行，看来hosts真是要退出舞台了，仓管准备删仓库吧2333

xxxx

oakaigh commented 7 years ago

我猜也是這樣 就是沒試過 這樣的化 GFW 應該監控所有packet 看有沒有google domain 的明文

oakaigh commented 7 years ago

那怎麼設計更安全(對於GFW) (現在這樣已經夠安全了至少破解不了什麼密碼什麼的, 不用google 的人就無所謂)

oakaigh commented 7 years ago

23333 太可怕

SerCom-KC commented 7 years ago

所以说要从协议上改变嘛233 https://github.com/googlehosts/chromium

ghost commented 7 years ago

确实是使用简单粗暴的关键词匹配而已。

oakaigh commented 7 years ago

中國互聯網因為GFW變得不安全

oakaigh commented 7 years ago

那天要發展到破解加密就GG mm credit card也別玩了

oakaigh commented 7 years ago

@billy1999 看看1.3呢 估計也沒用 開完會說不定放開一點 現在如果網域是hahFkGFWgoogle.com也不能用了吧

lrinQVQ commented 7 years ago

@billy1999 2333 tls 1.3貌似并不带啊 我全部部署了master分支的openssl 在hello包里面没有找到任何域名相关内容欸 //不过确实Hello自带域名信息2333就跟没加密一样 顺便提示www.kik.com就是用的TLS 1.3在用1.2的时候我init了commit但是无效 在他升级到1.3之后就万事大吉了 嘛= =话说成为历史的我可以理解为挑衅嘛23333／／开玩笑的

jinyumarine commented 7 years ago

老D的hosts可以使用，但是YouTube无法加载视频

lrinQVQ commented 7 years ago

==楼上啊能不能别提其他的XD 2333他用SNI的啊 反正我们是不用SNI的

jojo729 commented 7 years ago

@lrinQVQ 大佬，tls1.3 客户端发的hello也带域名呀，chrome 开启tls1.3 访问https://blog.cloudflare.com/introducing-tls-1-3/ (这个站开启了tls1.3) 22222

jojo729 commented 7 years ago

奇怪的是老D的hosts为什么可以访问呢，那个发出的hello信息也是带域名信息的额，诡异

GLingDroid commented 7 years ago

因为这个sni在墙内，只有出口上才检测

lrinQVQ commented 7 years ago

@billy1999 Chrome的 tls1.3 draft 有问题2333 == 你试试最后那个2333 顺便public的时候我会改的

ghost commented 7 years ago

因为现在*.google.com并没有被重置啊，所以sni可以正常用。 你可以试试*.twitter.com用sni，那链接必断！

你们有条件的试验下： vps部署sni，并且使用tls1.3来访问mobile.twitter.com 看看是否也会被连接重置。

GLingDroid commented 7 years ago

youtube只要连接上了就可以一直上（pc上还可以有几率刷出视频，手机上一直不行），但同时新开连接google.com则被全部重置， 这样子的墙也很迷啊。。。

huanjue commented 7 years ago

twitter还可以SNI正常用。 这是不是网信办放了一马？

在 2017-10-08 20:28:50，"sy618" notifications@github.com 写道：

因为现在.google.com并没有被重置啊，所以sni可以正常用。 你可以试试.youtube.com用sni，那链接必断！

你们有条件的试验下： vps部署sni，并且使用tls1.3来访问m.youtube.com 看看是否也会被连接重置。

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

jinyumarine commented 7 years ago

老D的youtube可以连接，但是加载不了视频 @sy618

oakaigh commented 7 years ago

YouTube RST路過 laod hosts Google ip 以封

SerCom-KC commented 7 years ago

@huanjue 实测 api.twitter.com SNI 先 RESET 再 TIMED OUT，确定不是国内中转/忘关代理/IPv6？

birdofprey commented 7 years ago

这技术分析多好滴，第一可以让世界知道真相，第二分析清楚了也是对新技术的提高。值得称赞致敬和学习

oakaigh commented 7 years ago

@billy1999 老D HOSTS 用的是HK TENCENT CLOUD. 现在被墙

oakaigh commented 7 years ago

hk-CN线路走GFW吧

oakaigh commented 7 years ago

否则HK Google也在Hong Kong被墙啊

lyflyflxf commented 7 years ago

TENCENT开始和GFW联动封SNI了啊，某些DNS也遭殃了

daiaji commented 7 years ago

@lrinQVQ 不止SNI certificate证书那个包好像也是明文的 而且有域名 http://www.lsablog.com/protocol/https/https-analysis/

Just2co commented 7 years ago

@lrinQVQ 看来，要趁TLSv1.3还没大规模启用之前，赶紧给OPENSSL等相关SSL项目组致函，要求在握手阶段不能泄露任何明文访问信息并且不能轻易被深度包检测技术DPI探针刺探出流量指纹来，方便GFW选择性阻断。

ghost commented 7 years ago

@Just2co 确实需要一个好的方法处理现在的状况

lrinQVQ commented 7 years ago

XD我去试试吧