自签一个 www.apple.com 证书，流量上有什么破绽？

[iqoo]

客户端信任该证书。流量上识别到该连接的 SNI 是 www.apple.com ，是否还有其他细节能看出和官方的证书不同？只考虑 TLSv1.3 协议。

[jinliming2]

@iqoo #17 GFW 主动探测的话，你服务器开 IP 白名单没用。
GFW 存在于你本地 IP 到你服务器 IP 中间的一个中间路由节点，完全可以假装是你，然后以你的 IP 的名义向你的服务端发起 TCP 请求，然后拦截服务端的响应的 ACK ，毕竟所有入口 / 出口流量都要经过 GFW ，而 TCP 的源地址又是可以随意指定的。

[jinliming2]

另外，你开 IP 白名单，防止了主动探测，但这不是正好证明这个服务器不是正常的 apple 服务器么，哪个正常的服务器会开白名单啊……
既然都触发主动探测了，肯定是流量上触发了什么机制了，算作可疑服务器被盯上了。如果主动探测看不出异常，也许就临时放过了，但既然主动探测无法访问，那即便你这个服务器是真实的 apple 的服务器，直接给你拦截了也没问题，毕竟“绝大多数国内的用户都无法正常访问”嘛，直接封 IP 受影响的用户也不多。

[iqoo]

@jinliming2 防止主动探测确实不是好策略，只是想省点流量。。。

不过伪造源 IP 的方式倒有办法解决。后来用的是数据包敲门的方式加信任 IP ，敲门数据是用私有算法生成并且可防重放，随便解决同个公网 IP 下（比如公司其他人）也能访问服务器的缺陷。

[lslqtz]

如果 IP 与白名单不符, 可以使用 SNIProxy 的方式.

[lslqtz]

另外, 可以使用一种 "敲门" 机制, 即在建立连接前预先透过其它方法访问, 且同时只能建立一个连接, 其它连接均采用 SNIProxy, 以降低 IP 伪造成功率.

[tool2d]

只是混淆一下流量，你这弄的也太高端了，用 UDP 简单加密一次，伪装成游戏包，也没啥问题。

[iqoo]

@iqoo
"不会自签更节省" --> "不如自签更节省"
"随便解决" --> "顺便解决"

换了个输入法打出一堆错别字 - -

[iqoo]

@lslqtz 不需要 SNI 转发。这种域名固定的，直接转发到源站就行。多个域名才需要 SNI 转发。

[LeviMarvin]

@choury @LeeReamond Google 会在申请后一年添加自建 CT 服务器，这个在 Google Chrome CT 策略也有写，但是 chrome 还强制要求必须包含 Google 非测试 CT 日志服务器