客户端信任该证书。流量上识别到该连接的 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 日志服务器
|