Skip to content

Instantly share code, notes, and snippets.

@clowwindy clowwindy/ssl.md
Last active Jun 15, 2019

Embed
What would you like to do?
为什么不应该用 SSL 翻墙

SSL 设计目标:

  1. 防内容篡改
  2. 防冒充服务器身份
  3. 加密通信内容

而翻墙的目标:

  1. 不被检测出客户端在访问什么网站
  2. 不被检测出服务器在提供翻墙服务

SSL 和这个目标还是有一些出入。其中最大的问题是,2. 防冒充服务器身份 这个功能多余了。他会导致墙嗅探出证书信息,继而墙会知道服务器身份。如果墙知道一个服务器身份是用来翻墙的,它要做的仅仅是封掉使用这个证书的所有 IP。

墙看见的 SSL 握手响应头部如下:

QMQڑ????β????!AFf?a?1??[?
? G
0???R???̙G!GfX-??5?k ??Q?
u
q
0??1 *?H?? n?0?|0?d?"?7??^??eĵ??F0
0 UUS10U
VeriSign, Inc.10U
VeriSign Trust Network1;09U
140510235959Z0?10 2Terms of use at https://www.verisign.com/rpa (c)061402U+VeriSign Class 3 Extended Validation SSL CA0
+?7<US10
+?7Delaware10Private Organization10U43374461
0 UUS10
U9410710U
San Francisco1!0U 795 Folsom St, Suite 60010U
Twitter, Inc.10U
Twitter Security10U
?0? *?H?? twitter.com0?"0
???w?…?tSmZ ?T#7Tn,?l\C????
??^d?L?*q? ???\n*???*?X?[?????-?b?V?Ic[[ݙn??D??i;?j~,亵Ȯu?z۴Jz9qr??כ????G?#???u2j?7_;?3[Y?&?P???P?@?U?N?,?Tx?e?N???SVߝ???*!Po???Q???!??sIpҒ#`H??U'?"^?*?7
_?>???Z|`W?.p_??????p????v2?p????0?0'U 0?www.twitter.com?
twitter.com0 U00U?x?Fy?n?]@H?G???(?1?0
U?0BU;0907?5?3?1http://EVSecure-crl.verisign.com/EVSecure2006.crl0DU =0;09
`?H??E0*+https://www.verisign.com/rpa0U%+0U#0???P???%Z{U?O?c??XkC0+p0n0+0?!http://EVSecure-ocsp.verisign.com0+0?1http://EVSecure-aia.verisign.com/EVSecure2006.cer0+
b0`?^?\0Z0X0V image/gif0!00+Kk?(?
? ??*?H??K?!0&$http://logo.verisign.com/vslogo1.gif0
??Z
GD?𥛄8ݫ?NJnJXn?????]?? -";J?#O????
<r?Q&?.??;? F
?????K??Fq?mD?-?Sl??=3???]?.??=v?I???
???ѱ??)i?Y!K?L???GC??rI0IR??f!~
b4˼??]?b?????_5a=?-B¹ax???rif߰?j?[??j?????3???d?Ўo
kS
?m'?9????X?H???`ln?n%???ߍ5G?H?!w?+x:
?u?86K?[,!?z?ipŵh?4uf????/N? Dt?'\??d+A???]?? ??gqP???V{?0c?1??mKǫ??o;
@DrayChou

This comment has been minimized.

Copy link

commented Jul 8, 2013

唔,但是没有证书的话,通信内容不是很容易被墙知道吗?

@sundaymouse

This comment has been minimized.

Copy link

commented Jul 8, 2013

如果只是用来当https代理的话倒没啥,因为只要域名是个GFW没见过的,就不容易引起怀疑。改host+SSL翻墙,那就暴露了。

@est

This comment has been minimized.

Copy link

commented Jan 21, 2014

今天才看到这个帖子。LZ考虑过client cert木有呢?

@setekhid

This comment has been minimized.

Copy link

commented Mar 19, 2014

其实要过墙对加密方式并没有太多要求,openvpn、ssh、ssl只是用来作安全通信的,而过墙需要的是shadowy,security完全是另一回事。只是碰巧ssl可以解决一点点shadowy。现在gfw变聪明了,我们需要的是专业的过墙协议

@evefreedoming

This comment has been minimized.

Copy link

commented Feb 5, 2015

关于对抗 GFW 的特征检测
不论是 Shadowsocks 还是 VPN 或 SSH 隧道,共性都很明显——长时间的 TCP 长连接。
这样一种特征,非常明显是被用来翻墙。

或许可以考虑换一种思路:
用普通的,明文的 HTTP 请求来承载上层的翻墙数据。

以 SOCKS 代理为例:
把 SOCKS 代理切割成两个部分,一部分部署在客户端,一部分部署在 VPS。
两者之间的通讯,伪装成普通的,明文的 HTTP 流量。
(表面上看,像是明文的,但是承载的数据,依然用加密方式,比如打包成图片的内容)

这时候,SOCKS代理的客户端部分,对本地开启SOCKS 监听端口,然后把数据包装成 HTTP 发送到 VPS 的服务端。VPS 的部分再解包,重新转化为原始的 SOCKS 流量发送到最终目的 IP

对本地的网络软件而言,看到的依然是普通的 SOCKS 代理,因此浏览器或 IM 可以无缝兼容。

这样的流量特征,就非常类似于平时访问网站的流量特征。可以避免被 GFW 察觉。
如果伪装得好,即使是 Ghost Assassin 在 7单元 提到的“人工审核”,也可以骗过。

转载自:http://program-think.blogspot.com/2015/02/Princelings.html?comment=1423062885928

@Sunybyjava

This comment has been minimized.

Copy link

commented Feb 27, 2016

看不懂这样的技术文章耶

@hong139327

This comment has been minimized.

Copy link

commented Aug 6, 2016

占楼

@mzdblsw8

This comment has been minimized.

Copy link

commented Dec 6, 2016

用了这个软件。来支持一下。

@ArtmmIsTheBest

This comment has been minimized.

Copy link

commented Feb 10, 2017

虽然不太懂,但是就是想来支持一下,

@ls0f

This comment has been minimized.

Copy link

commented Apr 7, 2017

@evefreedoming 我就实现了这么一个proxy:)

@Etz-haChayim

This comment has been minimized.

Copy link

commented Jul 21, 2017

@lovedboy 能否介绍下详情?感谢

@nanqinlang

This comment has been minimized.

Copy link

commented Jul 28, 2017

同意。

@cyyself

This comment has been minimized.

Copy link

commented Jul 28, 2017

SSL是使用RSA来进行密钥交换的,说白了就是客户端生成一个动态的加密密钥匙用服务器的Pubkey加密发给服务器,服务器用Private Key解密得到这个加密密钥,在密钥交换过程中会暴露服务器证书,特别是域名/IP。
不了解RSA加密原理的可以看一下我的这篇文章:
https://cyyself.name/2017/07/rsa-algorithm/
对于SS服务器来说,采用预共享密钥的加密方式免去了RSA密钥交换环节,抓不到任何有明显特征的握手包,减少了特征。

至于SSL识别对于GFW有多容易,参考OpenVPN。

@kuyur

This comment has been minimized.

Copy link

commented Sep 5, 2017

如果客户端预存服务器的证书(公钥),跳过通过网络获取服务器证书这一步,是否可以减少大量的握手特征?

用于翻墙的https代理服务器,其实不需要CA,一个自签署的证书就足够了,而且公钥可以根本不公开。

当然这改造版的https协议不再是一个标准的https协议,实现起来不能用现有的各种包。

@kimomoki

This comment has been minimized.

Copy link

commented Oct 10, 2017

完全看不懂,举脚支持

@lersh

This comment has been minimized.

Copy link

commented Oct 27, 2017

如果自己签署一个阿里,苹果,微软,腾讯这样大公司的证书呢,O,T,CN这些都完全模仿已有的证书, 是否可以伪装成链接的是合法的网站呢。至于承载的内容,墙肯定是无法得知的。

@ghost

This comment has been minimized.

Copy link

commented Dec 17, 2017

TLS 1.3 大概可以解决这个问题了吧 🤔

@jisuwugui

This comment has been minimized.

Copy link

commented Mar 12, 2019

Firewalls 仅通过证书判断某台 HTTPS 服务器的身份是困难的,对于非公开、非商业运营的使用场景,不失为一种方案。

@yufish

This comment has been minimized.

Copy link

commented Mar 22, 2019

关于对抗 GFW 的特征检测
不论是 Shadowsocks 还是 VPN 或 SSH 隧道,共性都很明显——长时间的 TCP 长连接。
这样一种特征,非常明显是被用来翻墙。

或许可以考虑换一种思路:
用普通的,明文的 HTTP 请求来承载上层的翻墙数据。

以 SOCKS 代理为例:
把 SOCKS 代理切割成两个部分,一部分部署在客户端,一部分部署在 VPS。
两者之间的通讯,伪装成普通的,明文的 HTTP 流量。
(表面上看,像是明文的,但是承载的数据,依然用加密方式,比如打包成图片的内容)

这时候,SOCKS代理的客户端部分,对本地开启SOCKS 监听端口,然后把数据包装成 HTTP 发送到 VPS 的服务端。VPS 的部分再解包,重新转化为原始的 SOCKS 流量发送到最终目的 IP

对本地的网络软件而言,看到的依然是普通的 SOCKS 代理,因此浏览器或 IM 可以无缝兼容。

这样的流量特征,就非常类似于平时访问网站的流量特征。可以避免被 GFW 察觉。
如果伪装得好,即使是 Ghost Assassin 在 7单元 提到的“人工审核”,也可以骗过。

转载自:http://program-think.blogspot.com/2015/02/Princelings.html?comment=1423062885928

底层改为伪造的明文图片类http连接而不是长连接,会不会大幅度降低传输效率?

@forever8938

This comment has been minimized.

Copy link

commented Apr 7, 2019

直接连ip不也得暴露服务器,除非用cdn

@selay01

This comment has been minimized.

Copy link

commented May 6, 2019

@forever8938 直连暴露ip,走cdn暴露sni,tls 1.3之前暴露证书内容
暴露出去的信息都能成为检测要素:
ip、sni不知名却有大流量, 证书与知名证书不同或不常见却有大流量、数据特征与常见协议不符
使用什么方法只是成本和收益的问题,阻断并不是很难

不知 encrypted-sni + tls 1.3 普及后,能否实现 不漏痕迹的依附的自由?

也许,在极端情况下,只有 依附的自由 这一条路可走,但最后的选择,也是最耐得住考验的选择。

@jmxct520

This comment has been minimized.

Copy link

commented May 16, 2019

Finally, may the Force be with you

@jmxct520

This comment has been minimized.

Copy link

commented May 16, 2019

不知该说什么,GFW已经对TLS系列具备攻击能力了

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.