Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
lrinQVQ opened this issue Oct 4, 2017 · 129 comments
Open

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

lrinQVQ opened this issue Oct 4, 2017 · 129 comments
Labels
Meta

Comments

@lrinQVQ
Copy link
Contributor

lrinQVQ commented Oct 4, 2017 •
edited
Loading

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 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测试不停,并且访问网页
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

  • Rebuilt URL to: https://216.58.203.36/
  • Trying 216.58.203.36...
  • Connected to 216.58.203.36 (216.58.203.36) port 443 (#0)
  • libcurl is now using a weak random seed!
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@strength
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /system/etc/security/cacerts
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
  • start date: Sep 26 11:27:05 2017 GMT
  • expire date: Dec 19 11:00:00 2017 GMT
  • subjectAltName does not match 216.58.203.36
  • SSL: no alternative certificate subject name matches target host name '216.58.203.36'
  • Closing connection 0
  • TLSv1.2 (OUT), TLS alert, Client hello (1):
    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
  • Rebuilt URL to: https://216.58.203.36/
  • Trying 216.58.203.36...
  • connect to 216.58.203.36 port 443 failed: Connection timed out
  • Failed to connect to 216.58.203.36 port 443: Connection timed out
  • Closing connection 0
    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

  • Rebuilt URL to: https://216.58.203.36/
  • Trying 216.58.203.36...
  • connect to 216.58.203.36 port 443 failed: Connection timed out
  • Failed to connect to 216.58.203.36 port 443: Connection timed out
  • Closing connection 0
    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

  • Rebuilt URL to: https://216.58.203.36/
  • Trying 216.58.203.36...
  • Connected to 216.58.203.36 (216.58.203.36) port 443 (#0)
  • libcurl is now using a weak random seed!
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@strength
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /system/etc/security/cacerts
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • Unknown SSL protocol error in connection to 216.58.203.36:443
  • Closing connection 0
    curl: (35) Unknown SSL protocol error in connection to 216.58.203.36:443
    TLS握手完成(很玄学第一次完成了的),然后gg
@123ysys
Copy link

123ysys commented Oct 4, 2017

哇！为大神送水递毛巾。

@birdofprey
Copy link

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

@beyondgfw beyondgfw added the Meta label Oct 4, 2017
@MeABc MeABc mentioned this issue Oct 4, 2017
Open
@lrinQVQ lrinQVQ mentioned this issue Oct 4, 2017
Closed
@lrinQVQ lrinQVQ changed the title 一些测试 一些测试,猜测一完成,猜测二继续实验中 Oct 4, 2017
@ghost
Copy link

ghost commented Oct 5, 2017

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

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 5, 2017 •
edited
Loading

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

@ghost
Copy link

ghost commented Oct 5, 2017

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

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 5, 2017

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

@ghost
Copy link

ghost commented Oct 5, 2017

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

@Sharkkkk
Copy link

Sharkkkk commented Oct 6, 2017

@lrinQVQ 大佬要不要试试不用443端口的hosts，就是手机（443）->手机的iptables（443->23333）->国外sni(2333)->手机的iptables（23333->443）->手机（443） PS:安卓上的iptables不懂配置，，，，
教程：http:https://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
Copy link

ghost commented Oct 6, 2017

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

@SerCom-KC
Copy link
Contributor

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

@Sharkkkk
Copy link

Sharkkkk commented Oct 6, 2017 •
edited
Loading

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

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

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 6, 2017

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

@Sharkkkk
Copy link

Sharkkkk commented Oct 7, 2017

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

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 7, 2017 •
edited
Loading

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

@lrinQVQ lrinQVQ changed the title 一些测试,猜测一完成,猜测二继续实验中 一些测试,猜测一完成,猜测三可行,猜测二继续实验中 Oct 7, 2017
@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 7, 2017

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

@lrinQVQ lrinQVQ changed the title 一些测试,猜测一完成,猜测三可行,猜测二继续实验中 一些测试,猜测一完成,猜测三不推荐,猜测二继续实验中 Oct 7, 2017
@lrinQVQ lrinQVQ changed the title 一些测试,猜测一完成,猜测三不推荐,猜测二继续实验中 一些测试,猜测一完成,猜测二继续实验中 Oct 7, 2017
@lrinQVQ lrinQVQ changed the title 一些测试,猜测一完成,猜测二继续实验中 一些测试,猜测一完成,猜测三可行,但会被几分钟后ban掉对应端口,猜测二继续实验中 Oct 7, 2017
@lrinQVQ lrinQVQ changed the title 一些测试,猜测一完成,猜测三可行,但会被几分钟后ban掉对应端口,猜测二继续实验中 一些测试,猜测一完成,猜测三短时间可行,但会被几分钟后ban掉对应端口,猜测二继续实验中 Oct 7, 2017
@123ysys
Copy link

123ysys commented Oct 7, 2017

233333

@oakaigh
Copy link

oakaigh commented Oct 8, 2017

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

@oakaigh
Copy link

oakaigh commented Oct 8, 2017

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
Copy link

oakaigh commented Oct 8, 2017

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

@jojo729
Copy link

jojo729 commented Oct 8, 2017

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

xxxx

@oakaigh
Copy link

oakaigh commented Oct 8, 2017

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

@beyondgfw
Copy link
Member

@daiaji ps:本项目ss不支持任何ssr及其衍生的客户端,win请留意dns污染 android请开启DNS转发,openwrt请留意dns污染

@daiaji

This comment has been minimized.

Sign in to view
@beyondgfw
Copy link
Member

@daiaji 昂很抱歉我的主机没有抗ban能力 我使用的是shadowsokcs-libev而不是所谓的ssr兼容 请无视我的建议 就此停止吧

@beyondgfw
Copy link
Member

@beyondgfw 好的 您继续使用v2 ss一直没有停止过更新 我们就此停止这个话题

@SerCom-KC SerCom-KC mentioned this issue Oct 15, 2018
Closed
@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 16, 2018 •
edited by SerCom-KC
Loading

非100%确认,只做提醒
经过几天的观测
GFW在部分地区开始对无SNI的1.1.1.1 https连接进行丢包 or 连接重置 (针对DoH)
概率:调查的10位中有8位出现
其中6位测试了使用浏览器打开https://1.1.1.1 没有被rst
使用cloudflare 作为DNS代理时出现丢包 or 连接重置的情况
104.16.111.25和104.16.112.25可能也会继续更进(1位报告有无法解析的情况)

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Oct 16, 2018

@SerCom-KC cloudflared是CF Doh的代理软件的名称啦x

@Ir1d Ir1d pinned this issue Dec 19, 2018
@123ysys
Copy link

123ysys commented Jan 27, 2019 •
edited
Loading

现在对于遭到SNI RST的网站应该是放弃TLS1.3和ESNI而确定使用QUIC协议解决了吧？不知道这项推广需要多长时间以及是否需要各网站的跟进？还有就是浏览器的兼容情况？毕竟如果全都要按照现在访问谷歌（HK）的方法设置的话真的太麻烦了，对于这方面有没有确定的消息？
另外听@beyondgfw 大佬说估计春节期间会有动作，不知道是什么？

@beyondgfw
Copy link
Member

@123ysys 基本上都会跟进 新的标准 到时候并不需要按照现在这样设置我会出新的说明

@beyondgfw
Copy link
Member

@123ysys 参考QUIC Proxy的配置 并不麻烦

@123ysys
Copy link

123ysys commented Jan 27, 2019

@123ysys 基本上都会跟进 新的标准 到时候并不需要按照现在这样设置我会出新的说明

感谢大佬的解释以及……定心丸。

@123ysys
Copy link

123ysys commented Jan 27, 2019

@123ysys 参考QUIC Proxy的配置 并不麻烦

也不是说麻烦，就是感觉在目标那一项下写一连串的网址，太长了。

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Jan 27, 2019

@123ysys 参考QUIC Proxy的配置 并不麻烦

也不是说麻烦，就是感觉在目标那一项下写一连串的网址，太长了。

2333不不不我指的
https://github.com/googlehosts/hosts/wiki/Google-Chrome-QUIC-Proxy-%E7%99%BD%E5%90%8D%E5%8D%95%E6%B7%BB%E5%8A%A0%E6%96%B9%E6%B3%95
这个版本,我依旧不推荐使用,即使这是我们自建的代理服务器

@GoogleHostsSupport GoogleHostsSupport mentioned this issue Mar 30, 2019
Closed
@liuxinyu970226
Copy link

4个字：图片挂了

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Apr 23, 2019

4个字：图片挂了

没挂啊0.0

@GoogleHostsSupport GoogleHostsSupport mentioned this issue Apr 25, 2019
Merged
@daiaji
Copy link

daiaji commented Aug 26, 2019 •
edited
Loading

@123ysys QUIC是一码事 HTTP/3是一码事
而且google的QUIC抗TCP RST吗？
一般来说 被推广可能性更高的是HTTP/3吧

@123ysys
Copy link

123ysys commented Aug 27, 2019 •
edited
Loading

QUIC是一码事 HTTP/3是一码事

这个我不确定。

而且google的QUIC抗TCP RST吗？

可以啊，现在QUIC被封是因为UDP 443端口受到了干扰，并不是SNI RST的原因。

@daiaji
Copy link

daiaji commented Sep 8, 2019 •
edited
Loading

QUIC是一码事 HTTP/3是一码事

这个我不确定。

而且google的QUIC抗TCP RST吗？

可以啊，现在QUIC被封是因为UDP 443端口受到了干扰，并不是SNI RST的原因。

我看QUIC的一些资料 说有些报文还是明文的
具体有影响吗？

@tec1987
Copy link

tec1987 commented Oct 20, 2019

我们的邻居现在也不好过啊。。。
https://namu.wiki/w/2019%EB%85%84%20%EC%9D%B8%ED%84%B0%EB%84%B7%20%EA%B2%80%EC%97%B4%20%EB%85%BC%EB%9E%80

@daiaji
Copy link

daiaji commented Oct 20, 2019

@tec1987 我第一次知道韩国审查成人内容…
看了一下审查的内容，这和兲朝也没什么两样。

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Nov 25, 2019

Google 正式完成并部署了新的TLS后量子密钥交换协议 CECPQ2(HRSS + X25519)
欢迎使用Chrome/Chromium Dev/Canary 最新版本的浏览器并且配合本项目hosts对 https://www.google.com/ncr 进行测试

@daiaji
Copy link

daiaji commented Jan 3, 2020

@lrinQVQ 没毛病 chrome dev可以上

@lrinQVQ
Copy link
Contributor Author

lrinQVQ commented Jan 13, 2020

Update:2020.1.13
一些封锁方式升级说明,详见正文

@tec1987
Copy link

tec1987 commented Jan 13, 2020

NND，前些天github的图片都加载不出来，浏览器一连这几个IP就reset。这是想逼网民造反么？

@123ysys
Copy link

123ysys commented Jan 13, 2020

被劫持的TCP端口的RTT非常低,几乎接近访问同省/市网络的速度(猜测黑洞服务器位于同省/市位置)

是不是可以认为各个省的黑洞路由都有了？

@beyondgfw
Copy link
Member

@123ysys 速度还没这么快 不过估计也不久了

@123ysys
Copy link

123ysys commented Aug 10, 2020

一篇一手研究报道，此报道与其他的几个报道都被多次引用。
https://www.iyouport.org/%E6%8A%A5%E5%91%8A%EF%BC%9A%E4%B8%AD%E5%9B%BD%E7%9A%84%E9%98%B2%E7%81%AB%E9%95%BF%E5%9F%8E%E5%B7%B2%E7%BB%8F%E5%B0%81%E9%94%81%E5%8A%A0%E5%AF%86%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%90%8D%E7%A7%B0%E6%8C%87/amp/

如果情况属实，那看来对手找我们一步。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Meta
Milestone
No milestone
Development

No branches or pull requests