这是一个创建于 520 天前的主题，其中的信息可能已经有所发展或是发生改变。
客户端信任该证书。流量上识别到该连接的 SNI 是 www.apple.com ，是否还有其他细节能看出和官方的证书不同？只考虑 TLSv1.3 协议。
 |
1
MFWT 2023-06-21 17:44:11 +08:00
理论上做的不仔细的话，证书颁发机构之类的细节会暴露（当然也可以自签名一个就是了）
不过我也不确定会不会看得那么仔细，还是说就看 SNI 算了 |
 |
2
estk 2023-06-21 17:44:28 +08:00 via iPhone
shadowtls ？
|
 |
3
choury 2023-06-21 18:11:53 +08:00
如果是用浏览器访问的话，最大的问题是怎么绕过 ct （证书透明度）
|
 |
4
billlee 2023-06-21 18:29:46 +08:00 via Android  1
TLS 1.3 的服务器证书是加密传输的吧，被动监听看不到证书。主动探测那就没办法了。
|
 |
5
leaflxh 2023-06-21 19:07:28 +08:00 2
网监：小伙子天天 window shopping
|
 |
6
documentzhangx66 2023-06-21 21:28:25 +08:00
当客户端信任你的自签证书后，你就相当于 CA ，你在客户端上就相当于可信 CA 。
然后你给 www.apple.com 签证书，并且改 DNS 做一个假 www.apple.com 网站，整个流程上，假 www.apple.com 对于客户端来说，其实就是真网站了。 |
 |
7
LeviMarvin 2023-06-21 21:40:40 +08:00 1
@choury Google 对 Chromium 内核浏览器（ Chrome ，Edge 等）的 CT 策略是，证书必须有 Google CT 服务器（不可为测试服务器）和第三方 CT 服务器。可以考虑搭建一个公开的 CT 服务器，我之前搭建过一个并将 SCT 信息嵌入到证书中。但是在我研究的时候发现，这方面公开技术文档几乎为 0 ，官方的说法是：对于第三方根证书信任链签发的 SSL 证书不需要 CT
|
 |
8
xabcstack 2023-06-21 21:44:44 +08:00
真的吗 我不信 ~
|
 |
9
nobody123123 2023-06-21 21:58:29 +08:00
发现主动探测，直接把 tcp 流量转发到真的 Apple. 可行吗
|
 |
10
Zy143L 2023-06-22 00:57:20 +08:00 via Android
之前看还有一个说法是
对你主动监测了，你 tm 看天天大流量看 apple 商店 怎么看都不对劲 |
|
11
choury 2023-06-22 01:15:19 +08:00 via Android
@LeviMarvin 你自己搭有什么用啊，chrome 信任的 CT 服务器的公钥是硬编码在代码里的，它又不信任你搞得那个
|
 |
13
baobao1270 2023-06-22 06:34:58 +08:00 via Android
没有不同吧
|
 |
14
popzuk 2023-06-22 06:56:06 +08:00
那个 shadowtls 和 reality 比这更进一步，直接用别人的证书。然而，这种方法如果大规模使用，会不会使用 dns 或者 as 号来对应之类的就不清楚了。
|
 |
15
LeeReamond 2023-06-22 08:06:15 +08:00
@choury 确实是这么回事，我记得 chrome 是有硬编码的，所以看这个帖子的时候很疑惑没明白 OP 想干什么
|
 |
16
yylzcom 2023-06-22 09:52:48 +08:00
@LeeReamond #15 翻墙用的，肯定不是给正常浏览器
@iqoo 虽然墙这个东西是黑盒，然而就我的经验来说，用的 ws+tls+vmess, 自己的服务器 /域名 /网站。我自己常年用都没事（稳定四年），但敏感期的时候共享给老婆用，同样的配置给一个封一个。所以，客户端因素不可忽略。她就用来玩个 Candy Crush Saga 连接服务器领奖励。 |
 |
17
iqoo OP |
 |
18
e3c78a97e0f8 2023-06-22 11:12:28 +08:00
@Zy143L 这个说法只有在人工监控的时候有意义。对于自动化的监控，GFW 很难判断哪个域名有多少流量是合理的。
|
 |
19
jinliming2 2023-06-22 11:31:41 +08:00 via iPhone
和官方证书的明显不同：证书颁发机构不是可信的颁发机构。正常的证书是由公共可信的 DigiCert 根的 Apple Public 中间证书签发的，而你的证书则是一个由不是公共可信的根证书颁发机构颁发的证书。
如果你用的是 TLS1.2 的话，那中间人完全能知道你连接的这个地址证书不正常。 而如果你用了 TLS1.3 ，那 Server Certificate 包是加密的，中间人没办法直接知道证书是否正常，但是你拦不住人家主动探测。如果你的流量特征不太正常（比如大流量），就把你的 IP 和 SNI 记下来，然后主动探测访问一下，就知道证书是否正常了。 另外，即便你能搞到受公共可信 CA 颁发的 apple.com 的证书也不行，因为 apple.com 的 DNS 记录里有 CAA 记录的，不允许其他 CA 颁发这个域名的证书（君子协议，正规可信的 CA 都会遵守），所以你的 CA 不一样肯定有问题。 |
 |
20
ruankaopai 2023-06-22 11:37:30 +08:00
https://www.v2ex.com/t/950826 Thanks♪(･ω･)ﾉ
|
|
21
jinliming2 2023-06-22 11:38:44 +08:00 via iPhone
@iqoo #17 GFW 主动探测的话，你服务器开 IP 白名单没用。
GFW 存在于你本地 IP 到你服务器 IP 中间的一个中间路由节点，完全可以假装是你，然后以你的 IP 的名义向你的服务端发起 TCP 请求，然后拦截服务端的响应的 ACK ，毕竟所有入口 / 出口流量都要经过 GFW ，而 TCP 的源地址又是可以随意指定的。 |
|
22
jinliming2 2023-06-22 11:49:15 +08:00 via iPhone
另外，你开 IP 白名单，防止了主动探测，但这不是正好证明这个服务器不是正常的 apple 服务器么，哪个正常的服务器会开白名单啊……
既然都触发主动探测了，肯定是流量上触发了什么机制了，算作可疑服务器被盯上了。如果主动探测看不出异常，也许就临时放过了，但既然主动探测无法访问，那即便你这个服务器是真实的 apple 的服务器，直接给你拦截了也没问题，毕竟“绝大多数国内的用户都无法正常访问”嘛，直接封 IP 受影响的用户也不多。 |
|
23
iqoo OP @jinliming2 防止主动探测确实不是好策略，只是想省点流量。。。
不过伪造源 IP 的方式倒有办法解决。后来用的是数据包敲门的方式加信任 IP ，敲门数据是用私有算法生成并且可防重放，随便解决同个公网 IP 下（比如公司其他人）也能访问服务器的缺陷。 |
 |
24
lslqtz 2023-06-22 12:30:29 +08:00
如果 IP 与白名单不符, 可以使用 SNIProxy 的方式.
|
|
25
lslqtz 2023-06-22 12:32:42 +08:00
另外, 可以使用一种 "敲门" 机制, 即在建立连接前预先透过其它方法访问, 且同时只能建立一个连接, 其它连接均采用 SNIProxy, 以降低 IP 伪造成功率.
|
 |
26
tool2d 2023-06-22 12:47:30 +08:00
只是混淆一下流量，你这弄的也太高端了，用 UDP 简单加密一次，伪装成游戏包，也没啥问题。
|
|
27
iqoo OP |
|
29
LeviMarvin 2023-06-22 23:24:43 +08:00
@choury @LeeReamond Google 会在申请后一年添加自建 CT 服务器，这个在 Google Chrome CT 策略也有写，但是 chrome 还强制要求必须包含 Google 非测试 CT 日志服务器
|
Select Language