A socks5 proxy through SSL。
整理了一下自己写过的可以公开的代(po)码(lan)，都放到git上来了。
在13年10月份，wallproxy突然看不了U2B了（具体原因未知据说是GAE限制），Google IP也大量被封，感觉一直用这个翻墙方式不是事儿啊 就开始寻觅新的梯子，找到了SS，当时是1.4版的。读了SS的代码，感觉加密和混淆上有缺陷，so就有了我这个东西。main函数和SS 1.4版还是很一样的。
功能
和当时1.4版的SS差不多，区别有3点： 1、使用SSL连接替代SS的加密模块。这么做的想法是：SS不能防重放、防篡改等，加密这块最好别自己造轮子。 2、固定工作在443端口，当收到的TCP流头20个字节不是约定好的密码，就将这个连接作为https处理，否则作为代理处理。这么做的想法是：SS当时的建议是将SS服务端开在995等已知端口上，但是GFW会主动探测开放的端口具体运行的什么服务的，所以这样等于坦白给GFW说“我是代理哦”的感觉。固定在443并验证链接，这样收到墙的探测链接就返回正常的HTTP相应。 3、多了一个通过短链接转发TCP端口的z_tcptrans.py：z_tcptrans本地打开一个端口做服务器，当有链接来时，将数据通过多个短链接转发到服务器，服务器再转到指定的IP:端口上，并定时断开重建这些短链接。这么做的想法是：SS的流量特征就是SS里面承载的数据流的特征，虽然用SS了，但是通过流量分析还是能知道你里面跑的具体什么数据类型。
实际效果
13年11月开始用到14年底，不知道怎么回事VPS Control Panel被别人登录，估计证书也被泄漏，忙毕设懒得再折腾，停止使用，有1年时间。 缺点很明显，建立连接开销大，但是传输速度和SS没区别。 由于是在SSL里面承载socks5，并且几乎都是用代理浏览网页，流量特征和正常https服务器无异，这一年期间没有出现过断流、IP速度劣化、被封端口\IP等。 我把VPS的ssh设置为监听127.0.0.1 ，然后通过z_tcptrans在本地开一个端口转到服务器22上去连SSH，想法是流量分散到一堆只持续1分钟左右的短链接上，流量特征应该就不好看出来是SSH了。 通过日志发现每15分钟左右，GFW会在新建SSL时暂时阻塞，伪造一个随机的大陆IP对443端口发 http get 探测一次，然后放行。 还有一个更大的缺点：只有python版，不像SS那样有完善的各种平台版本的客户端。
后期计划
发现自己越来越懒了，这个东西从13年11月底开始就基本没变动过，除了14年2月把暴雪验证器放进HTTP里面，方便给工会人用我wow账号。 VPS Control Panel被黑后曾经想学SS也做成异步构架，没坚持下来，只把eventloop框框写好，就扔那里了。 判断头20字节那块也有缺陷，要改。changlog里面记录一堆todo，也没做。。。。。 说不定那天心血来潮，会继续这个东西，因为现在SS太容易短流了，基本上30分钟就要换个VPS才能继续用要不没速度，整天在自己3台廉价VPS切来切去的。
from https://github.com/warriorpaw/z-ssl-proxy
