简单说SS/SSR与GFW
个人理解,如有错误请告知.
Phase 1:
起初,我们对网络的访问时非常直接的,我们(客户端)向对方(服务端)发出请求,对方回应请求.
这tm没什么好讲的
Phase 2:
后来,在我party(和谐词注意)英明的指挥下,建立了GFW(Great FireWall),也就是伟大的中国国家防火墙.
据说就这货设计的.
下面花一点篇幅说几个GFW的封锁原理.
1.域名解析服务缓存污染
首先,GFW使用了返回错误的DNS查询结果的方式,比如,当长城监听它骨干出口上某端口的DNS查询(当然这是UDP),接着对其进行入侵检测,一旦发现了和黑名单上关键词相匹配的域名查询请求,就会马上开始当演员,返回一个虚假的结果,这样,我们就会遭遇连接重置，无法获得目标网站的IP地址。
然而..
2010年3月，当美国和智利的用户试图访问热门社交网站如facebook.com和youtube.com还有twitter.com等域名，他们的域名查询请求转交给中国控制的DNS根镜像服务器处理，由于这些网站在中国被封锁，结果用户收到了错误的DNS解析信息，此时长城的DNS污染已影响国际互联网。(因为多次污染国际互联网,北京的一台根域DNS还被关停了一段时间…)
还有..
2015年1月2日起，污染方式升级，不再是解析到固定的无效IP，而是随机地指向境外的有效IP(有毒啊)刚开始只是对YouTube视频域名（*.googlevideo.com）进行处理，之后逐渐扩大到大多数被污染的域名.这导致了境外服务器遭受来自中国的DDoS攻击，部分网站因此屏蔽中国IP
2.针对境外的IP地址封锁
防火长城的路由扩散技术中使用的静态路由其实是一条错误的路由，而且是有意配置错误的，其目的就是为了把本来是发往某个IP地址的数据包统统引导到一个“黑洞服务器”上，这个黑洞服务器上可以什么也不做，这样数据包就被无声无息地丢掉了,当然也可以进行一个虚假的回复.接着通过路由重分发,整个网络被打通,大家就都知道这样的IP要发向这么一个黑洞了,效率也得到了提升(封IP封的越来越开心了呢)
3.IP地址特定端口封锁
结合2,为了达到更精确的封锁,长城会对特定端口上的数据包进行全部丢弃,以达到更彻底的封锁.
常常封锁的端口:
| SSH TCP 22 HTTP 80 (PPTP)VPN TCP 1723 (L2TP)VPN UDP 1701 IPSec/L2TP UDP 500&4500 OpenVPN TCP/UDP 1194 TLS/SSL/HTTPS TCP 443 |
另外,中国X动,中国X通等ISP的手机IP端,所有的PPTP都被封锁.
4.对加密连接的干扰
(不太了解加密握手可以看看隔壁的TLS/SSL)
在连接握手时，因为服务器的公钥是明文传输的，长城会阻断特定证书的加密连接，方法和无状态TCP连接重置一样，都是先发现匹配的黑名单证书，之后通过伪装成对方向连接两端的计算机发送RST干扰两者间正常的TCP连接，进而打断与特定IP地址之间的TLS加密连接握手，或者干脆直接将握手的数据包丢弃导致握手失败，从而导致TLS连接失败.
5.深度包检测
深度数据包检测(Deep Package Inspection)是一种于应用层对网络上传递的数据进行侦测与处理的技术，DPI可对报文内容和协议特征进行检测。(似乎这个就是所谓的流量审查)
在中国大陆，DPI一度被ISP用于追踪用户行为以改善其广告推送业务的精准性，长城赖以检测关键词及嗅探加密流量的重要技术之一.基于必要的硬件设施、适宜的检测模型及相应的模式匹配算法，长城能够精确且快速地从实时网络环境中判别出有悖于预期标准的可疑流量，并对此及时作出相应地应对措施.
Phase 3:
针对一些封锁技术,勤劳智慧而又充满勇气的天朝人民,使用了境外HTTP服务器代理,SOCKS服务,VPN 等等各种方式来 Break the GFW.
然而,尽管SSH是安全的,长城并不能知道里面发生了什么样的数据交换,它却依旧能在建立隧道时,分析连接特征从而进行干扰或是重定向连接.
其他的几种方式,也都差不多.
Phase 4:
于是,出现了cloudwindy同学…带来的SS,没错,他被警察请去喝茶了.
延续Phase3,ShadowSocks实际上是将 SSH 创建的
SOCKS5协议 拆成两个部分,server 端和 client 端
不同的地方在于,客户端发出的请求基于 Socks5 协议跟 ss-local 端进行通讯，由于这个 ss-local 一般是本机或路由器或局域网的其他机器，不经过 GFW，所以解决了上面被 GFW 通过特征分析进行干扰的问题.
那么,就总体来说一下SS的运作流程:
首先,在服务器上配置好了 SS 服务器后,用户按照指定的密码、加密方式和端口使用 SS 客户端与其连接。在成功连接到服务器后，客户端会在用户的电脑上构建一个本地
Socks5 代理。浏览网络时，网络流量会被分到本地
socks5 代理，客户端将其加密之后发送到服务器，服务器以同样的加密方式将流量回传给客户端，以此实现代理上网。
Phase 5:
后来,在Party的调教下,似乎GFW对SS的流量有了某种辨识能力,于是,Github上一位叫BreakWa11的作者修改了原SS的代码,增加了混淆以及其他的一些功能(这里面有场不小的风波,从中可以学到一些开源协议的知识…感兴趣的去搜搜看),名为SSR.
其中使用的混淆机制有:
- http_simple
- tls_simple
- random_head
- tls1.0_session_auth
说说这其中比较好理解的
tls1.0_session_auth:模拟TLS1.0在客户端有session ID的情况下的握手连接。因为有session ID所以没有发送证书等复杂步骤，因而防火墙无法根据证书做判断(之前说过),同时自带一定的抗重放攻击的能力。
由于防火墙对TLS比较无能为力，抗封锁能力较强
random_head：开始通讯前发送一个几乎为随机的数据包,之后为原协议流。目标是让首个数据包根本不存在任何有效信息,使得GFW的统计学习机制失效.