不依赖证书的伪 TLS

[hy172574895]

总结

1. 无需证书
2. 1-RTT ，防止任何重放攻击
3. 不需要每次都跟伪装站交互
4. 很安全；不能被识别出来，无视主动探测

链接

1. 协议 PDF
2. 安装使用

目前还在测试和征集建议阶段，很多东西可能会随时被更改或不兼容，欢迎大家到 Github 留言反馈。

更新一些图片，便于理解： https://zhuanlan.zhihu.com/p/639547430

[tool2d]

自定义代理协议，感觉还是用 google 的 gprc 方便一些。

对外就是 http2 ，也没办法做流量识别。

[hy172574895]

@tool2d 这个应该是安全层的协议哦，对标的是 TLS

[Jirajine]

土制协议容易，土制类 tls 协议就有点困难了，tls 太复杂了。
我感觉目前的网络架构下，anti censorship 的顶点就是 shadowTLS 这种方案了。

[hy172574895]

@Jirajine TLS1.3 很简单的。同类协议我就不评论了。建议你先看看 PDF ，可能会让你改观，什么叫顶点

[e3c78a97e0f8]

粗略的看了一下，我没明白这个怎么防止重放攻击的。我重复发一个 ClientHello 用你同样的 random 不就暴露了吗？

[hy172574895]

@e3c78a97e0f8 PDF 里面“基本原理” 那部分。TLS 是有两个随机数的，一个来自 Client 一个来自 Server ，共同组成本次对话 ID 。还应该加上 x25519 生成的共同密钥，以保证前向安全。

[swulling]

问个问题，我看协议内容中说 session id 应该是随机的。但是正常的 TLS 中 session id 应该是复用的吧。

那么这个特征能够用来探测你的协议？

[hy172574895]

@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.
```

[e3c78a97e0f8]

@hy172574895 我不是问前向安全，我是问主动探测。如果我理解没错，GFW 重放 ClientHello 就会收到假证书从而判断出这不是正常的 TLS 服务器。

[retanoj]

@e3c78a97e0f8
我也想问这个。 客户端 ClientHello 换到的证书是它站证书，证书里并没登记 JLS 服务端 IP/域名信息，这已经可以判断出异常了

[hy172574895]

@e3c78a97e0f8 TLS1.3 是加密证书的，需要使用 x25519 生成的 ShareSecretKey ，才能解密出证书。又因为 TLS 协议会对 Hello 头做完整性验证，攻击者无法是违法伪装 Hello 头的。

[hy172574895]

@retanoj 你说的那种是 TLS1.2 ，证书是明文的。然而 JLS 检测到不是 1.3 的话直接转发，不作处理，协议文档中有规定

[busier]

@tool2d 当年 TLS/https 也是这么说的

[retanoj]

@hy172574895
还是理解有差异。
探测者访问的是 jls server IP ，获得的内容是什么？是 fake 站的证书？ fake 站的 HTML 内容？还是获得一个报错信息？

[hy172574895]

@retanoj
比如伪装站设置为: apple.com
探测者访问 JLS Server ，则 Server 判断：
1. 来源是 TLS1.3 ，进行 Client 验证，不是有效 Client 则转发到 apple.com 的服务器，有效则按照正常代理流程
2. 来源不是 TLS 或者是 TLS1.2 ，直接转发到 apple.com 的服务器

apple.com 的服务器返回什么，我的 VPS 就返回什么（就是转发的意思）。探测者看到的内容就是 apple.com 的内容

[retanoj]

@hy172574895
那你看，一个正常的人，探测的人，非 JLS Client 用户。访问 JLS Server IP 获得到的却是 apple.com 网站相关的证书和内容，这算不算一种“不正常”

[hy172574895]

@retanoj 前提是你要知道我的 IP 不是苹果的啊。除非是每个备案网站都要提供他使用的全部 IP ，不备案就访问不了，在这种严酷环境下，你连正常 TLS 的流量都被禁止。

再说了，你不想转发到苹果也行，可以转发到你自己的网站，伪装站都是任意的。

[retanoj]

@hy172574895

可以自圆其说就是很好的，这个话题就先不继续往下聊了。:)

[e3c78a97e0f8]

@hy172574895 我和服务器发生一次握手，然后 GFW 重用我的 ClientHello 里面 random ，会发生什么

[hy172574895]

@e3c78a97e0f8 Server 会回复由 JLS 生成的 Server Hello ，但因为是加密的，GFW 也解密不了

[hy172574895]

@e3c78a97e0f8 可能我说得太简单了，GFW 重放只能重放整个 Client Hello ，而不能仅“偷”已经生成的 Random

[zylll520]

我想问下 Client 端不支持 macOS 对吗？ 压缩包里面是 RRS_macOS.exe

[hy172574895]

@zylll520 支持的，后缀 exe 是 CI 统一加上去的。目前建议使用这个最新的 https://github.com/JimmyHuang454/sing-box