再谈家庭宽带架设 HTTPS 防嗅探。

[binkcn]

先说目标：

      我的目标是在公网任意位置（公司、移动网络、手机 APP 等）通过 HTTPS 协议可以访问到位于家中 NAS 上提供的 HTTPS 协议服务，譬如 Seafile （实际上 Seafile PC 客户端和手机客户端在 auth 认证阶段也是走 HTTPS 协议的），但是又不会被探测到，或者说即便探测到了，也无法在第三方进行复现，从而避开监管不给 G0v 添麻烦。

目前的已有方案：

     由于 `HTTPS` 协议中客户端发送的 `SNI`  会泄漏 `server_name`，可能会被 ISP 嗅探到，然后 `ESNI `也迟迟没有实装，再者即便实装了，大量客户端（譬如手机 App 、浏览器等）在没有得到 `DoH` 等安全 `DNS` 支持的情况下，大概率还是会直接发送 `server_name` 从而导致域名被泄漏，所以等 tls v1.3 esni 不现实。

     然后我在测试机上部署且体验了 SNIProxy，也不是绝对满足需求，毕竟这玩意儿只能防止直连端口证书泄漏域名，但是正常访问握手时 client hello 发送 server_name 的问题还是没有解决。

     至于 Frp 、SSH 、VPN 隧道等方案也不完美，不具备 **从任意设备，任意公网访问** 这个先决条件。

我的想法：

     想了一个折中办法，实现上比较麻烦，也有一些小瑕疵，先抛砖引玉聊一聊？也或者如果有现成的类似的玩意儿也可以直接发给我玩玩？

     首先，我们需要一个中间服务器，负责在上面跑一些自己写的脚本，但是这个服务器只作为一个类似前期握手的存在，并不参与具体的流量转发。所以一般来说服务器用最便宜的 VPS 即可，要求具有 IPv4 公网 IP 和低延迟+稳定，对硬件性能无要求。

    然后，家里的 NAS 也需要进行一些调整，同样跑一个脚本执行一些额外操作。

    最后，具体的实现是这样：

1. 正常解析域名 seafile.yourdomain.com 的 A 记录到 VPS 上，客户端正常请求 https://seafile.yourdomain.com
2. VPS 上的脚本监听且收到请求后，先挂起请求，然后通过任意加密方式（比如加密的 SSH 隧道）连接家中的 NAS，并且将本次请求中的客户端公网 IP 发送到 NAS 的脚本上
3. NAS 的脚本接收到这个公网 IP 后通过 iptables 操作防火墙允许这个 IP 从公网访问 NAS 的 https 服务，并且标记这个 ip，设定一个定时器在 N 秒后移除这条白名单规则，这个参数 N 可配置，一般默认 30-60 秒这样。
4. NAS 通知 VPS 已设置好白名单，以及过期时间 N，VPS 上标记该域名白名单状态和过期时间。这样在过期时间内该域名的后续请求不再挂起而是直接放行，参见下一步操作。
5. VPS 不再挂起 https 请求，返回 302 状态，重定向该请求到另外一个域名 seafile.fakedomain.com 。这个新的域名是直接解析到家庭宽带的公网 IP 的。
6. 客户端收到 302 状态后跟随跳转重新请求到 seafile.fakedomain.com （即 NAS ）上，由于白名单的存在，通讯正常处理。
7. 安全起见，NAS 上仍然部署 sniproxy，丢弃非 seafile.fakedomain.com 的访问，防止直接端口探测。

这样一套组合拳打下来，优缺点分别如下：

优点：

1. seafile 等自建云盘的文件传输是直接 客户端<-->NAS，无需第三方中转，家庭宽带的带宽上限下限可以发挥到极限。
2. 即便 ISP 采用 TCP 包拦截抓到 client hello 中的 server_name(seafile.fakedomain.com) 也无法直接访问，因为第三方请求 IP 不在 NAS 的白名单中
3. 理论上客户端无需进行特殊配置即可支持。（浏览器默认支持 301 302 跟随跳转，其他客户端就看代码本身了）

缺点：

1. 仍然需要一台中间服务器，当然了，最最便宜的 10 刀一年的垃圾 vps 就行了。
2. 需要客户端支持 http 301 302 跟随跳转，如果客户端的 http request 是自己写的，只接受 http code 200，其他默认 return error 的话，我这个方案就嗝儿屁。当然了，正常的网页浏览器都是支持的，怕就怕第三方手机 app 这种。譬如 seafile 的手机端认证时是采用 https 的，是否会跟随跳转我暂时没有测试。
3. 如果 nas 是跑云盘的话，大流量大带宽的使用仍然会被运营商发现，这个真的没有办法……

总结：

所以，如果你只是要访问家中的网页 https 服务，流量不那么大的那种，又不想被运营商扫到你的端口进行各种探测抓包的话，我这个方案似乎可行？

[lookas2001]

是维基百科的方案吗？

[hlz0812]

哪有那么多麻烦，按你这么说用联通家宽中转 v2 ws+tls 的不是都要死，说白了 https 非 443 端口几乎不管

[KyonLi]

我是开了一个代理端口，所有访问内网的走代理

[chairuosen]

家里公网出口 DDNS 到域名 1，但不处理域名 1 的请求，绑域名 2 的证书处理域名 2 的请求。
vps 部署一个 dnsmasq 写死域名 2 cname 到域名 1
任意地方想访问家里时，改本机 dns，再直接访问。
可防一般情况，不防绑 host 访问

[ddsfeng]

@binkcn 关键字 Port knocking 自己去搜吧

[binkcn]

@lookas2001 对维基百科并不了解。

@hlz0812 非 443 的 https 是否会触发 block 目前没有准确的说法，保险起见都默认 ISP 现在或者将来会这样做，所以我这个帖子主要讨论假定 ISP 会检测任意端口的 HTTPS 协议包。


@KyonLi 你这个方法的话对我没啥用，我如果在户外忽然想用手机 4G 网络打开 Seafile APP 看一下某个 PDF 的话就会很麻烦，而且家人用起来也不方便。

@ddsfeng 同上，这个方案也需要客户端额外做动作才可以，无法让客户端随时随地便捷访问。

@chairuosen 同上……

！！！注意：本帖讨论的目标是：客户端（即访问方，可能是手机 APP 等不受控的 Client ）无需额外操作（譬如按需访问端口，譬如修改 HOST，譬如修改 DNS 等）就可以访问家里 NAS 上的 HTTPS 服务 。

[wsy2220]

双向 SSL 认证足够了

[LnTrx]

@binkcn 直接挂一个静态网页用 js 做 Port knocking，那样连 VPS 也不需要

[hlz0812]

@binkcn 很多机场都是普通宽带中转，但是不清楚 https 网站和 v2 ws tls 的流量是不是完全一样，如果是完全一样，那真的没遇到非 443 被封的

[ashong]

只要不架设面向公众的内容几乎就不会管， 家宽本来也不是干这个的，这么折腾下去大家都别方便

[chairuosen]

@binkcn 你又想不让第三方复现，又想在任意设备不做改动访问，是不可能的。你手里的设备和第三方有何不同呢？

[justs0o]

说了 N 遍了，运营商是镜像流量的方式进行探测，就跟某设备的原理一样

[CheekiBreeki]

這麼麻煩，還不如 VPN 一步到位，又安全。你實名家寬整 web 被亂搞了就涼了

[jiangyang123]

都要用另外机器中转了，为啥不用 frp 这类工具呢

[jzphx]

难道没人知道上海家宽私设 web 被断网的事情吗，发帖的哪个是 443 的，直接扫端口，有 web 服务就断网

[BlackHole1]

有个疑问，在 302 跳转时，不会被监听到其中的 server_name 么

[binkcn]

@wsy2220 双向 SSL 会导致第三方手机 APP 访问 第三方 HTTPS 业务。比如我举例的 Seafile 云盘。

@talarax7 挂静态页面？挂载 NAS 上么，这不还是还是要开放一个端口提供 WEB 服务，直接就犯规了。

[binkcn]

@chairuosen 注意看帖子，我讲的很清楚了，我自己的访问是先访问 A，由 A 通知 B 开门，然后 A 再引导我访问的 B 。

而抓包等方式只能抓到我访问 B 这个环节，第三方复现直接访问 B 是拒绝访问的。

[binkcn]

@jiangyang123
@CheekiBreeki

注意审题。

[binkcn]

@BlackHole1 从 VPS 302 到 NAS 的时候，ISP 抓包都是在电信宽带侧抓包，所以抓到的包只是 Client to NAS 的包，那么这个 HTTPS 里面的 server_name 是具有白名单无法直接访问的。