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

[iqoo]

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

[MFWT]

理论上做的不仔细的话，证书颁发机构之类的细节会暴露（当然也可以自签名一个就是了）
不过我也不确定会不会看得那么仔细，还是说就看 SNI 算了

[estk]

shadowtls ？

[choury]

如果是用浏览器访问的话，最大的问题是怎么绕过 ct （证书透明度）

[billlee]

TLS 1.3 的服务器证书是加密传输的吧，被动监听看不到证书。主动探测那就没办法了。

[leaflxh]

网监：小伙子天天 window shopping

[documentzhangx66]

当客户端信任你的自签证书后，你就相当于 CA ，你在客户端上就相当于可信 CA 。

然后你给 www.apple.com 签证书，并且改 DNS 做一个假 www.apple.com 网站，整个流程上，假 www.apple.com 对于客户端来说，其实就是真网站了。

[LeviMarvin]

@choury Google 对 Chromium 内核浏览器（ Chrome ，Edge 等）的 CT 策略是，证书必须有 Google CT 服务器（不可为测试服务器）和第三方 CT 服务器。可以考虑搭建一个公开的 CT 服务器，我之前搭建过一个并将 SCT 信息嵌入到证书中。但是在我研究的时候发现，这方面公开技术文档几乎为 0 ，官方的说法是：对于第三方根证书信任链签发的 SSL 证书不需要 CT

[xabcstack]

真的吗 我不信 ~

[nobody123123]

发现主动探测，直接把 tcp 流量转发到真的 Apple. 可行吗

[Zy143L]

之前看还有一个说法是
对你主动监测了，你 tm 看天天大流量看 apple 商店
怎么看都不对劲

[choury]

@LeviMarvin 你自己搭有什么用啊，chrome 信任的 CT 服务器的公钥是硬编码在代码里的，它又不信任你搞得那个

[Aloento]

@Zy143L #10 这时候就需要 speedtest 出马了

[baobao1270]

没有不同吧

[popzuk]

那个 shadowtls 和 reality 比这更进一步，直接用别人的证书。然而，这种方法如果大规模使用，会不会使用 dns 或者 as 号来对应之类的就不清楚了。

[LeeReamond]

@choury 确实是这么回事，我记得 chrome 是有硬编码的，所以看这个帖子的时候很疑惑没明白 OP 想干什么

[yylzcom]

@LeeReamond #15 翻墙用的，肯定不是给正常浏览器

@iqoo 虽然墙这个东西是黑盒，然而就我的经验来说，用的 ws+tls+vmess, 自己的服务器 /域名 /网站。我自己常年用都没事（稳定四年），但敏感期的时候共享给老婆用，同样的配置给一个封一个。所以，客户端因素不可忽略。她就用来玩个 Candy Crush Saga 连接服务器领奖励。

[iqoo]

@estk
@popzuk

shadowtls 出来之前就用试过类似的方案了，但反代会浪费流量。如果握手环节没破绽，不会自签更节省。

主动探测也是没用的，因为服务端只允许自己的 ip 访问。

[e3c78a97e0f8]

@Zy143L 这个说法只有在人工监控的时候有意义。对于自动化的监控，GFW 很难判断哪个域名有多少流量是合理的。

[jinliming2]

和官方证书的明显不同：证书颁发机构不是可信的颁发机构。正常的证书是由公共可信的 DigiCert 根的 Apple Public 中间证书签发的，而你的证书则是一个由不是公共可信的根证书颁发机构颁发的证书。
如果你用的是 TLS1.2 的话，那中间人完全能知道你连接的这个地址证书不正常。
而如果你用了 TLS1.3 ，那 Server Certificate 包是加密的，中间人没办法直接知道证书是否正常，但是你拦不住人家主动探测。如果你的流量特征不太正常（比如大流量），就把你的 IP 和 SNI 记下来，然后主动探测访问一下，就知道证书是否正常了。

另外，即便你能搞到受公共可信 CA 颁发的 apple.com 的证书也不行，因为 apple.com 的 DNS 记录里有 CAA 记录的，不允许其他 CA 颁发这个域名的证书（君子协议，正规可信的 CA 都会遵守），所以你的 CA 不一样肯定有问题。

[ruankaopai]

https://www.v2ex.com/t/950826 Thanks♪(･ω･)ﾉ

[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 日志服务器