一些实验,完成编辑(请仔细阅读说明和说明中给出的链接)
lrinQVQ opened this issue · 129 comments
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
- 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
哇！为大神送水递毛巾。
嗯，这个好，让世界明白是咋回事！！
这样看来，防火墙确实高明了不少。
能在TCP握手阶段识别并重置，按理说SYN-ACK握手包里不包含你要访问的网站详细信息。
所以啊就很迷XD 继续实验分析中
还有一种猜测也有可能是根据动态路由表 比如根据Github上公布的hosts SNI也好 官方IP也好 应该已经找到了规律并且掌握了动态路由表
我抓包也发现收到大量伪造包，这些包有同一特征：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不懂配置，，，，
教程：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
问题是国外运营商的sni并没有提供转发端口功能。
要是自建sni服务器，那何不如自建成ss服务器来用更直接。
@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 端口也沒人用)
这分明就是ssl设计有问题，说好的加密传输，可是hello包却带上域名信息。而且检测这个信息根本不需要多少成本，只是简单的文本匹配，甚至比以前的http匹配还要简单。
不过通过ip也是能知道大概访问了什么网站的，so, 带不带域名信息也就无关紧要了，尴尬......
会开完了，如果还不行，看来hosts真是要退出舞台了，仓管准备删仓库吧2333
我猜也是這樣 就是沒試過 這樣的化 GFW 應該監控所有packet 看有沒有google domain 的明文
那怎麼設計更安全(對於GFW) (現在這樣已經夠安全了至少破解不了什麼密碼什麼的, 不用google 的人就無所謂)
23333 太可怕
所以说要从协议上改变嘛233 https://github.com/googlehosts/chromium
确实是使用简单粗暴的关键词匹配而已。
中國互聯網因為GFW變得不安全
那天要發展到破解加密就GG mm credit card也別玩了
@billy1999 看看1.3呢 估計也沒用 開完會說不定放開一點 現在如果網域是hahFkGFWgoogle.com也不能用了吧
@billy1999 2333 tls 1.3貌似并不带啊 我全部部署了master分支的openssl 在hello包里面没有找到任何域名相关内容欸 //不过确实Hello自带域名信息2333就跟没加密一样
顺便提示www.kik.com就是用的TLS 1.3在用1.2的时候我init了commit但是无效 在他升级到1.3之后就万事大吉了
嘛= =话说成为历史的我可以理解为挑衅嘛23333／／开玩笑的
老D的hosts可以使用，但是YouTube无法加载视频
==楼上啊能不能别提其他的XD 2333他用SNI的啊 反正我们是不用SNI的
@lrinQVQ 大佬，tls1.3 客户端发的hello也带域名呀，chrome 开启tls1.3 访问https://blog.cloudflare.com/introducing-tls-1-3/ (这个站开启了tls1.3)
奇怪的是老D的hosts为什么可以访问呢，那个发出的hello信息也是带域名信息的额，诡异
因为这个sni在墙内，只有出口上才检测
@billy1999 Chrome的 tls1.3 draft 有问题2333 == 你试试最后那个2333 顺便public的时候我会改的
因为现在*.google.com并没有被重置啊，所以sni可以正常用。
你可以试试*.twitter.com用sni，那链接必断！
你们有条件的试验下：
vps部署sni，并且使用tls1.3来访问mobile.twitter.com
看看是否也会被连接重置。
youtube只要连接上了就可以一直上（pc上还可以有几率刷出视频，手机上一直不行），但同时新开连接google.com则被全部重置，
这样子的墙也很迷啊。。。
老D的youtube可以连接，但是加载不了视频 @SY618
YouTube RST路過 laod hosts Google ip 以封
@huanjue 实测 api.twitter.com SNI 先 RESET 再 TIMED OUT，确定不是国内中转/忘关代理/IPv6？
这技术分析多好滴，第一可以让世界知道真相，第二分析清楚了也是对新技术的提高。值得称赞致敬和学习
@billy1999 老D HOSTS 用的是HK TENCENT CLOUD. 现在被墙
hk-CN线路走GFW吧
否则HK Google也在Hong Kong被墙啊
TENCENT开始和GFW联动封SNI了啊，某些DNS也遭殃了
@lrinQVQ 不止SNI certificate证书那个包好像也是明文的 而且有域名
http://www.lsablog.com/protocol/https/https-analysis/
@lrinQVQ 看来，要趁TLSv1.3还没大规模启用之前，赶紧给OPENSSL等相关SSL项目组致函，要求在握手阶段不能泄露任何明文访问信息并且不能轻易被深度包检测技术DPI探针刺探出流量指纹来，方便GFW选择性阻断。
@Just2co 确实需要一个好的方法处理现在的状况
XD我去试试吧
@Just2co
首先，各个TLS/SSL库的项目组并不是TLS标准的编写者，你跟他们说没用，要跟写标准的人说。。
第二，不传输明文信息就目前的证书体系来说是不可能的。
@beyondgfw @lrinQVQ 可以跟谷歌公司的相关组织反映，毕竟谷歌这次损失最大，直接证书屏蔽，之前借助hosts以及GAE平台，还能让几十万**人用，现在整个彻底废了，只剩下QUIC技术过墙了，而QUIC特征特别明显，一旦用的人多了，早晚也会跟证书屏蔽一样，墙掉QUIC协议。
能解释下目前的证书体系必须要传输明文域名信息吗？
最终，翻墙还得靠混淆流量与去除特征才行。
@SY618 但是VPN本身就是用于混淆流量的吧
厉害了！！**的****技术已赶超欧美处于世界领先水平！！中华民族复兴崛起！！！祖国**！！！
@beyondgfw @lrinQVQ 网上能够找到的关于为什么SNI是明文的最好的回答（洋文）：
https://security.stackexchange.com/questions/86723/why-do-https-requests-include-the-host-name-in-clear-text
特别注意以下的这段：
While encrypting the hostname would be nice, the question would be which key to use for encryption. The key exchange comes only after identification of the site by certificate, because otherwise you might exchange keys with a man-in-the-middle. But identification with certificates already needs the hostname so that the server can offer the matching certificate. So the encryption of the hostname would need to be done with a key either based on some other kind of identification or in a way not safe against man-in-the-middle.
另外IETF在TLS 1.3的设计过程里已经开始研究如何加密SNI了，以下是IETF关于加密SNI的PowerPoint：
https://www.ietf.org/proceedings/interim/2014/07/20/tls/slides/slides-interim-2014-tls-2-6.pdf
还有一点就是除了SNI和证书之外，还有在DNS查询的环节也可以泄露访问目标网站名，当然使用HOSTS可以达到规避这种泄露的效果。
@lrinQVQ @beyondgfw 不客气，如果有任何好消息，还请再这里讨论
严重支持!!! TLS是要改了 否则不像话 不过看到有SNI+Tunnel 翻墙可以
http://www.ttlsa.com/linux/bind-stunnel-sni_proxy-secure-proxy/
Golden Shield 只是没这么厉害可以墙内sni 先coax GFW再说
openssl/openssl@5368bf0
也许有些有趣的事情会发生~
早猜到大多數普通VPN用默認port 都要GG....
坐等更新
2333顺便好像 ipv6(非教育网)也出现了和ipv4一样的封锁 仅个人
还是熟悉的味道
ipv6隧道已沦陷
@SY618 2333差不多 测试了下隧道也能全部SNI RST
//XD目前TLS 1.3 22草案我适配得差不多了 或许会先放出一个一年的SNI 233先说一下
@lrinQVQ 所以结论是什么？ tls1.3也没用？
@braindevices 2333为什么没用呢 只是需要1.3 21草案以上的版本而已啊
@daiaji 标准已经定下来 对于某些群体而言不加密当然更好 可能当初确实有把ipsec强制加上的草案 现在应该是在某些利益团体的强烈要求下砍掉了……
“不加密性能好 而且设备制造成本更低”
说什么都凉了
ipv6草案是有过强制ipsec，然而后来砍了，确实挺可惜的。。
哇XD +1
@beyondgfw 哇，社会是真的险恶
哎 反正都凉了
先去打几把RPG好了
@beyondgfw 强制ipsec的话 路由这边能知道你访问的是啥ip吗？
我已经几个月没用谷歌了
TLS1.3的sni加密只在0-RTT/TLS1.3会话恢复时生效(ietf写的很明白，第一次只能明文)
@railjty 绝望
這樣用Shadowsocks 就好了好.... 沒有希望... No darn hope at al 還有那個什麼下載packet retransmission 現在寫程式用65535 threads 暴力開 不花代理跑满频宽 shoot GFW the bird. QUIC 也不錯
@lrinQVQ 不知道你們最近有看到 HTTP 下載 會middle man attack 301 redirect 到GFW的proxy 嗎 e.g.
http://101.96.10.36/ Chinacache
Any solution without proxies?
@lrinQVQ 不知道你們最近有看到 HTTP 下載 會middle man attack 301 redirect 到GFW的proxy 嗎 e.g.
http://101.96.10.36/ Chinacache
那不是ISP日常劫持到自己的缓存服务器嘛
早就有了
解决办法要么换HTTPS
要么做个本地代理自己把第一个数据包扔掉
...IE8 on XP也许在Google全面放弃3DES/RSA前有用。。
Looking on ipv6...
https://www.wkii.org/ipv6-hosts-connect-google-services.html
加快TLS1.3建设吧。某组织堪比纳粹！！！
TLS1.3说好前半年部署呢
现在不还是前半年嘛（笑）
标准才刚刚通过 实现需要时间
备忘：bitbucket.org 进入 SNI 黑名单。
已解除。
最近几个小时开始，逼逼C、美帝知淫系、中文维基都有类似的方式干扰，curl显示的结果是： SSL_ERROR_SYSCALL，有点类似1楼的干扰方式。
ss现在也跪了
比较司马的一点是p站ban了我的idc