使用 sniproxy 隐藏 SSL 握手时的域名,以躲过 ISP 嗅探

2019-11-27 14:36:04 +08:00
 austinchou0126

最近在论坛上有不少同学反馈,由于将家中 NAS 的服务暴露到了公网,其中包含了管理页面的 HTTP 或者 WebDAV,导致 ISP 发现并断网发文通知整改。其中有部分回帖称其没有使用 HTTPS 而导致流量被运营商嗅探到。但使用了 HTTPS 服务就万无一失吗?不是的。就算使用了 HTTPS,也有可能在 SSL 握手时域名遭到泄漏,导致运营商可以通过域名形式访问到用户开启的网页服务。

当然,运营商如何操作的,对于我们来说是一个黑盒,运营商可能通过抓包等方式获取请求中的明文的 SNI 信息。要确保万无一失,您还需要使用加密的 SNI。

需要注意的是,如果您的 ISP 未分配给您互联网上的地址,此篇教程不适用您的情况。请移步 frp 进行端口映射。


我们假设以下的这种情况:

某用户使用了群晖的 NAS,默认 5001 为 DSM 的 HTTPS 连接方式,默认的 5006 为 WebDAV 的 HTTPS 连接方式。而且某用户使用了群晖自带的 DDNS 服务,注册的域名为:customname.synology.me

用户在路由器上做好了端口映射的设置( 5001:5001,5006:5006 ),暴露给公网的端口,已经不包含 HTTP 明文传输的网页服务了。

某段时间,该个用户因为使用了 BT 等软件造成短时间的流量过大,导致进入运营商的关注列表。运营商使用了端口扫描的方式嗅探该用户的端口。

扫描下来,发现用户的路由器上开放了两个端口,5001 和 5006,且嗅探时返回可能为 HTTPS 协议。

运营商使用:openssl s_client -connect x.x.x.x:5001 嗅探 HTTPS 的握手信息:

…
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = customname.synology.me
…

运营商使用 https://customname.synology.me:5001 顺利打开 NAS 的管理页面,判定用户违规架设了 HTTP 类服务。一键三连。


在这个过程中,关键之处在于:运营商一定要掌握到你的域名地址信息,且能通过 IP + 端口或者域名 + 端口的组合形式访问到。例如 DSM 使用的 Web 服务器,默认只绑定了一个域名和一个证书,在 SSL 握手时服务器会主动发送该证书,导致域名的泄漏。所以我们要做的,就是始终不让运营商掌握到我们使用的域名(通过 HTTPS ),而且要保证,当运营商起疑心,通过技术手段扫描我们的端口时,不能使其访问成功(通过 sniproxy )。

通过 sniproxy ,我们可以做到:


下面直接给出设置的过程,以我自己的 DS918+ 为例,DS918+ 支持 Docker,我将使用 Docker 方式运行 sniproxy。如果您的 NAS 并未提供 Docker 支持,您也可以通过其他方式运行 sniproxy,例如树莓派等等。

  1. 在 DSM 的 Docker 中,搜索 Image:austinchou0126/sniproxy
  2. 下载 Image,创建一个 Container,创建时设置如下:Port Settings 中,删去容器端口为 80 的条目,手动设置一个未占用的端口,例如将 15001 映射至容器的 443 端口(请不要选择默认的 Auto,否则会由 Docker 自动分配一个端口)
  3. Environment 中,添加环境变量:SNIPROXY_LISTEN0_PROTO=tls、SNIPROXY_LISTEN0_PORT=443、SNIPROXY_LISTEN0_FALLBACK=127.0.0.1:4443 (这里选择任一一个无法访问的端口,以阻断不带域名的 HTTPS 请求)、SNIPROXY_TABLE0_SRC0=customname.synology.me (这里填入您的 DDNS 域名)、SNIPROXY_TABLE0_DEST0=x.x.x.x:5001 (这里填入您的 NAS IP 和 DSM 的端口),更多的环境变量请参考 README
  4. 创建并运行这个 Container,此时,您就拥有了一个端口为 15001 的 sniproxy 实例,将会把带有 customname.synology.me 域名访问的 HTTPS 请求转发给 x.x.x.x:5001
  5. 使用 openssl s_client 进行验证和测试:如果通过 IP + 端口访问,将不返回任何一个证书;如果通过域名 + 端口访问,将返回一个正确的证书信息。测试方式:(openssl s_client -connect x.x.x.x:5001openssl s_client -connect x.x.x.x:5001 -servername customname.synology.me
  6. 配置您的路由器的端口映射,将原本直接映射至 NAS 的端口经由 sniproxy 进行转发
  7. 对于其他的 HTTPS 服务(例如 WebDAV ),执行同样的步骤

配置后流量:Router[:5001] <-—> Docker on NAS[:15001] <-—> NAS[:5001]

相比于使用 VPN 或者内网穿透这两种方式,使用 sniproxy 有以下的优点:


最后,我建议大家,如果您继续选择将服务暴露给在互联网上,请做好以下的防范措施:


如果您觉得这篇文章对您有帮助,欢迎在 GitHub 上给我的这个 项目 点个 Star,并且分享给有需要的人。

原文地址: https://blog.evianzhow.com/hide-your-domain-using-sniproxy/

拓展阅读

12055 次点击
所在节点    宽带症候群
45 条回复
ZRS
2019-11-27 14:45:51 +08:00
如果运营商都做到这份上了,对家宽的入站 TLS 请求做 SNI 嗅谈也是很容易的
austinchou0126
2019-11-27 14:52:26 +08:00
@ZRS 手动狗头保命。
那我这么想,那我用假的 TLS 请求给大量的 IP 群发,制造 flooding 是不是也可以误伤好多人?除非运营商再针对 TLS 的状态做一次筛选
justs0o
2019-11-27 14:54:06 +08:00
都说过多少次了,运营商通过分光镜像,7 层 DPI。不使用类似 VPN 这种无解
直接给你们运营商用的设备
https://i.loli.net/2019/11/27/7kICs3uWPaJLbK9.jpg
justs0o
2019-11-27 14:55:36 +08:00
系统串接或并接于 IP 骨干网上,提供 10G、40G POS 接口,从网络第三层到第七层对每一个 IP 包进行解析
ZRS
2019-11-27 14:58:53 +08:00
@austinchou0126 嗅探拿到域名之后连一次就能判断了,你文章里折腾这么一圈还不如上个不存在域名的自签证书…
austinchou0126
2019-11-27 14:59:22 +08:00
@justs0o 我相信可以。
不是杠,那要是有这样设备,被罚的话岂不是一大片人,既然有这么精准的设备,一抓一个准啊。
filter valid tls -> check sni -> 测试一下 -> 告知书
目前看到的暂时是个例现象
justs0o
2019-11-27 15:00:49 +08:00
@austinchou0126 该设备就在上海电信的城域网骨干上,某位大佬说误封概率很低。
3dwelcome
2019-11-27 15:01:07 +08:00
@austinchou0126 运营商现在监控技术今非昔比,我看到过后台的记录的访问详细记录,想封真是随时封掉。
什么时候访问 HTTPS 能完全不暴露 SNI 就好了。
austinchou0126
2019-11-27 15:02:19 +08:00
@ZRS 你上了一个自签的证书,SSL 握手里是没有域名信息了。然后呢?网警当着你的面,Chrome 里忽略不安全的证书继续访问,不一样可以访问到么?
我这个方法,可以避免嗅探。当然我前面也说了,运营商通过抓包获取到的 SNI,不在讨论的范围内。
austinchou0126
2019-11-27 15:02:43 +08:00
@3dwelcome ESNI 离我们还太远了
justs0o
2019-11-27 15:03:15 +08:00
@austinchou0126 不是网警,是不良信息处理中心,每天都在搞这个
austinchou0126
2019-11-27 15:04:27 +08:00
@ZRS @justs0o
我不否认各位说的,通过 VPN 方式连回去使用,这样确实是目前最安全最没有后顾之忧的选择。但也意味着,要在移动设备上访问内网服务的话,都必须先开一个 VPN,有些设备没法配置 VPN,例如小米电视。
justs0o
2019-11-27 15:05:55 +08:00
@austinchou0126 只有 VPN,不然过不了 dpi,以前只管政企,现在民用也管
ZRS
2019-11-27 15:06:11 +08:00
@austinchou0126 你给的完全是错误的方案啊…为猜想出来的运营商手段给了一个奇怪的错误对应方式。出发点就有问题…
carlist
2019-11-27 15:39:07 +08:00
下载量大的时候被嗅探搞挂刷了午餐肉固件的网件路由又不是一次两次了,只能第二天早上重启路由
但是墙梯直接被联通 ban 了只能电信,双线负载均衡都不好用的说
Jirajine
2019-11-27 15:48:00 +08:00
ESNI 真的还很远吗?也许各大主流网站支持的会很慢,但自己部署的话,一些实验性的 patch ( https://github.com/cloudflare/tls-tris/pull/172 )加上 Firefox nightly,已经可以尝试使用了。
alphatoad
2019-11-27 16:04:43 +08:00
这个问题没有运营商内鬼谁也不知道他们到底是怎么搞的
Worst case dns 指向家宽就搞你
sni……我不觉得是问题,只要公网能访问就有足够的理由搞你
deorth
2019-11-27 17:33:27 +08:00
了解了一下 ESNI,结果需要 dns 服务商支持。像是群晖或者我用的 tplink 自带的 ddns 不太可能支持这种东西
cnyang
2019-11-27 17:34:20 +08:00
tls1.3 不久干这事的吗,没必要造轮子吧
cwbsw
2019-11-27 17:38:31 +08:00
@austinchou0126
小米电视是啥意思? VPN Server 架在任意设备上都可以啊。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/623594

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX