Description
English
A new proof-of-concept tool named Aparecium has been released, designed to detect TLS camouflage protocols, specifically ShadowTLS v3 and REALITY. The tool exploits discrepancies in the handling of TLS 1.3 post-handshake messages, particularly the NewSessionTicket message.
Link to Aparecium: https://github.com/ban6cat6/aparecium
Overview of Detection Method
Aparecium identifies these protocols by observing that they do not correctly mimic or relay NewSessionTicket messages as a standard TLS 1.3 server (especially one based on OpenSSL) would after the ClientFinished message.
- Standard TLS 1.3 (OpenSSL-based): Typically sends one or two
NewSessionTicketmessages after receivingClientFinished. - REALITY & ShadowTLS v3 Behavior: These protocols (when mimicking OpenSSL-based servers) reportedly fail to relay or generate these post-handshake
NewSessionTicketmessages, or do so incorrectly. - Aparecium's Exploitation:
- Phase 1 (ClientHello Fingerprinting): It establishes a TLS session, records the lengths of any
NewSessionTicketmessages received (expecting specific lengths for OpenSSL). If none are received, it may assume a legitimate server that doesn't send them (e.g., Google). - Phase 2 (NewSessionTicket Analysis): It monitors messages after
ServerFinished. If the subsequent messages do not match theNewSessionTicketlengths recorded in Phase 1 (for servers that should send them), it flags the connection as likely using a camouflage protocol.
- Phase 1 (ClientHello Fingerprinting): It establishes a TLS session, records the lengths of any
Specific Vulnerabilities Highlighted by Aparecium
-
REALITY:
- Vulnerability: Fails to send
NewSessionTicketmessages afterClientFinishedwhen mimicking OpenSSL servers. - Proposed Mitigation by Aparecium Author:
- Delay sending
NewSessionTicketmessages until after receivingClientFinished. - Actively probe the target server to capture its
NewSessionTicketmessage lengths. - Send fake, padded
NewSessionTicketmessages matching the target's lengths.
- Delay sending
- Vulnerability: Fails to send
-
ShadowTLS v3:
- Vulnerability 1: Same
NewSessionTicketissue as REALITY. - Vulnerability 2 (Critical): The HMAC(PSK) tainting adds 4 bytes to handshake messages (e.g.,
ServerFinishedbecomes 57 or 73 bytes instead of the standard 53 or 69 bytes). This creates a strong, easily detectable signature. - Aparecium Author's Conclusion: ShadowTLS v3 is declared "dead" due to the HMAC(PSK) length-altering design flaw.
- Proposed Mitigation by Aparecium Author:
- Remove or modify the HMAC mechanism to avoid length discrepancies.
- Mimic OpenSSL’s post-handshake behavior by sending fake
NewSessionTicketmessages afterClientFinished.
- Vulnerability 1: Same
Exception
The detection method is less effective if REALITY/ShadowTLS mimics servers (like Google's) that legitimately do not send NewSessionTicket messages.
Request to Developers
We kindly request the Xray-core developers to:
- Investigate the claims and detection methods presented by the Aparecium tool.
- Evaluate the potential impact on REALITY and ShadowTLS v3 users.
- Consider implementing or recommending mitigations to address these detection vectors, particularly for REALITY.
Thank you for your attention to this matter.
中文 (Chinese)
[安全警报] 新工具 "Aparecium" 通过分析 TLS 1.3 握手后消息检测 REALITY 和 ShadowTLS v3
一款名为 Aparecium 的新型概念验证工具已被发布，旨在检测 TLS 伪装协议，特别是 ShadowTLS v3 和 REALITY。该工具利用了这些协议在处理 TLS 1.3 握手后消息（尤其是 NewSessionTicket 消息）方面的差异。
Aparecium 工具链接： https://github.com/ban6cat6/aparecium
检测方法概述
Aparecium 通过观察这些协议未能像标准 TLS 1.3 服务器（特别是基于 OpenSSL 的服务器）在收到 ClientFinished 消息后那样正确模拟或中继 NewSessionTicket 消息来识别它们。
- 标准 TLS 1.3 (基于 OpenSSL)： 通常在收到
ClientFinished后发送一或两条NewSessionTicket消息。 - REALITY 和 ShadowTLS v3 的行为： 据报告，这些协议（在模拟基于 OpenSSL 的服务器时）未能中继或生成这些握手后的
NewSessionTicket消息，或者处理不当。 - Aparecium 的利用方式：
- 阶段 1 (ClientHello 指纹识别)： 建立 TLS会话，记录收到的任何
NewSessionTicket消息的长度（期望 OpenSSL 服务器具有特定长度）。如果没有收到，则可能假定为不发送这些消息的合法服务器（例如 Google）。 - 阶段 2 (NewSessionTicket 分析)： 监控
ServerFinished之后的消息。如果后续消息的长度与阶段 1 中记录的NewSessionTicket长度不符（针对那些应该发送它们的服务器），则将连接标记为可能使用伪装协议。
- 阶段 1 (ClientHello 指纹识别)： 建立 TLS会话，记录收到的任何
Aparecium 指出的具体漏洞
-
REALITY:
- 漏洞： 在模拟 OpenSSL 服务器时，未能在
ClientFinished之后发送NewSessionTicket消息。 - Aparecium 作者建议的缓解措施：
- 延迟发送
NewSessionTicket消息，直到收到ClientFinished之后。 - 主动探测目标服务器以捕获其
NewSessionTicket消息的长度。 - 发送与目标长度匹配的伪造、填充过的
NewSessionTicket消息。
- 延迟发送
- 漏洞： 在模拟 OpenSSL 服务器时，未能在
-
ShadowTLS v3:
- 漏洞 1： 与 REALITY 相同的
NewSessionTicket问题。 - 漏洞 2 (严重)： HMAC(PSK) 标记会给握手消息增加 4 个字节（例如，
ServerFinished从标准的 53 或 69 字节变为 57 或 73 字节）。这产生了一个强大且易于检测的特征。 - Aparecium 作者的结论： 由于 HMAC(PSK) 改变长度的设计缺陷，ShadowTLS v3 被宣告“死亡”。
- Aparecium 作者建议的缓解措施：
- 移除或修改 HMAC 机制以避免长度差异。
- 在
ClientFinished之后发送伪造的NewSessionTicket消息，以模仿 OpenSSL 的握手后行为。
- 漏洞 1： 与 REALITY 相同的
例外情况
如果 REALITY/ShadowTLS 模仿那些本身就不发送 NewSessionTicket 消息的服务器（如 Google 的服务器），此检测方法的有效性会降低。
向开发者请求
我们恳请 Xray-core 开发者：
- 调查 Aparecium 工具提出的声明和检测方法。
- 评估其对 REALITY 和 ShadowTLS v3用户的潜在影响。
- 考虑实施或推荐缓解措施，以应对这些检测向量，特别是针对 REALITY。
感谢您对此事的关注。