而 ShadowTLS 则是完全独立脱离于 SSL 的混淆实现，数据流加密依赖于其他的代理协议，因此与 SSL 库无关，所以可以随意构造 SessionID。
正是 VLESS 协议的作者的不专业，既不理解其他协议的实现细节...
以下三段引用自 https://github.com/ihciah/shadow-tls/blob/master/docs/protocol-v3-zh.md
除此之外，我在这篇博客里也提到了一些针对数据封装的可能的劫持攻击，这也是 V3 协议必须解决的问题。
1. 能够防御流量特征检测、主动探测和流量劫持。
3. 尽可能地弱感知 TLS 协议本身，实现者无需 Hack TLS 库，更不需要自行实现 TLS 协议。
1. 客户端的 TLS Client 构造 ClientHello，ClientHello 需要生成自定义的 SessionID。
Ⅲ. 都不符合，此时可能流量已被劫持，需要继续握手（握手失败则作罢），并在握手成功后发送一个长度随机的 HTTP 请求（糊弄性请求），在读取完响应后正确关闭连接。
1. 流量劫持时，Server 会返回没有做 XOR 的数据，Client 会直接进入糊弄流程。
客户端负责 TLS 握手、切换并在切换后做数据封装和解封装。
客户端需要内置一个 TLS Client
1. 通过 TLS 库构造自定义 SessionID 并签名。
甚至成我“不专业，既不理解其他协议的实现细节”了，毕竟 Surge 是闭源的，你不说谁知道你家 ShadowTLS 一直都实现错了啊，正确实现为了防止 TLS Client Hello 被重定向到真正的网站，你需要用真的 TLS Client 而不是“但实际上shadowtls就只是个混淆，tls指纹是随意构造，无需魔改tls库的”，再说的确也没需要你大改啊，就连 ShadowTLS 作者都不认为自定义 Session ID 是个多大的修改
