关于XTLS的疑问

[sandianyue]

经实测，XTLS 在低性能或没有 AES 硬解的设备上效果出众，如在硬路由上换用 XTLS，同样跑满 CPU 时实现网速 翻倍，或是相同网速时 CPU 占用率减半 从第二个内层 TLS data record 开始，数据不二次加解密，直接转发，且从外面看还是一条连贯的普通 TLS

首先 感谢您的工作😊 然后请见谅 纯外行 就是喜欢瞎琢磨😀但是有时候想不通就很烦 。 按照个人理解 无论是socks5/http 还是透明代理(路由器、magisk模块等)中 由终端设备上的浏览器/APP发起的https连接的TLS(即内层TLS) 不都应该由终端本身浏览器/APP加解密吗

`

`

[RPRX]

这里指的是 XTLS 本身不再对内层的 TLS 加解密。

[sandianyue]

这里指的是 XTLS 本身不再对内层的 TLS 加解密。

所以我可以理解为 在以往的经典代理协议中 实际上客户端应用和目标服务器间的TLS数据包在代理过程中被加解密过？即先被代理的一端解密 再被另一端加密 最后到达终端/目标服务器 也就是这样？

我一直以为是借着代理直接透传的:(........那么这样处理的目的为何呢 我搜索了正向代理 透明代理 TLS https 加解密 没有搜到相关资料 。 按我的理解 代理只需要能获取SNI就可以了 为什么要加解密内层的TLS重新封包？

[RPRX]

按我的理解 代理只需要能获取SNI就可以了 为什么要加解密内层的TLS重新封包？

主要是因为你对代理的认知顺序与大多数人不同，在 XTLS 出现之前，TLS 代理都是无差别加解密数据，并不会特殊处理 TLS 流量，这是件很平常的事情。现在 XTLS 出现了，你先获知了 XTLS 的原理以及和传统 TLS 代理的区别，然后产生了问题：为什么以前的代理要二次加解密？这就像现代人先接触到了更先进的科技产物，而对古代人的做法表示不解。

几年前 HTTPS 还并不流行，所以以前出现的代理，不管是 SS 这类还是基于 TLS 的，都是无差别加解密数据以确保通信内容的安全。而现在 HTTPS、TLS 随处可见，XTLS 于是魔改了 Go 的 TLS 来实现特殊处理 TLS 流量，从而获得更强的性能。

[RPRX]

稍等，我似乎误解了你想表达的意思，但根源是你对我回复你的第一句话产生了误解，请仔细想一想。

[sandianyue]

稍等，我似乎误解了你想表达的意思，但根源是你对我回复你的第一句话产生了误解，请仔细想一想。

.....啊这 结合您的回复和表达的误解了的意思
我大胆猜测

这里指的是 XTLS 本身不再对内层的 TLS 加解密。

这句意思是不再往内层TLS外嵌套一层VLESS的TLS 而是拼接VLESS TLS上去成为一条 即在路由透明代理场景下 终端的内层TLS加密发出后 路由器不再需要出啥力计算加密外层TLS 直接拼接 （即路由器由传统TLS代理的无脑再套一层TLS变成处理https不套而是拼接 基本没有出力计算） 到达代理服务端后即脱落VLESS TLS部分。 但是这俩TLS的key/cert不一样啊 路由-代理服务端这段.... 我承认我懵了....😥

[RPRX]

XTLS 发送方和接收方约定检测到内层 TLS 第一个 data record 传输完毕后，后面的不再二次加解密，所以状态是同步切换的。

[sandianyue]

嗯 看了好多HTTPS/TLS通讯原理 发现原来理解偏了 也就是说当XTLS发现内层TLS时 路由器照常和代理服务端进行handshake中的client hello server hello 验证证书 交换协商pre master key 继而计算会话密钥 但是不加密record层 只起到验证身份作用 直接将内层TLS的 data record包传递。不知道这次理解对了没... 但是有个问题 虽然内层TLS不会被解密 但是会不会有被恶意篡改攻击风险 即虽然不加密 但XTLS是否会利用前面计算出的会话密钥进行Mac完整性校验(AEAD是否可以不加密只完整性校验)

[RPRX]

有过这种想法，也写过一些实现（没错，在这个仓库的公开版之前，我用不同的思路、从不同的角度写了至少七八种 XTLS）

但实际上没有必要，因为内层 TLS 也不是吃醋的，不管 XTLS 是否进行完整性校验，一旦出现中间人攻击，都会断。

[sandianyue]

有过这种想法，也写过一些实现（没错，在这个仓库的公开版之前，我用不同的思路、从不同的角度写了至少七八种 XTLS）

但实际上没有必要，因为内层 TLS 也不是吃醋的，不管 XTLS 是否进行完整性校验，一旦出现中间人攻击，都会断。

嗯嗯 感谢您的解答 😀