Reality是否会缓存被"偷"网站的握手信息

[raintean]

看了源码, 没看懂. 也搜过issue/discussion没有找到.
想了解一下, 每次客户端连接到服务器的时候, 服务器都是临时去fetch证书信息的吗?

[RPRX]

对，以后会缓存

[RPRX]

大致看了下你们的讨论，我说一下，REALITY 服务端要“学习”的是到目标网站的延迟、Sever Hello 响应内容以及后续证书等密文的长度（看不到明文），此外还有 maxUselessRecords and some time-outs 以及 目标网站是否支持 tlshello 分片 等，这些是难点

[mofanxt]

感谢，我理解了，需要”学习”的就是各种异常以及正常情况下的行为，确实是个难点

[RPRX]

其实还有比较关键的一处，四年前公开提过，我一直没敢再提，因为说出来后果挺炸裂的

[raintean]

大致看了下你们的讨论，我说一下，REALITY 服务端要“学习”的是到目标网站的延迟、Sever Hello 响应内容以及后续证书等密文的长度（看不到明文），此外还有 maxUselessRecords and some time-outs 以及 目标网站是否支持 tlshello 分片 等，这些是难点

证书长度我有考虑到, 目前自签证书, 配合一些证书的extension做padding, 模拟长度. 从包的长度来看比较够用的.
另外挺关心这个炸裂的东西是什么. 哈哈

[RPRX]

证书长度我有考虑到, 目前自签证书, 配合一些证书的extension做padding, 模拟长度. 从包的长度来看比较够用的.

因为不止有证书这一条密文消息的长度要模仿，所以 REALITY 统一用 TLSv1.3 自带的 padding 机制

[mofanxt]

@RPRX 我看了下代码，我感觉目前每次建连时都要求请求 ServerName 的原因主要应该是为了让xray服务器的行为在非认证流量时(比如gfw 直接 curl 来探测 xray 服务)的行为和ServerName站点行为一致对吧？
我感觉可以对经过认证的流量对 ServerName target conn 的响应进行懒加载缓存，对于非认证流量则保持现有逻辑不缓存
总体有点像之前的 fallbacks 逻辑的思路

[raintean]

可以先上PR, 大家审核看看.

[mofanxt]

然后对于缓存key的生成我觉得也是值得讨论的: 1.就像你说的，对整个ClientHello包(除去随机/时间等)做hash，这种是最保守的方案，但是缓存数量会过多 2.只对单个client指纹(例如UserAgent，TLSFinge等) 做key的hash，这种缓存数量取决于用户设备数 3.只对ServerName，这种缓存数量最少，但是是否会暴露给gfw特征也是要考虑
还有对于特征暴露，如果区别对待认证和非认证流量的缓存机制，那么我认为有2种方案解决 1.可能根本不存在这个特征问题？因为本身延迟还要取决于访问站点的延迟会有较大不同，需要被偷网站延迟需要高到超过大部分站点网站的响应时间，而且之前的fallbacks方案也存在类似的问题的(非认证流量往往是个本地静态页或者简单的本地网盘服务)，并且在gfw视角下他访问的本身就是个非常规业务接口，响应时间比正常api低那是合理的 2.不区分对待非认证流量，全部都走缓存逻辑，但这里可能又会出现缓存失效时的第一次请求rt较大，那么可以做成按key lru并且刷新单个key缓存是异步定时触发的

针对这段话, 有如下问题:

1. 缓存key目前较好的是 TLS 指纹方案. 但不是ja3, 因为chrome高版本会存在 tls extension混洗的特性. 你懂我意思就行了.
2. 另外没有UserAgent这种东西, 在TLS这一层怎么会有http里面的概念? 是我理解有问题吗?
3. 同样关于 “因为本身延迟还要取决于访问站点的延迟会有较大不同” 这里的表述, 我觉得可能也有问题. 我没看过源码, 难道Reality返回ServerHello的时机由节点到目标网站的ServerHello返回时机来决定? (BTW, 不过这个倒是给我提供了一个伪装的思路, 哈哈, 明天就写到自己的协议里)
4. “不区分对待非认证流量，全部都走缓存逻辑“ 这里也有问题, 如果全部走缓存逻辑, 非认证连接如果要进行真实通讯怎么办? 你完全没法模拟证书啊. 这个路子完全不可行.

另外建议熟读一下TLS协议规范, 中间的事实错误比较

多.

然后对于缓存key的生成我觉得也是值得讨论的: 1.就像你说的，对整个ClientHello包(除去随机/时间等)做hash，这种是最保守的方案，但是缓存数量会过多 2.只对单个client指纹(例如UserAgent，TLSFinge等) 做key的hash，这种缓存数量取决于用户设备数 3.只对ServerName，这种缓存数量最少，但是是否会暴露给gfw特征也是要考虑
还有对于特征暴露，如果区别对待认证和非认证流量的缓存机制，那么我认为有2种方案解决 1.可能根本不存在这个特征问题？因为本身延迟还要取决于访问站点的延迟会有较大不同，需要被偷网站延迟需要高到超过大部分站点网站的响应时间，而且之前的fallbacks方案也存在类似的问题的(非认证流量往往是个本地静态页或者简单的本地网盘服务)，并且在gfw视角下他访问的本身就是个非常规业务接口，响应时间比正常api低那是合理的 2.不区分对待非认证流量，全部都走缓存逻辑，但这里可能又会出现缓存失效时的第一次请求rt较大，那么可以做成按key lru并且刷新单个key缓存是异步定时触发的

针对这段话, 有如下问题:

1. 缓存key目前较好的是 TLS 指纹方案. 但不是ja3, 因为chrome高版本会存在 tls extension混洗的特性. 你懂我意思就行了.
2. 另外没有UserAgent这种东西, 在TLS这一层怎么会有http里面的概念? 是我理解有问题吗?
3. 同样关于 “因为本身延迟还要取决于访问站点的延迟会有较大不同” 这里的表述, 我觉得可能也有问题. 我没看过源码, 难道Reality返回ServerHello的时机由节点到目标网站的ServerHello返回时机来决定? (BTW, 不过这个倒是给我提供了一个伪装的思路, 哈哈, 明天就写到自己的协议里)
4. “不区分对待非认证流量，全部都走缓存逻辑“ 这里也有问题, 如果全部走缓存逻辑, 非认证连接如果要进行真实通讯怎么办? 你完全没法模拟证书啊. 这个路子完全不可行.

另外建议熟读一下TLS协议规范, 中间的事实错误比较多.

好的，感谢，后面我整理个pr大家一起看看吧

[mofanxt]

仔细想了下,这个缓存应该是做不了的
客户端每次tls发起握手阶段会有生成随机值来让dest域名的持有者来加密，而xray作为中间人是没有dest的证书私钥的，缓存了必然不能完成tls握手，我理解这是tls的防中间人攻击的设计基础

[raintean]

事实上可以做, ClientRandom ClientSessionID均可用来做客户端的合法验证, 当客户端的合法验证通过后, 你通过ja3(暂定)来查找缓存, 发现没有, 可以尝试转发到“被偷网站”来获取ServerHello, 其实这个ServerHello中间的最有用的是 选择的加密套件等等这些信息, ServerRandom ServerSessionID(tls1.3必须等同客户端) 还要25519 pubkey这些都可以替换, 并不会暴露特征.

[raintean]

所谓的 “被偷网站” 的特征信息其实也是加密套件的选择, 你可以参考tls server的ja3是如何探测出来的. 就明白这个原理了.