使用 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:5001 与 openssl 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/

拓展阅读

11518 次点击
所在节点    宽带症候群
45 条回复
Jirajine
2019-11-27 17:56:19 +08:00
@deorth 也不是多难的需求，就是添加一个 TXT 记录里面写上自己的公钥而已，这种不支持但你自己的域名肯定可以支持的，用 cloudflare 托管或者拿个小鸡自建 ns 权威服务器都行。
scukmh
2019-11-27 18:33:09 +08:00
@Jirajine 但是目前只有 Firefox 的开发者预览版支持？
allin1
2019-11-27 18:38:15 +08:00
@scukmh 我记得 70 就有了。etwork.security.esni.enabled
ZeroKong
2019-11-27 19:15:20 +08:00
话说你们有深圳的案例么。。。昨天我问了深圳电信 10000 号。
他们说他们允许这么做？？？这是为啥？？？我都被弄蒙了
ljy2345
2019-11-27 20:50:25 +08:00
我的宽带的用户就是电信公司他们查什么
https://imgur.com/iaFNrC3
https://imgur.com/p80UzwV
NSAgold
2019-11-28 02:04:31 +08:00
套 cdn，网页服务端口仅允许 cdn 回源。
justs0o
2019-11-28 08:05:03 +08:00
@NSAgold 也没用，回源的流量电信可以镜像分光进行 dpi
Chingim
2019-11-28 09:01:41 +08:00
firefox 支持 esni。再加上 doH doT 美滋滋。


我在公司就用，不想被网管统计。
brMu
2019-11-28 09:12:04 +08:00
我印象中 nginx 在配置 tls1.3 后，sni 不是强制加密的，意思就是看浏览器，如果浏览器支持 esni，那么整个过程就不会泄漏域名，如果浏览器不支持，那么 sni 还是明文发送的，而且目前好像只有 firefox 浏览器才支持 esni。

所以请教一下楼主：
你的这个是 server 端强制了必须走 esni 吗？
你用非 firefox 浏览器可以打开吗？比如 chrome，360 浏览器？
austinchou0126
2019-11-28 10:01:07 +08:00
@brMu 不是 ESNI 的解决方案
这个方案说的很清楚了，只是解决了端口扫描时被发现 HTTPS 以及域名泄露的可能性，无法解决 SNI 泄漏
brMu
2019-11-28 11:15:29 +08:00
@austinchou0126 那就是说如果运营商有监控设备，一旦有访问，还是可以监控到访问的域名是什么？
xunandotme
2019-11-28 16:54:07 +08:00
@Chingim https://thief.one/2019/07/09/1/
ericww
2019-11-28 19:14:06 +08:00
@ljy2345 查业务工单，查关联用户，查光口位置，想找到你有什么不能查的？
techon
2020-01-04 01:05:46 +08:00
真要涉及敏感问题，分分钟找你喝茶。一般家庭用户，完全看人家网警的心情，毕竟我们还是人治社会。。
brMu
2020-04-16 14:33:54 +08:00
如果运营商有监控设备，当你在外访问家里的设备时，家里设备会返回证书，此时又被监控设备抓取到了这个证书，不就知道你的证书信息了吗？证书信息里有域名，再尝试访问这个域名不就行了？
brMu
2020-04-16 14:42:57 +08:00
而已客户端也会发送 Client Hello 包，这个包里也会带有 sni 信息，也就是域名，监控设备同样可以抓取到。
binkcn
2020-04-26 11:28:52 +08:00
@brMu ESNI 了解一下，抓包实测 V2EX 已经启用 ESNI 了，无法在 Client Hello 里面看到 server_name 。

当然了，现在的关键问题是服务器虽然支持 ESNI，但是客户端浏览器默认仍然采用 SNI 直接发送明文 server_name 的话，还是会悲剧，譬如用 Chrome 访问 V2EX，或者 Firefox 不强制开启 ESNI 的情况下。

不过，这个解决起来并不难了，题主提到的 sniproxy 可以自己修改一下，强制检测 tls 版本必须要求 v1.3，并且 Client Hello 不能包含 server_name 即可。

过些天我有空的时候搞一下，有结果后我回再来回这个帖子并且 Share 解决方案。
brMu
2020-04-26 14:18:57 +08:00
@binkcn 解释的很清晰，明白了，非常感谢，等你的大招！
binkcn
2020-04-27 14:17:21 +08:00
@brMu 昨天部署好 sniproxy 之后仔细想了想，其实现阶段来说这样做意义并不大。

首先，假设按照预期在 NAS 上部署好 sniproxy+esni，并且实现我说的丢弃包含 server_name 的 tls 包，那么我想从外部访问这个 https，仍然需要浏览器支持，目前来说只有 Firefox 经过配置之后可以实现。

也就是说需要请求方支持（修改一些高级设置）才可以正常浏览，如果是这样的话还不如用传统的 VPN 回家或者 FRP 方案，毕竟我们选择 https 协议的意义就在于：“随时随地方便且安全的访问位于家里 NAS 上的 https 服务”，但是现在并不方便，门槛略高。

所以，只能等到主流浏览器在无需用户干预的情况下默认支持 tlsv1.3 & esni 时，这个方式才有意义。
brMu
2020-04-28 14:04:48 +08:00
@binkcn 老哥说的有理，那就再等等看，我现在也是用的通道先到家里再开别的。

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

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

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

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

© 2021 V2EX