Off-Topic Discussion: Detectability of ShadowTLS v1

[gaukas]

Hi @3andne, decent work on Restls, the design looks promising and I'd love to give it a deeper look.

This could be off-topic and outdated, possibly should be put in Discussion instead of Issues. Please feel free to close the issue if you are not interested.

Our paper has been accepted by Free and Open Communications on the Internet FOCI'23: Chasing Shadows: A security analysis of the ShadowTLS proxy. The paper is revealing attacks that could effectively identify a ShadowTLS v1 server setup. Some of the mentioned problems were fixed in v2 but not all of them. You may want to pay extra attention to these vulnerabilities when implementing a TLS/FakeTLS server. It is a shame we couldn't make it public earlier due to the anonymity issue.

I will be willing to discuss more on detection vulnerabilities.

Thanks.

[3andne]

Hi @gaukas, I wouldn't say this is off-topic. Thanks for letting me know about your paper and I'll take a look at it later. Any discussion regarding vulnerabilities in a TCP-TLS based proxy is appreciated and would benefit me as well as the community.

[RPRX]

我认为 ShadowTLS v1 犯的很多错误完全是可以避免的，包括 ShadowTLS v2 仍未加入对服务端的验证，而后者并不难做到。

[gaukas]

我认为 ShadowTLS v1 犯的很多错误完全是可以避免的，包括 ShadowTLS v2 仍未加入对服务端的验证，而后者并不难做到。 I think many of the mistakes made by ShadowTLS v1 are entirely avoidable, including that ShadowTLS v2 still doesn't include server-side verification, which is not difficult to do.

I agree, @RPRX. Unfortunately, ShadowTLS authenticates its client too late in the handshake (only when it finishes) and via a destructive method which breaks a "legit" TLS connection.

And if my understanding is correct, that's exactly what Restls has offered to improve. With a very early ClientVerification in the ClientHello message with a non-destructive manner, it allows the client to verify the server before the handshake ends.

---

我同意，@RPRX。不幸的是，ShadowTLS在握手过程中对客户端的认证太晚了（只有在握手结束后），而且是通过一种破坏性的方法，破坏了 "合法 "的TLS连接。

而如果我的理解是正确的，这正是Restls提供的改进。通过在ClientHello消息中以非破坏性的方式提供一个非常早期的ClientVerification，它允许客户端在握手结束前验证服务器。

[RPRX]

尽管 ShadowTLS 和 Restls 名字都包含“TLS”，它们都不是真正的 TLS，它们使用对称密钥且缺乏最基本的前向保密性。

ShadowTLS 存在的问题并不止“在握手过程中对客户端的认证太晚了”这一条。其实早在 2021 年 1 月，我就想到了向中间人呈现对另一个域名的握手，也就是“使用另一个域名的证书”，可以查看以下消息：

https://t.me/projectXray/195894 https://t.me/projectXray/195950 https://t.me/projectXray/195966 https://t.me/projectXray/195988

当时因为一些事情，我并没有实现它们，并且“消失”了。所以一年多后，当想法一样的 ShadowTLS 出现时，我很有兴趣地查看了它的设计，然而和我想象的设计相比，只能说它过于原始、漏洞百出，一部分漏洞在 @gaukas 的论文中也有提及。遗憾的是，其 v2 版本也只是进步了一小步，甚至还是没有加上对服务端的认证。还有太多问题，甚至很难列举完。

Restls 尝试改进 ShadowTLS，但仍受其实现思路的局限较大，并没有改进多少。它相对于 ShadowTLS v2 主要改进了两处，一是选择对 Client Hello 的 key_share 等信息进行 hmac 并把结果填充至一半 Session ID，这是进步，但相对于 REALITY 已经做的，远远不够。二是提供了客户端对服务端的验证 —— 以一种不完美的方式。甚至，之后还需要多余的“客户端二次认证”。

REALITY 协议是于上个月完成设计的，它的代码和文章会于近期放出，我相信你们会很有兴趣查看。

CC @ihciah @3andne @gaukas

[gaukas]

Looking forward to it!

[CoiaPrant233]

尽管 ShadowTLS 和 Restls 名字都包含“TLS”，它们都不是真正的 TLS，它们使用对称密钥且缺乏最基本的前向保密性。

ShadowTLS 存在的问题并不止“在握手过程中对客户端的认证太晚了”这一条。其实早在 2021 年 1 月，我就想到了向中间人呈现对另一个域名的握手，也就是“使用另一个域名的证书”，可以查看以下消息：

https://t.me/projectXray/195894 https://t.me/projectXray/195950 https://t.me/projectXray/195966 https://t.me/projectXray/195988

当时因为一些事情，我并没有实现它们，并且“消失”了。所以一年多后，当想法一样的 ShadowTLS 出现时，我很有兴趣地查看了它的设计，然而和我想象的设计相比，只能说它过于原始、漏洞百出，一部分漏洞在 @gaukas 的论文中也有提及。遗憾的是，其 v2 版本也只是进步了一小步，甚至还是没有加上对服务端的认证。还有太多问题，甚至很难列举完。

Restls 尝试改进 ShadowTLS，但仍受其实现思路的局限较大，并没有改进多少。它相对于 ShadowTLS v2 主要改进了两处，一是选择对 Client Hello 的 key_share 等信息进行 hmac 并把结果填充至一半 Session ID，这是进步，但相对于 REALITY 已经做的，远远不够。二是提供了客户端对服务端的验证 —— 以一种不完美的方式。甚至，之后还需要多余的“客户端二次认证”。

REALITY 协议是于上个月完成设计的，它的代码和文章会于近期放出，我相信你们会很有兴趣查看。

CC @ihciah @3andne @gaukas

This is the case. I have reviewed your protocol code. Your protocol design is that the server and the client predefine a password (private key), and then carry out HKDF transfer authentication. If the authentication can be passed, a self-signed certificate will be generated. If not, it will fall back to the real server. Is this the case?

[CoiaPrant233]

If so, my previous closed-source project protocol design was like this, but more like the authentication implementation of Telegram MTProxy FakeTLS, which I modified using utls as a template. This design is not a big problem at present, but the characteristics and ShadowTLS v2 are completely opposite. My new protocol will work entirely with true certificates and true TLS.

[CoiaPrant233]

All camouflage is in vain, just as the parrot is dead. It would be a terrible amount of work to implement those fine details entirely using FakeTLS.

Here is a quote from three body to sound the alarm for your theoretical safety.

弱小和无知不是生存的障碍，傲慢才是。

In fact, the PoC of shadow TLS I mentioned will not be implemented to a large extent, because there is a simpler way to verify the authenticity of the server, which I will not say much.

[CoiaPrant233]

Including Xray's once-popular failback feature, which now seems to be a temporary solution, this feature can be said to be insignificant, and time will prove everything. When you look back now, you may find that what you were doing was stupid. Of course, these are not important, for those open source workers who are willing to contribute, people and the Internet will remember them.

[CoiaPrant233]

If I can get some money, then I will provide a lot of new methods and insights, but unfortunately this circle and community can not, so I can not disclose so much, because I can not tell all my business secrets, sorry.

[RPRX]

a password

错，是一对用于 X25519 密钥交换的密钥对，客户端会先拿自身的私钥与它的公钥生成一个新的密钥，然后是 hKDF + AEAD。

true certificates

这是错误的做法 https://github.com/XTLS/Xray-core/issues/1588#issuecomment-1415861613 ，其次，它没必要是公共 CA 签的证书，REALITY 用临时认证密钥对临时证书公钥进行签名，已经足以让客户端区分它是 REALITY 服务端、持有有效证书的服务端，还是持有无效证书的服务端，进而做出响应。

true TLS

REALITY 就是 TLS，请你指出它哪里不“真实”。

All camouflage is in vain, just as the parrot is dead.

注意，我说的是 REALITY 是相对于现有这些方案更好的方案，而不是一个完美的解决方案，REALITY 有两种用法，一种是服务端就是自己的，另一种是模仿另一个域名的响应，对于后者，它还是有很多已知问题和 TODO，或已知但不会解决的问题，这些都会在我的文章中提及。我的文章放出来前不开 issue 区，就是因为肯定会有你这种自以为是的错误解读加一顿输出，浪费我时间。

because there is a simpler way to verify the authenticity of the server, which I will not say much.

不如我直接给你说一个杀手锏：去和真实的服务器拿到 TLS session，从而判定这些服务器只是转发。

不要以为你很聪明，你能想到的问题其他人也能想到，甚至比你想得更早、想得更多，只是没说出来。正如两年前我提出要偷另一个域名的证书时，我们内部群就已经想到了 重定向攻击 等攻击模式并且进行了探讨，你不会真的以为只有你想到了吧？

Including Xray's once-popular failback feature, which now seems to be a temporary solution, this feature can be said to be insignificant, and time will prove everything. When you look back now, you may find that what you were doing was stupid.

看到你这句话时直接笑出来了。实际上，它有哪些弱点我们从第一天开始就一清二楚，只是 GFW 暂时没针对，所以它是一个比其它回落更好的可用方案，仅此。你不会真的以为我们都不知道吧？

我说过，两年前我就想出了 N 种方法把 FQ 流量精准封死，其中很多方法与你用什么协议根本无关。 任何解决方案都不是银弹，只是暂时没被 GFW 拿来封锁所以可用，苟且偷生，仅此而已。

If I can get some money, then I will provide a lot of new methods and insights, but unfortunately this circle and community can not, so I can not disclose so much, because I can not tell all my business secrets, sorry.

Business secrets？别，千万别。你可以看到，我从第一天开始就没收过一分钱赞助，也不像其他很多开发者一样是实名，因为我不需要靠这个领域的任何事情来赚钱、赚名声，甚至你们可能永远都不会知道现实世界中我是哪位。

即使这样，我仍愿意匿名、无偿为这个领域做贡献，只是因为我单纯希望人们有可用的渠道去自由地获取、发布信息。人们应当有这些自由，这是我的信念，也是基本人权，且恰好我的能力可及，所以我愿意牺牲一些自己的时间与利益来做这些事。

弱小和无知不是生存的障碍，傲慢才是。

？？上个月我用极短的时间就写好了 REALITY 的核心代码，对我而言，它就是一个比现有其它方案更好的玩具而已，而且我非常清楚地知道它有哪些弱点，有些是 TODO 有些 Won't fix。如果你有更好玩的玩具，我非常欢迎你也拿出来让大家玩玩。所以恰恰相反，我既不弱小，也不无知，更不需要靠这些玩具来生存，反倒是你，还拿这些东西当 business secrets，我可以理解为“生存”吧？真的是弱爆了，就这还能摆出一副居高临下的傲慢姿态，却不知道只是自己无知罢了。我真心建议你，用这句话好好比对下自己。

[CoiaPrant233]

I'm afraid you don't know what's wrong with this.

Second, I don't think you're doing anything wrong, just a reminder that you're fixated on theoretical security, undecidable servers, and ignoring too many details.

The middleman may not need to decrypt the PoC I mentioned, and through some implementation details, he can judge the authenticity of the server.

The middleman doesn't need to know what server you are, and he doesn't need to know at all. He just needs to know that you are running agent activities, and that's enough.

[CoiaPrant233]

I have thought about your idea a long time ago, and I can give you a few abandoned drafts for your reference.

1.Modify the TLS handshake, Let the certificate go through the motions and not participate in the encryption process, or even use the password directly as the TLS key

2. Similar to MTProto's FakeTLS, but implements full TLS handshake

Of course, these are the old drafts of my current agreement, and these have a lot of known problems that can't be solved. As shadow TLS v2, I said

I'm glad you can share this, but please put down your arrogant attitude, everyone has their own different opinions, this is not the place to quarrel.

[CoiaPrant233]

The protocol design of REALITY has been in my mind for a long time. This is the idea when I first tried to change mtproxy faketls. This is more dangerous than restls, because it doesn't need a complicated process at all. I just need to passively intercept a data packet and modify what's inside to complete the judgment. The design of your protocol, from my point of view as a middleman, is too fake.

Let me give you an example.

This is a program where he can enter two arbitrary numbers, a and b, including random ones. When I input the same a and b, he always outputs c But proxy servers are not like that. After the proxy server authenticates the client, if it is a client, it will not output C, but will output another value D. That's it. The same program, the same input, the same output

Take the current design much like Telegram Mtproxy's FakeTLS adoption to the authentication process. If you are interested, you can look through the MTG to the source code.

As for your statement that you do not receive sponsorship, it is true that you may have a regular job, get a regular income every month, and have no worries about food and clothing. But not everyone is like this. I'm still a student. I need to plan for my future. I think you have some over-understanding.

Finally, a word of advice.

成于细节，也败于细节。

[CoiaPrant233]

GFW does not have the ability to completely block proxy traffic

Humans have been killing bugs, but they've never really been killed.

[CoiaPrant233]

My initial design is two plans. The server first verifies the identity of the client, and after the authentication is passed

1.The server sends its own CA, and the client verifies whether the CA is a true server or a redirect server

2.The client and the server use the same modified encryption algorithm, and the client prepares two ciphers to try to decrypt the server's data

Both of these schemes are possible in TLS 1.3, and both allow mutual authentication between the client and the server, but these drafts have been abandoned

As I said just now, he doesn't conform to the theory that a + b = c

[CoiaPrant233]

It's true that restls is a better thing than shadow TLS, but it's also a terrible amount of work if you have to deal with a lot of detail

If the advantages of REALITY and restls can be combined, it will be a kill, and my new agreement is intended to be like this.

[RPRX]

我这么给你说吧，你对 REALITY 的目标理解错了，而这种错误理解，来源于你的视角的低维，与无知，这部分内容我有空时回复。

但是既然你提到了协议设计，为了防止你误解了 REALITY 服务端的代码，不如你详细描述下 REALITY 服务端是如何工作的？

[CoiaPrant233]

我这么给你说吧，你对 REALITY 的目标理解错了，而这种错误理解，来源于你的视角的低维，与无知，这部分内容我有空时回复。

但是既然你提到了协议设计，为了防止你误解了 REALITY 服务端的代码，不如你详细描述下 REALITY 服务端是如何工作的？

Why don't you just talk about protocol design and avoid detours?

[CoiaPrant233]

I'm looking forward to your work. Let's talk about the protocol design first?

[CoiaPrant233]

But there are some details, not what you do with TLS, but things beyond that, that you should release yourself from the busy development and think about other factors.

[RPRX]

我这边要关心的事情很多，本来 REALITY 上个月就可以放出，但是因为我要花时间去处理、准备 Xray-core 的种种事情，拖慢了我的进度，直到几天前时机成熟我才公布了 REALITY 服务端的代码，现在正打算公布客户端的代码，文章尚未完成，这都需要时间。

所以我的意思是，在这里我没有太多时间与你单独谈论，你太着急了，很多问题你看了文章后自然会明白。就是因为可能会有很多着急的人开 issue 导致我需要花时间单独回复、拖慢我的进度，所以 REALITY 现在没开 issue 区，有任何问题，等看完文章再说。

但是我看了你的发言，感觉你可能误解了 REALITY 服务端的代码，所以让你先描述一下，我看正不正确。

[CoiaPrant233]

我这边要关心的事情很多，本来 REALITY 上个月就可以放出，但是因为我要花时间去处理、准备 Xray-core 的种种事情，拖慢了我的进度，直到几天前时机成熟我才公布了 REALITY 服务端的代码，现在正打算公布客户端的代码，文章尚未完成，这都需要时间。

所以我的意思是，在这里我没有太多时间与你单独谈论，你太着急了，很多问题你看了文章后自然会明白。就是因为可能会有很多着急的人开 issue 导致我需要花时间单独回复、拖慢我的进度，所以 REALITY 现在没开 issue 区，有任何问题，等看完文章再说。

但是我看了你的发言，感觉你可能误解了 REALITY 服务端的代码，所以让你先描述一下，我看正不正确。

好的，不过请你先放下你自己个人的看法，就事论事

我大概看了一下你的服务端代码

得出的结论大概是这样子

通过私钥+公钥，进行HKDF来验证客户端真伪，如果不是客户端，failback到真服务器

如果是客户端 进行握手，生成临时自签名证书，然后协商加密

我的协议和你这个类似，不过认证采用Telegram MTProto的那套ClientHello认证方案，然后进行正常TLS握手

至于怎么协商加密的，我并不关心，我只需要大概思路就ok了

[CoiaPrant233]

至于我前文所说的真TLS和真证书，但是你忽略了一点，就是SNI并不是我拥有的，相当于偷证书。具体怎么实现不便透露。

[CoiaPrant233]

同一个TLS ClientHello，如果只改变key share内的公钥，他返回的数据包大小应该都是相同的。这就是我前文所说的 a+b=c，很显然，自签名证书和自己生成的ServerHello以及后续握手条件，数据包大小是很难控制的，可能要做很多改动，这就是为什么这个方案我放弃了。虽然我现在确实是这个设计，目前来说可能够用，但是潜在的风险比restls大。我现在的原则就是以少改动来实现最全功能的 REAL TLS

[CoiaPrant233]

restls的xor是一个很好的解决方法，因为他并不会造成数据包大小更改，但是其他细节的实现难度，我很早放弃了这种方案，因为这样子做不值，不如用真的TLS来实现。

[RPRX]

同一个TLS ClientHello，如果只改变key share内的公钥，他返回的数据包大小应该都是相同的。这就是我前文所说的 a+b=c，很显然，自签名证书和自己生成的ServerHello以及后续握手条件，数据包大小是很难控制的，可能要做很多改动，这就是为什么这个方案我放弃了。虽然我现在确实是这个设计，目前来说可能够用，但是潜在的风险比restls大。我现在的原则就是以少改动来实现最全功能的 REAL TLS

仅针对这个问题，你知道 TLSv1.3 有 padding 吧？REALITY 的服务端会把每个包都 padding 到和目标服务端一样的长度。

[CoiaPrant233]

等我新的协议设计完成以后，我会公开现有协议的部分设计，包括一些很多人可能没有考虑到的问题。

[RPRX]

Check https://github.com/XTLS/REALITY/blob/e814936a3d99b652351fbae87d6e3b1e5192cf47/conn.go#L525

[CoiaPrant233]

同一个TLS ClientHello，如果只改变key share内的公钥，他返回的数据包大小应该都是相同的。这就是我前文所说的 a+b=c，很显然，自签名证书和自己生成的ServerHello以及后续握手条件，数据包大小是很难控制的，可能要做很多改动，这就是为什么这个方案我放弃了。虽然我现在确实是这个设计，目前来说可能够用，但是潜在的风险比restls大。我现在的原则就是以少改动来实现最全功能的 REAL TLS

仅针对这个问题，你知道 TLSv1.3 有 padding 吧？REALITY 的服务端会把每个包都 padding 到和目标服务端一样的长度。

是的，我知道，但是会存在一个可能，源服务器证书比自签名的小。这个更难处理。我使用我自签名的CA来操作，这样子还是会有很多问题。所以我新的协议设计不再自己签名证书了

[RPRX]

源服务器证书比自签名的小

这种情况不会出现，REALITY 是 Ed25519 证书，其次，哪个服务端，是我们决定的

[RPRX]

我可以给你多说一点，REALITY 的 Ed22519 证书是最小的，是因为它只含 Ed25519 的公钥和签名而不含其它信息，这保证了即使是另一个使用 Ed25519 证书的服务端也会至少比 REALITY 的大，所以仅你提到的数据包长度来说，REALITY 已经解决了该问题。

[CoiaPrant233]

我可以给你多说一点，REALITY 的 Ed22519 证书是最小的，是因为它只含 Ed25519 的公钥和签名而不含其它信息，这保证了即使是另一个使用 Ed25519 证书的服务端也会至少比 REALITY 的大，所以仅你提到的数据包长度来说，REALITY 已经解决了该问题。

好的，我再看看，然后给你答复

[RPRX]

首先，REALITY 从一开始就是双向转发流量，并且用的是别人的 Server Hello 而不是自己生成的，只是把其中 key_share 换成了自己的，并且选择和源服务器一样的加密套件。其次，REALITY 会记录 Server Hello 后续包的长度，以便 padding 自己至相同长度。

Check https://github.com/XTLS/REALITY/blob/e814936a3d99b652351fbae87d6e3b1e5192cf47/tls.go#L308

[RPRX]

通过私钥+公钥，进行HKDF来验证客户端真伪

我需要纠正一下，hKDF 只是派生密钥，验证客户端真伪的是 AEAD，加密的是版本号、时间戳、ShortId，附加数据为整个握手。

[CoiaPrant233]

通过私钥+公钥，进行HKDF来验证客户端真伪

我需要纠正一下，hKDF 只是派生密钥，验证客户端真伪的是 AEAD，加密的是版本号、时间戳、ShortId，附加数据为整个握手。

好的，谢谢你的答疑，我会重新分析一下源代码的。

[RPRX]

很显然，自签名证书和自己生成的ServerHello以及后续握手条件，数据包大小是很难控制的

所以我说感觉你没看懂 REALITY，REALITY 根本不自己生成 Server Hello，而数据包大小用 padding 就可以控制。

[CoiaPrant233]

很显然，自签名证书和自己生成的ServerHello以及后续握手条件，数据包大小是很难控制的

所以我说感觉你没看懂 REALITY，REALITY 根本不自己生成 Server Hello，而数据包大小用 padding 就可以控制。

昨天只是大概看了下，现在看来确实没有什么明显的问题，期待上线后实际测试看看

[CoiaPrant233]

希望不会出现padding为负的问题，祝你好运。

[CoiaPrant233]

等你正式发布可以通知我一下，我给你提几个逻辑之外的问题，包括MTProxy FakeTLS, Shadow TLS和restls都存在的问题

[CoiaPrant233]

你这个设计很好，不过我的新协议是另外一个方案，效果和你相同。

不过这样子的话 包括全部这种类似设计的协议 都会造成类似CC的TLS握手攻击，对源服务器可能会是一种滥用，但是没办法解决。

连接数越高攻击数也越高，这是正比

[RPRX]

昨天只是大概看了下，现在看来确实没有什么明显的问题，期待上线后实际测试看看

所以我说浪费我的时间

REALITY 只是比其它解决方案更好，但也不是完全没问题，因为还有些细节要处理（TODO），但就算这些细节处理完美了，这不还有个核弹级三体问题 Won't fix 嘛：去和真实的服务器拿到 TLS session，从而判定这些服务器只是转发。

希望不会出现padding为负的问题，祝你好运。

不会，即使真出现了，换服务端就行了，若是其它原因，针对性处理即可，就像我说的：TODO

等你正式发布可以通知我一下，我给你提几个逻辑之外的问题，包括MTProxy FakeTLS, Shadow TLS和restls都存在的问题

就像我说的，你能想到的，我基本上都想到了，只是还没说出来，另外，尝试在文章中把所有已知问题都列出来是有点累的

你这个设计很好，不过我的新协议是另外一个方案，效果和你相同。

如果你的协议真的是用的公共 CA 证书，讲真，安全性不如 REALITY，REALITY 只用自签证书是有原因的，具体原因上面发了。 另外，我想你的协议解决不了上面我说的核弹级三体问题。

不过这样子的话 包括全部这种类似设计的协议 都会造成类似CC的TLS握手攻击，对源服务器可能会是一种滥用，但是没办法解决。

可以解决，REALITY 会出基于客户端指纹的预先构建模式，从而不用回源（尤其是源在国内时）。当然，这会牺牲一些实时性。

[CoiaPrant233]

昨天只是大概看了下，现在看来确实没有什么明显的问题，期待上线后实际测试看看

~所以我说浪费我的时间~

REALITY 只是比其它解决方案更好，但也不是完全没问题，因为还有些细节要处理（TODO），但就算这些细节处理完美了，这不还有个核弹级三体问题 Won't fix 嘛：去和真实的服务器拿到 TLS session，从而判定这些服务器只是转发。

希望不会出现padding为负的问题，祝你好运。

不会，即使真出现了，换服务端就行了，若是其它原因，针对性处理即可，就像我说的：TODO

等你正式发布可以通知我一下，我给你提几个逻辑之外的问题，包括MTProxy FakeTLS, Shadow TLS和restls都存在的问题

就像我说的，你能想到的，我基本上都想到了，只是还没说出来，~另外，尝试在文章中把所有已知问题都列出来是有点累的~

你这个设计很好，不过我的新协议是另外一个方案，效果和你相同。

如果你的协议真的是用的公共 CA 证书，讲真，安全性不如 REALITY，REALITY 只用自签证书是有原因的，具体原因上面发了。 另外，我想你的协议解决不了上面我说的核弹级三体问题。

不过这样子的话 包括全部这种类似设计的协议 都会造成类似CC的TLS握手攻击，对源服务器可能会是一种滥用，但是没办法解决。

可以解决，REALITY 会出基于客户端指纹的预先构建模式，从而不用回源（尤其是源在国内时）。当然，这会牺牲一些实时性。

不，我可以用任意存在的sni，然后使用真实证书和正常握手走完整个TLS流程，在外面看来，和正常的TLS握手没有不同。这个应该是目前最完善的方法了。

[CoiaPrant233]

你可以理解为，我真的偷到了别人证书去做TLS。 差不多就是这样子

[RPRX]

不如你说清楚点，以便我帮你找找 BUG

[CoiaPrant233]

我刚才拿wireshark随便抓了几个不同sni的包 可能最后的问题在new session ticket那边，有的服务器new session ticket包只有50，有的服务器有200+

当然我没控制变量，可能实际上不会出现这个

[CoiaPrant233]

~不如你说清楚点，以便我帮你找找 BUG~

~不了，实名上网怕被抓~

[RPRX]

我刚才拿wireshark随便抓了几个不同sni的包 可能最后的问题在new session ticket那边，有的服务器new session ticket包只有50，有的服务器有200+

这是在说哪个问题？padding 的话，你可以看下 REALITY 的代码。另外，其实我更建议去用那些后面所有包一起加密的服务端。

[CoiaPrant233]

我刚才拿wireshark随便抓了几个不同sni的包 可能最后的问题在new session ticket那边，有的服务器new session ticket包只有50，有的服务器有200+

这是在说哪个问题？padding 的话，你可以看下 REALITY 的代码。另外，其实我更建议去用那些后面所有包一起加密的服务端。

其实，你可以直接参考Telegram MTProto FakeTLS的认证方案，然后把加密协商用ClientHello和ServerHello到key share直接计算出来，剩下的证书和签名直接填充就行了，不用发有效数据，给中间人表演一下就行。

[CoiaPrant233]

这样子也许是更好的解决方法，当然前提是TLS 1.3