1
tool2d 2023-06-25 22:40:53 +08:00
自定义代理协议,感觉还是用 google 的 gprc 方便一些。
对外就是 http2 ,也没办法做流量识别。 |
2
hy172574895 OP @tool2d 这个应该是安全层的协议哦,对标的是 TLS
|
3
Jirajine 2023-06-25 22:52:47 +08:00
土制协议容易,土制类 tls 协议就有点困难了,tls 太复杂了。
我感觉目前的网络架构下,anti censorship 的顶点就是 shadowTLS 这种方案了。 |
4
hy172574895 OP @Jirajine TLS1.3 很简单的。同类协议我就不评论了。建议你先看看 PDF ,可能会让你改观,什么叫顶点
|
5
e3c78a97e0f8 2023-06-25 23:28:15 +08:00
粗略的看了一下,我没明白这个怎么防止重放攻击的。我重复发一个 ClientHello 用你同样的 random 不就暴露了吗?
|
6
hy172574895 OP @e3c78a97e0f8 PDF 里面“基本原理” 那部分。TLS 是有两个随机数的,一个来自 Client 一个来自 Server ,共同组成本次对话 ID 。还应该加上 x25519 生成的共同密钥,以保证前向安全。
|
7
swulling 2023-06-26 00:01:18 +08:00 via iPhone
问个问题,我看协议内容中说 session id 应该是随机的。但是正常的 TLS 中 session id 应该是复用的吧。
那么这个特征能够用来探测你的协议? |
8
hy172574895 OP @swulling
``` In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. ``` 你的确发现了协议中的一个不够明确的规定,关于 PSK 的东西可以先不管着,那个很容易搞。 而且: ``` IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data. Specifically: 1. This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK. 2. There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is provided via the server's Random value, but 0-RTT data does not depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. The same warnings apply to any use of the early_exporter_master_secret. ``` |
9
e3c78a97e0f8 2023-06-26 09:52:21 +08:00 via iPhone
@hy172574895 我不是问前向安全,我是问主动探测。如果我理解没错,GFW 重放 ClientHello 就会收到假证书从而判断出这不是正常的 TLS 服务器。
|
10
retanoj 2023-06-26 10:01:06 +08:00
@e3c78a97e0f8
我也想问这个。 客户端 ClientHello 换到的证书是它站证书,证书里并没登记 JLS 服务端 IP/域名信息,这已经可以判断出异常了 |
11
hy172574895 OP @e3c78a97e0f8 TLS1.3 是加密证书的,需要使用 x25519 生成的 ShareSecretKey ,才能解密出证书。又因为 TLS 协议会对 Hello 头做完整性验证,攻击者无法是违法伪装 Hello 头的。
|
12
hy172574895 OP @retanoj 你说的那种是 TLS1.2 ,证书是明文的。然而 JLS 检测到不是 1.3 的话直接转发,不作处理,协议文档中有规定
|
14
retanoj 2023-06-26 20:54:50 +08:00 via iPhone
|
15
hy172574895 OP |
16
retanoj 2023-06-27 08:49:56 +08:00
@hy172574895
那你看,一个正常的人,探测的人,非 JLS Client 用户。访问 JLS Server IP 获得到的却是 apple.com 网站相关的证书和内容,这算不算一种“不正常” |
17
hy172574895 OP @retanoj 前提是你要知道我的 IP 不是苹果的啊。除非是每个备案网站都要提供他使用的全部 IP ,不备案就访问不了,在这种严酷环境下,你连正常 TLS 的流量都被禁止。
再说了,你不想转发到苹果也行,可以转发到你自己的网站,伪装站都是任意的。 |
18
retanoj 2023-06-27 09:09:56 +08:00
|
19
e3c78a97e0f8 2023-06-29 09:20:59 +08:00
@hy172574895 我和服务器发生一次握手,然后 GFW 重用我的 ClientHello 里面 random ,会发生什么
|
20
hy172574895 OP @e3c78a97e0f8 Server 会回复由 JLS 生成的 Server Hello ,但因为是加密的,GFW 也解密不了
|
21
hy172574895 OP @e3c78a97e0f8 可能我说得太简单了,GFW 重放只能重放整个 Client Hello ,而不能仅“偷”已经生成的 Random
|
22
zylll520 2023-07-18 12:22:56 +08:00
我想问下 Client 端不支持 macOS 对吗? 压缩包里面是 RRS_macOS.exe
|
23
hy172574895 OP @zylll520 支持的,后缀 exe 是 CI 统一加上去的。目前建议使用这个最新的 https://github.com/JimmyHuang454/sing-box
|