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

Open
lrinQVQ opened this Issue Oct 4, 2017 · 109 comments

Comments

@lrinQVQ
Contributor

lrinQVQ commented Oct 4, 2017

UpdateL2018.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

This comment has been minimized.

123ysys commented Oct 4, 2017

哇!为大神送水递毛巾。

@birdofprey

This comment has been minimized.

birdofprey commented Oct 4, 2017

嗯,这个好,让世界明白是咋回事!!

@beyondgfw beyondgfw added the meta label Oct 4, 2017

@lrinQVQ lrinQVQ changed the title from 一些测试 to 一些测试,猜测一完成,猜测二继续实验中 Oct 4, 2017

@sy618

This comment has been minimized.

sy618 commented Oct 5, 2017

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 5, 2017

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

@sy618

This comment has been minimized.

sy618 commented Oct 5, 2017

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 5, 2017

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

@sy618

This comment has been minimized.

sy618 commented Oct 5, 2017

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

@Sharkkkk

This comment has been minimized.

Sharkkkk commented Oct 6, 2017

@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

@sy618

This comment has been minimized.

sy618 commented Oct 6, 2017

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

@SerCom-KC

This comment has been minimized.

Contributor

SerCom-KC commented Oct 6, 2017

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

@Sharkkkk

This comment has been minimized.

Sharkkkk commented Oct 6, 2017

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

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 6, 2017

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

@Sharkkkk

This comment has been minimized.

Sharkkkk commented Oct 7, 2017

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 7, 2017

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

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 7, 2017

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

@lrinQVQ lrinQVQ changed the title from 一些测试,猜测一完成,猜测三可行,猜测二继续实验中 to 一些测试,猜测一完成,猜测三不推荐,猜测二继续实验中 Oct 7, 2017

@lrinQVQ lrinQVQ changed the title from 一些测试,猜测一完成,猜测三不推荐,猜测二继续实验中 to 一些测试,猜测一完成,猜测二继续实验中 Oct 7, 2017

@lrinQVQ lrinQVQ changed the title from 一些测试,猜测一完成,猜测二继续实验中 to 一些测试,猜测一完成,猜测三可行,但会被几分钟后ban掉对应端口,猜测二继续实验中 Oct 7, 2017

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

@123ysys

This comment has been minimized.

123ysys commented Oct 7, 2017

233333

@PantherJohn

This comment has been minimized.

PantherJohn commented Oct 8, 2017

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

@PantherJohn

This comment has been minimized.

PantherJohn 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

@PantherJohn

This comment has been minimized.

PantherJohn commented Oct 8, 2017

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

@billy1999

This comment has been minimized.

billy1999 commented Oct 8, 2017

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

xxxx

@PantherJohn

This comment has been minimized.

PantherJohn commented Oct 8, 2017

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

@daiaji

This comment has been minimized.

daiaji commented Feb 27, 2018

@railjty 绝望

@PantherJohn

This comment has been minimized.

PantherJohn commented Mar 1, 2018

這樣用Shadowsocks 就好了好.... 沒有希望... No darn hope at al 還有那個什麼下載packet retransmission 現在寫程式用65535 threads 暴力開 不花代理跑满频宽 shoot GFW the bird. QUIC 也不錯

@PantherJohn

This comment has been minimized.

PantherJohn commented Mar 1, 2018

@lrinQVQ 不知道你們最近有看到 HTTP 下載 會middle man attack 301 redirect 到GFW的proxy 嗎 e.g.
http://101.96.10.36/ Chinacache

@PantherJohn

This comment has been minimized.

PantherJohn commented Mar 1, 2018

Any solution without proxies?

@SerCom-KC

This comment has been minimized.

Contributor

SerCom-KC commented Mar 1, 2018

@lrinQVQ 不知道你們最近有看到 HTTP 下載 會middle man attack 301 redirect 到GFW的proxy 嗎 e.g.
http://101.96.10.36/ Chinacache

那不是ISP日常劫持到自己的缓存服务器嘛
早就有了
解决办法要么换HTTPS
要么做个本地代理自己把第一个数据包扔掉

@railjty

This comment has been minimized.

railjty commented Mar 1, 2018

...IE8 on XP也许在Google全面放弃3DES/RSA前有用。。

@PantherJohn

This comment has been minimized.

PantherJohn commented Mar 2, 2018

@birdofprey

This comment has been minimized.

birdofprey commented Mar 2, 2018

加快TLS1.3建设吧。某组织堪比纳粹!!!

@veteran233

This comment has been minimized.

veteran233 commented Mar 31, 2018

TLS1.3说好前半年部署呢

@SerCom-KC

This comment has been minimized.

Contributor

SerCom-KC commented Apr 7, 2018

现在不还是前半年嘛(笑)
标准才刚刚通过 实现需要时间

@SerCom-KC

This comment has been minimized.

Contributor

SerCom-KC commented Jun 22, 2018

备忘:bitbucket.org 进入 SNI 黑名单。
已解除。

@mraandtux

This comment has been minimized.

mraandtux commented Aug 24, 2018

最近几个小时开始,逼逼C、美帝知淫系、中文维基都有类似的方式干扰,curl显示的结果是: SSL_ERROR_SYSCALL,有点类似1楼的干扰方式。

@lrinQVQ lrinQVQ changed the title from 一些实验,完成编辑 to 一些实验,完成编辑(请仔细阅读说明和说明中给出的链接) Aug 26, 2018

@daiaji

This comment was marked as off-topic.

daiaji commented Oct 10, 2018

ss现在也跪了😂 我现在在用cf中转ws代理
比较司马的一点是p站ban了我的idc

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

@daiaji 公益ss:????

@daiaji

This comment was marked as off-topic.

daiaji commented Oct 10, 2018

@beyondgfw 自用SSR SS跪了几个了
没用的 已经识别了 现在是赌gfw敢不敢弄掉Cloudflare

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

@daiaji 嘛 你用公益ss被屏蔽在来说"识别"的问题

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

@daiaji 本项目公益ss已经提供了一年emm 没有出任何问题

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

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

@daiaji

This comment was marked as off-topic.

daiaji commented Oct 10, 2018

@beyondgfw ss ssr被gank又不是一两天了
本家那边哀鸿遍野也没人解决
你vps抗Ban那和ss有啥关系?
还是最近ss更新了?
那挺好
我继续用V2吧

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

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

@beyondgfw

This comment has been minimized.

Member

beyondgfw commented Oct 10, 2018

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

@lrinQVQ

This comment has been minimized.

Contributor

lrinQVQ commented Oct 16, 2018

非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

This comment has been minimized.

Contributor

lrinQVQ commented Oct 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment