修复tls lazy encrypt功能的 tls1.3 传输 tls1.2 的一种技术实现

[e1732a364fed]

想到了一个方法，不知可不可行，现陈述如下：

目前可以默认，支持tls1.3的服务器也不少了，所以客户端如果申请tls1.3握手的clienthello，可以直接以tls1.3的方式向服务端拨号，然后因为实际上，我们拨号是向代理服务器拨号，然后代理服务器再帮我们向实际服务器拨号，

所以，可以与最新的 ”连接池“技术提议相融合：当代理服务器发现目标服务器使用的实际上是tls1.2握手后，我们不向刚刚客户端发来的1.3握手的连接传回数据

而是，从连接池中找到一个可用的客户端之前拨过的待命连接，直接向此连接发送握手数据。

所以呢，客户端就要保证，有一个 连接处于待命状态，此连接就是 ”特殊信道“。
当客户端收到了 特殊信道中发来的tls1.2连接的 server hello握手后，因为该serverhello握手被我们的特殊信道的外面的tls又加密了一层，所以是不怕暴露的，可以添加一些特殊命令，让客户端了解 该serverhello是客户端哪一个刚刚发起的clienthello的回应，客户端会重新再向 服务端拨号一个 tls1.2连接，然后通过特殊信道，把该新tls1.2连接的Random部分发送给代理服务器，因为Random是固定32字节的随机数，所以是可以用于分辨每一条连接的

于是客户端可以把Random和 之前serverhello传递给客户端的标识 一起通过特殊信道发送给代理服务端，然后代理服务端即可了解，现在客户端想要发起新tls1.2连接，然后开始准备接收特殊的tls1.2连接，只要收到符合Random的握手，就代表这个连接是要用于新的与刚才的服务器相吻合的连接

为何总是纠结要用tls1.2发送tls1.2，而不是1.3？因为tls1.2的alert是明文的，而tls1.3的是秘文的，如果不分开处理，审查者就会发现，这个tls1.3连接不对啊！握手是1.3，但是实际传的是1.2！这就是特征，也是xtls的一个大bug

不过，我上面的这个方法，需要在一些情况下，阅读每一个传来连接的Random字段，会消耗一定性能。

抑或是，之前通过特殊信道，与代理服务器先协商，哪些Random字段是专门用于重建tls1.2代理的，可以让服务端缓存一下。这样就不用每一次都需要通过特殊信道 同时协商Random了。而且我们服务端可以通过SNI来进一步匹配流量，即相同SNI+相同Random的tls1.2连接，被认为是我们客户端需要继续的 tls1.2连接，然后经过握手完成后，直接向这个tls1.2连接发送数据，然后关闭之前的tls1.3连接；抑或是，把之前的tls1.3连接放到连接池中，等待下一个连接发来。

然后要说明的是，Random不能重用，所以每次都要消耗一个Random。用完后，就需要用特殊信道 重新协商新的一组Random

总之，连接池技术已经迫在眉睫了，有必要实现！问题就在于，必需要复用连接，否则的话，“特殊信道”的流量特征也许很明显。而我们复用的话，可以采取一个 特殊指令，让某个特殊信道 降级，变成普通信道，然后重新拨号另一个特殊信道

这个新的“特殊信道”技术，恐怕不能在vless v0里实现了，还是要放到vless v1中。考虑到我的fullcone也是用到特殊信道，所以可以与之相配合

[e1732a364fed]

总之，就是说，使用应用层的特殊实现， 来协商绕过 tls传输层的 特征区别问题

这种使用相同tls发送相同tls流量的方法，可以很好地服务于我们的 tls lazy encrypt 的双向 splice 功能

因为只需要握手时判断好tls版本。后面也不会出现过滤任何tls record数据的情况，直接splice直连即可。

只要能够隐蔽好流量特征，避免了tls lazy encrypt的 可探测性的问题的话， tls lazy encrypt 就无敌了