5e2t
5e2t
当然，我其实 最想强调的还是，河南GFW检测TCP流量的方式 ， 跟对待UDP流量似的，以每个数据包为单位，对每个包 读取应用层前十几个字节 来确认是不是TLS的clienthello，兴许代码里压根没有检测syn的行为。 北上广出口GFW检测TCP流量的方式 才真正的像对待TCP流量，以每条连接为单位。 与此同时有个细节，众所周知workers.dev域名被北上广出口GFW给SNI阻断了，但是阻断的只是TLS，没有阻断对此域名的HTTP请求 由于河南GFW部署了对HTTP的HOST的检测，恰巧workers.dev域名也在河南GFW的黑名单里，所以河南部署域名黑名单墙以后，连对workers.dev的HTTP连接也被RST阻断。 而我们都知道HTTP是持久连接的，同一条连接上可以进行多次的HTTP GET/POST之类的请求，也正是河南GFW的这种 无状态检测，可以有效阻断明文HTTP连接。。（不过话说回来同一条TCP连接上进行的多次HTTP请求难道还能换HOST的吗.........暂且认为可以吧~~~） 北上广出口GFW对待HTTP流量的历史就源远流长了~具体细节我也不知道。 如果只讨论河南GFW的话，此GFW在读取一个包的前十几个字节之前，也不知道这个包到底是TLS的clienthello握手还是HTTP GET/POST 之类的请求，如果是在一条连接已经通信了很久的情况下，发送了一个新的HTTP GET/POST请求当然是非常合理的， 当然如果一条TLS连接已经通信了很久，又在此连接上发送了一个新的明文clienthello握手包， 看起来河南GFW是可以阻断这个 已经通信了很久的连接 上的 新发送的明文clienthello握手包的.......... （毕竟原来的目的是为了阻断“一个通信了很久的连接” 上 《新的HTTP GET/POST请求》，能阻断“已经通信了很久的连接“ 上的 《新发送的明文clienthello握手包》是 额外的效果.....）...
@RPRX 所以有没有可能是因为 河南GFW的检测算法，不是专门针对检测TLS流量设计的，而是针对检测HTTP流量设计的，所以才造成了，河南GFW可以阻断 servername位于第一个clienthello分片的TLS握手包。 如果他真想好好的检测TLS握手包，兴许就会像国际出口GFW那样，如果不读到一个完整的clienthello包，就不判断为是TLS 的clienthello握手了。 从应用层第一个字节开始，一个字节一个字节的读真的很像 HTTP服务器的行为呀~~~ *So is it possible that the Henan GFW's detection algorithm is not specifically designed for detecting TLS traffic, but for detecting HTTP...
河南GFW有个特点是对于黑名单里的所有域名一律阻断HTTP HOST和TLS SNI，这一点跟国际出口GFW的行为是很不一样的。国际出口GFW对HTTP HOST的阻断跟TLS SNI像是两个系统。 *One feature of Henan GFW is to block HTTP HOST and TLS SNI for all domain names in the blacklist, which is very different from...
河南GFW阻断HTTP HOST用的RST包跟阻断TLS SNI用的RST包应当是没有任何区别的。 *There should be no difference between the RST packet used by Henan GFW to block HTTP HOST and the RST packet used to block TLS SNI.*
 My location is Henan , but the RST I received is not from Henan GFW's censorship equipment. It's from ShangHai exit GFW's censorship equipment. because the...
when I curl -v http://1.1.1.1 I received this in 30ms after HTTP GET sent. HTTP/1.1 301 Moved Permanently Location: http://106.74.25.198/ Cache-Control: no-cache Content-Type: text/html Content-Length: 0 
content of http://106.74.25.198/ 
@RPRX root@host:~# curl -v https://1.1.1.1 * Trying 1.1.1.1:443... * Connected to 1.1.1.1 (1.1.1.1) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile:...
@RPRX The traffic between me and 1.1.1.1 is through Shanghai exit GFW, I get RST in 30ms, the delay between me and Shanghai exit GFW is also 30ms.
@RPRX 我去年11月买的一台德国9929线路机器，用ShadowTLS就会被SNI阻断，具体表现是，不进行TLS握手时 ping值稳定150，一进行TLS握手（shadowTLS的）就直接两分钟ping不通。用的域名是www.bing.com ，但可惜的是我没进行更多测试就关机不管了。毕竟这显然是IP被GFW列为黑名单了才会被这样对待。。。