hy172574895

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

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

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

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

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

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

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

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