花了若干小时看完了Telex的论文,简单来说,利用了TLS握手协议最开始客户端发出的随机串。可以用类似Diffie- Hellman的方法构造出某些特定的随机串(称为tag)及其对应的key:$k_{sh}$,使之满足两个条件:

  1. 有私钥的人可以迅速识别出tag,并根据tag算出key:$k_{sh}$

  2. 没有私钥的人无法有效地区分tag和真正的随机串

私钥当然是掌握在Telex的提供者手里(以下认为Telex station有私钥)。

整个通讯过程的背景是,client要访问一个被Q的网站Blocked.com,另外有一个没有被Q的网站NonBlocked.com作为靶子,而Telex station作为路由器的旁路设备架设在client和NonBlocked.com之间。当然,除了client之外的三个东西都是在Q外的。

client不能直接访问Blocked.com,因为这样Q就发现了。于是client用HTTPS访问了NonBlocked.com,只不过在TLS协议cli ent最开始发送的随机串那里用了一个tag而不是真正的随机串。当这个包到达Telex station时,Telex station用私钥识别成功,开始监听这 个连接。TLS握手进行到交换密钥这一步时,client故意造了一个漏洞,在应该用真随机串的地方用了根据$k_{sh}$生成的伪随机串。对于不知道$k_{sh }$是什么的人来说无法发现差别,但Telex station知道$k_{sh}$,所以相当于client把密钥交换算法中自己的私密部分告诉了Telex station。于是Telex station就可以像client一样算出双方在后续通讯中使用的主密钥(master secret)了(注意NonBlocked.com发来的公开信息Telex station也能看到)。

最精彩的地方在于,当client和NonBlocked.com的TLS握手即将进行完毕,NonBlocked.com发来最后一个Finished消息时,Te lex station用一个RST蹬掉了NonBlocked.com,自己摇身一变成了Man-In-The-Middle。(RST终于在好人手里创造价值了… …内牛……)在把这个Finished消息forward给client之后整个TLS握手就完毕了,而通信的双方实际上已经由client和NonBlocked. com变成了client和Telex station。一个加密信道建立起来了,Telex station只需要像个代理一样负责转发就可以了。比如client在这个连接上的下一个请求就可以是到Blocked.com的了。

Telex强大的地方在于它是部署在从client到NonBlocked.com(注意不需要是Blocked.com)的中间节点上的,即作者所说的end- to-middle,client是end,Telex是middle。整个通讯在client这边看起来都是在和NonBlocked.com进行的,Telex station的IP并没有暴露,所以也就无法用封IP的方法消灭。client想要Telex的帮忙,只需要建立一个HTTPS连接途经Telex即可。可以想象如 果能在骨干网大规模部署Telex或者干脆部署在国家入口,命中率还是很高的。

不过Telex还是存在一些问题(除去论文中已经指出的)。既然client和NonBlocked.com之间的通讯密钥被三方(client/NonBlocke d.com/Telex station)知道了,那么:

  1. client和NonBlocked.com的通讯都被Telex station看到了。这就意味着client和NonBlocked.com之间的通讯是不安全的。所以不要把NonBlocked.com指定为很重要的网站。

  2. 理论上NonBlocked.com可以破译client和Telex station的通讯。所以这条信道并不是真正的安全,只是能凸Q罢了。如果在client和Telex station之间的通讯需要加密,应当在加密信道建立之后立即重新协商密钥。

总的来说整个过程很有趣。苦逼的client给无辜的靶子发求救信号,只为中间被Telex截获。Telex忍啊忍等到两边的TLS通道建立起来了,一脚蹬掉靶子开始 为client服务。可怜的靶子,辛辛苦苦和别人握了手,还没热乎,就被一个RST蹬掉了。没办法,谁让靶子身份好。

附TLS握手协议图一张,这个是双向认证的,凑合看吧。

SSL.png

Links: