2015年6月18日星期四

GAE Proxy可以使用GVS了

根据近来的消息,GoAgent的某些新版本已经支持使用GVS的IP了。
这自然是好事情。GFW把可用的Google IP已经封得差不多了,但GVS却基本没怎么动。如果GVS能用,就又多了一支生力军。(虽然还是会很快很容易地被干掉)

我去验证了一下,的确是可以了。当然,旧版GoAgent的代码需要做一些修改。主要是需要在客户端wrap_socket的时候把ciphers设成ECDHE-RSA-AES128-SHA。改动不止一处,但也不会很多,两三处、三四处吧。
另外一个好消息是,不只是GVS,还有别的一些原本不能用来做GAE Proxy的Google IP,也可以被这样用起来了。

尽管这些IP我估计都撑不到明年6月4日,但能用总比没有强。只可惜Google北京IP段不能用同样的方法来做GAE Proxy,否则那速度就爽了。
本文同样希望低调,就也不作推广了。看得到是缘分。看不到?看不到也就看不到了。

2015年6月9日星期二

荒野求生:把GGC转发搭建在非标准端口上

话先说在前面:这篇Blog,我没有,也不会去做任何的推广。能看到是缘分,尽量保持低调才能活得久一些。这不叫“自我审查”,这叫做对敌斗争策略
另外,本文只提供思路,不提供具体的操作方法(命令、脚本等)。想要知道的,可以自行搜索。也因此,本文可能不太适合技术小白。
好了,言归正传:

着GFW近日来将之前具备的GoogleSSL证书嗅探功能投入使用,hosts的生存周期日渐缩短。根据我自己监控下来的记录,新投入使用的hosts,大约最多只能存活不到两天。在自己的VPS上一旦开启了GGC转发,则48小时之内该IP必定会被黑洞路由掉。

从理论上,SSL证书嗅探可以在旁路上以异步方式排队进行,因此对GFW的性能方面压力并不大。以日为“结算”周期,集中地更新路由表,也可以避免频繁调整骨干路由设置导致的网络不稳。从各方面来说,hosts接下来都是在劫难逃了。

那么,真的没有办法了吗?hosts真的要“死”了吗?

※ ※ ※ ※ ※ ※ ※ ※ 低调的分割线 ※ ※ ※ ※ ※ ※ ※ ※

GFW这次的SSL证书嗅探,是针对443端口的。443端口,是HTTPS协议的标准端口。如果用hosts来翻墙,一定要与HTTPS配合,否则直接明文内容的话是通不过关键词审查的。所以,GFW这次盯住443端口,也是很有道理的。

那么,很自然地就想到,是不是避开了443端口,在别的端口上开启HTTPS服务,GFW就不进行嗅探了呢?这当然取决于GFW使用者,全端口嗅探当然也是可以做到的。不过目前还很幸运,答案是肯定的:GFW只检查443端口,其余的TCP端口被放过了。

接下来的问题就是:Google的服务器,控制权不在我们,如何让它把HTTPS服务开在非443端口上呢?去白宫请愿吗?

显然也不是。既然本文的标题叫做“荒野求生”,主要讲的就是“自己想办法”。Google的服务器我们控制不了,但GGC转发器我们可以自己架(在VPS上)。把端口转发开在非标准端口上,是我们完全可以做到的事情。

然而,另一个问题又来了。好了,我们现在有把HTTPS服务开在非标准端口上的Google服务器,但是,如何让我们的浏览器知道去这个非标准端口上访问HTTPS服务呢?

略有HTTP知识的,都知道在URL里面可以通过主机名后面加冒号来标注端口。我们当然可以这样写来访问这个非标准端口上的HTTPS服务:
https://www.google.com:12345
这样或许是能看到首页。但是,在使用Google服务的过程中,接下来会跳转到的那些URL地址,可能就不能如我们所愿了。另外,不管怎么说,这样用起来也太不自然了。有没有更好用的招数呢?

好吧,稍微想想,其实我们只要在本地再找一台机器,把这个端口转发再改回来,就可以了。像这样(懒得画图了):
浏览器 -> (:443)本地代理 -> (:12345)VPS -> Google服务器
本地再找一台机器,这会不会太麻烦了啊?
其实也不会。有翻墙路由器的朋友,看到这里大概就知道很简单了。没有翻墙路由器的呢?也很简单,在本地搭一个就好。Windows的话,用netsh在本地开一个端口转发,然后hosts指向loopback地址。这样就又可以用hosts了,GAE Proxy也可以用了,真好哎!

2015年6月4日星期四

按更新时间同步单个文件的简易方案

我曾经抱怨过,有个很简单的单个文件同步需求,却居然难以找到有软件能够解决。也许是需求太过于简单,反而没人去考虑。连Allway Sync这么好的东西,也做不到。于是一直都是人肉解决。

最近有点厌倦了每次Copy来Copy去的事情。而且中间也不是没有出过错。一出错就会丢一次的数据。索性简单地写了个bat批处理脚本来解决这种事情:
@echo off
xcopy D:\仓库\文件.txt .\ /D /Y >nul
xcopy .\文件.txt D:\仓库\ /D /Y >nul
运行这个bat脚本后,更新时间比较早的那个副本,会被另外一个覆盖掉。接下来只要每次编辑前或编辑后都记得运行一下这个脚本,就可以使两边文件版本一致,不需要再考虑复制方向对不对的问题了。

可能需要好多个VPS呢

目前打算在VPS上部署下列服务:
  • Shadowsocks:主要给PC和Android用。
  • GGC转发:给PC上的hosts和GoAgent用,比起Shadowsocks来还是快一点。
  • IPSec VPN:给iOS用。
从被GFW发现并封掉的风险来看,由高到低:
  • GGC转发:这个是最容易被检测到的。目前只能开在非标准端口上。开443的话不出一天必死。
  • IPSec VPN:特定端口和协议,也很容易检测。但因为商务上也有比较广泛的应用,被封的可能性比GGC转发还是要低很多。
  • Shadowsocks:如果协议没有漏洞的话,应该只能通过流量分析来检测到。
这样的话,我可能需要准备好几个VPS:
  1. 通用梯:能换IP(或方便加IP)的便宜VPS。三种服务都开。要是被封了就换IP,实在不行就弃。平时主要用这个,最好准备两台,用不同的VPS提供商。
  2. 移动设备专用梯:开Shadowsocks和IPSec VPN。需要在移动数据和WIFI上都能访问的VPS。延迟越低越好。因为手机上切换梯子不方便,所以这个梯子只需要一台就好。
  3. 救生梯:只开Shadowsocks,安装IPSec VPN但平时不启动。可以使用不方便换IP的VPS。平时尽量少用,只用于防止最坏情况出现时无梯可用。延迟只要不是太低都可以。只需要一台。
  4. 共享梯:三种服务都开。只在非本人电脑上临时使用。VPS越便宜越好。只需要一台。
这些梯子上,彼此间所有端口都不能重复,各种密码也都不能共用。

2015年6月3日星期三

匪军六三新动向Ⅱ

最近家里一团糟,工作也忙成狗,按理说今年写Blog的事情几乎要按下来了。但是随着一年一度的中国特色姨妈节的临近,大局域网里各种新情况层出不穷,不写点东西实在对不住自己,也怕清算菊花癌的时候忘记,所以还是来写点吧。

之前就在Google+上提到过,今年匪军吸取了去年的教训,花了大约一年的时间潜心收集各种Google的可用IP,在上个月的时候,就把这些可用IP封了个精光。并且匪军还开启了Google证书嗅探功能,所有HTTPS连接握手时的信息,都每天汇总到菊花残办。新发现的hosts,或者自行假设的GGC转发,存活期越来越短,基本不可能支撑到姨妈节。所幸也就只是这样而已,一阵腥风血雨之后,随着hosts/GAE Proxy的全面倒下,貌似平静了一段时间。

不过明天就是姨妈节了,在这个特殊的日子,我要很高兴地向大家汇报:菊花癌及其启明星姘头又推出了贴心的新套餐——云维稳。

这个云维稳,其实也不是新东西了,我以前在Google+上也层提到过。我发现自己找的Facebook的hosts,在家里能用,但是在单位用不了。抓包看下来,有台设备(TTL==128)在热情地替我Reset。进入非工作时段时,似乎就没这情况了。后来还发现googlevideo.com也享受这待遇,差点害我错判了形势。

这个设备的工作原理很简单:SSL证书过滤。注意是“过滤”,不是大局域网里的那种“嗅探”。你SSL需要握手吧?握手需要Server发Cert给你验证服务端身份吧?咔嚓

那么这个设备是什么呢?是这样的。只要你单位有通过ISP上网,某个“有关部门”就会找到你们单位的IT,要求你们单位购买并安装一个“上网行为管理系统”。这个系统里面呢,当然是会有一堆后门,专门给那个“有关部门”来用的。它们不光能看日志,还能随心所欲地让你来姨妈。

不过呢,今天的情况跟以前相比,又略有一些不同,简单地通报一下:

  1. Google主产品系列今天还没被封。
  2. Blogger眼下享受SSL证书过滤待遇。
  3. Youtube眼下享受SSL域名过滤待遇。

最后这一条我解释一下。“SSL证书过滤”这办法其实不是太高明。因为在某个时间段内证书只在第一次SSL连接时发一次,后面一般是可以跳过这一步的。所以只要用别的方式(VPN或Shadowsocks)拿一下证书,然后就可以hosts正常用了。而“SSL域名过滤”呢,是从你的Client Hello里面去拿Server Name(我只能说SSL太特么老实了)。这下没得跑了。预先拿到证书也没用,一看到关键字就给你咔嚓

话说回来,SSL用来翻墙的确很不合适。浑身上下都是漏洞,特别是在握手阶段,太多特征可以用来检测了。SSL本质上要求服务端身份得到严格确认,这样传输通道才是可信的。但翻墙在这一点上其实是完全相反的需求——服务端身份越模糊越好,最好谁都认不出来。看似矛盾,实际上分成两层来分别解决这两个需求,就没有问题了。不过这是后话,按下不提。

在最后,预祝各位姨妈节快乐,要记得给组织扎小人儿哦!