Chocolatey无法通过XTLS连接服务器

[xsm1997]

我使用了支持XTLS功能的v2ray-core（VLESS+TCP+TLS方式），在使用Chocolatey时，无法连接默认源。错误信息如下：

Error retrieving packages from source 'https://chocolatey.org/api/v2/':
 解密操作失败，请参见内部异常。

测试命令为choco install nodejs。

除此之外，暂未发现其他解密失败的情况。尝试过浏览器打开上述URL，没有问题。由于Chocolatey基于powershell，我又使用了powershell命令Invoke-WebRequest随便下载了一个文件，也没有问题。

看样子像是一个使用特定客户端或者访问特定网站才会发生的bug？

[RPRX]

感谢反馈！首先，不使用 XTLS 时有无这个错误？

按理来说，若内层是符合规范的标准 TLS，则外层使用 XTLS 不会出现问题。可否用 Wireshark 截取一下直连时的流量？

[RPRX]

XTLS 目前不支持内层 TLS 总长超过 5+16384+256 的 data record，即 TLSv1.3 的上限。

而 TLSv1.2 data record 的总长上限为 5+16384+2048，但绝大多数时候，并不会超过 TLSv1.3 的上限。

若内层为 TLSv1.2，在极罕见情况下，会无法通过 XTLS。

[RPRX]

另外，内层 TLS 不能中途发 change cipher record（在 TLSv1.2 及以前，它是可用的，但是也很少见）。

由于 XTLS 本身会是 TLSv1.3，可以说对于内层 TLS，完美支持 1.3，基本支持 1.2。

[xsm1997]

首先，不使用xtls的时候没有问题。 wireshark抓包已上传，压缩包里面的xtls是开启了xtls之后的抓包，noxtls是不开启xtls（但开启v2ray透明代理）时的抓包。 choco.zip

简单分析了一下，开启xtls之后，比不开启xtls，在本地发送FIN之后，远程又额外多发来一个TLS数据包（长度19），而问题就应该出在这个数据包。收到这个数据包之后，本地马上发送RST报文，强制断开连接。

[RPRX]

@xsm1997

感谢测试，noxtls 是 Chocolatey 的 TLS 还是 v2ray 的 TLS？

[xsm1997]

@rprx

noxtls为在运行Chocolatey的计算机上抓的包，v2ray是运行在路由器上面的（作为透明代理，也开启了TLS）。 所以这里应为Chocolatey的TLS（如果我没理解错您的意思的话），连接的也是Chocolatey的服务器。

[RPRX]

@xsm1997

xtls 也是透明代理吗？

[xsm1997]

@rprx

是的。

[RPRX]

@xsm1997

其实我之前测试的时候遇到了一个神奇的情况：从输出来看，XTLS 的发送方并没有发送 23 24（5+19），但接收方却收到了。。。

[xsm1997]

@rprx

是否可以在转发TLS数据的时候同时进行解密，以便于确认这5+19大小的包的明文是什么？（仅供调试）

[xsm1997]

@rprx

sorry，我可能弄错了，刚才那个请求虽然触发了RST，但是貌似被客户端接受了（经过fiddler https mitm调试）。接下来的第二个请求才是解密错误，fiddler做中间人也无法正常解密。已重新上传抓包

choco2.zip

表现还是多了一个5+19长度的包，很奇怪。

[xsm1997]

@rprx

当内层TLS连接和外层TLS连接使用不同的Cipher Suite的时候，XTLS是如何处理的？

发现一个奇怪的事情，我尝试了同时在本机和路由器上抓包，Chocolatey使用TLS1.2（CipherSuite为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256），而xtls使用TLS1.3 （CipherSuite为TLS_AES_128_GCM_SHA256），这时其他data record看起来都是完全不一样的，唯独那个5+19大小的包，是一模一样的。

而且在路由器上直接抓取v2ray到服务器的包，表明路由器确实收到了5+19的包，并把它原样不动地转发给了Chocolatey。除此之外，路由器上的v2ray在收到了5+19的包之后，又回复了一个5+19的包（跟上一个不一样），并且此包Chocolatey没有发出。

而且不是所有的请求都会有这个5+19的包。具体规律未找出。推测是不是vless的一些协议部分没有处理呢？

EDIT: 尝试了在服务器和本机同时抓包，服务器和Chocolatey服务器的通信中并未出现5+19的包，但服务器和路由器v2ray的通信中出现了5+19的包，并且这个包被原封不动地转发给了本机。服务器v2ray也受到了路由器v2ray回复的5+19的包。

由于附带隐私，就不继续上传抓包了。

[RPRX]

@xsm1997

不管使用何种加密套件，TLS data record 格式都是一样的，在此格式中，TLSv1.3 用的是 TLSv1.2 的版本号。

目前可以确定这种 23 24 的包由 v2ray 自己发出，有可能是 conn.go 的 flush() 函数（但也不应该发出 23 的包）。

[RPRX]

@xsm1997

XTLS 接管 writeRecordLocked 函数后，只放行连续的正确的 TLS data record 格式（以及 alert），除非这里被绕过了。

[xsm1997]

@rprx

请问“23 24的包”代表什么呢？

[RPRX]

@xsm1997

23 代表 data record。

我给 conn.go 的 write 和 flush 函数分别设置了输出，目前观察到的是 write 函数时不时有 23 24 的包，且有的包本不该出现。

[RPRX]

@xsm1997

找到问题在哪了：TLSv1.3 加密 record 的第一个字节均为 23（即使是 alert），我也会根据这个特性对 XTLS 进行些调整。

（XTLS 接管的情况下仍有未经记录的 23 24 跑出来，那很显然它们就是之前我特地放跑了的 21 [1, 0]，代码也证实了这一点。）

[RPRX]

其实之前看 24 这个长度就像是加密后的 alert，但它第一个字节是 23，成功地迷惑了我。

[xsm1997]

哈哈，静候更新

[RPRX]

https://github.com/rprx/v2ray-vless/releases

[xsm1997]

使用最新build后，Chocolatey已经可以正常工作。