[tor-dev] [Proposal for Arti] Add REALITY as an optional pluggable transport for Arti

pryty26 · June 19, 2026, 11:52am

Hi, dear developers and tor-dev

I have been following the development of Arti closely and would like to suggest a new and modern feature:
Adding support for the REALITY protocol as a optional new PT protocol in Arti.

I suggest REALITY as a new optional protocol, since REALITY unlike traditional PTs which rely on traffic obfuscation or domain fronting, REALITY borrows real TLS sessions from existing websites, which could be very useful for Tor users, who needs to bypass DPI.

Additionally, I would be willing to work on this new feature, if it’s acceptable to you. However, in my opinion, it could be implemented as an new PT plugin via tor-ptmgr, with corresponding configuration changes in arti-client.
I look forward to your feedback.

Best regards,
pryty26

···

Sent with Proton Mail secure email.
(pryty017@proton.me)

meskio · June 30, 2026, 3:47pm

Hello pryty,

I'm happy to hear you have interest in implementing a PT. This is great, we are
always looking for new ideas of PTs to be included.

REALITY is an interesting protocol, but there are few reports of issues with it
where it looks like is possible to fingerprint it and block it:

github.com/Anonymous376c1d0cf28/VLESS-cracker

2026-05-11-%E6%BC%8F%E6%B4%9E%E6%8A%A5%E5%91%8A%E6%AD%A3%E6%96%87.md

main

（由于社区一般完全使用VLESS协议指代VLESS/XTLS/REALITY/VISION等协议与特性，本文不再使用“R协议”指代，直接统称“VLESS协议”）

面对前文技术质疑，RPRX本人的公开回应不出所料：他继续堆砌大段逻辑漏洞百出的诡辩之词，避重就轻，企图在缺乏专业辨别能力的受众面前，强行营造出一场单方面的“精神胜利”。必须指出，**这种用造词话术掩盖技术缺陷、顾左右而言他的做派，恰是其面对实质性质疑时一贯的遮羞布**。对于没有足够技术背景的普通用户而言，这种极具欺骗性的安抚极难识破。

笔者已给足了时间，期盼他能恢复理性，正视安全隐患。然而事实证明，**RPRX 根本不在乎这几十万用户的节点是否会被精准识别，他唯一在乎的，是他那不容置疑的“教主”面子与虚荣心**。 他宁可让隐患继续潜伏，也没有流露出哪怕一丝私下接受漏洞报告的意愿。

很多用户并非技术专家，大家只是想要一个稳定的翻墙工具，却被长期以来“绝对安全”的营销话术绑架，沦为了满足某些人“野生密码学大师”幻想的小白鼠。笔者今日公开披露漏洞，**绝非针对广大无辜的使用者，而是为了在 GFW 收网之前强行击碎这个信息茧房，让大家认清自己正处于何种裸奔的危险之中，及时避险**。

更令人齿冷的是，面对笔者指出的伦理问题与社区生态毒化，RPRX置若罔闻，未见丝毫反思，更遑论悔过。至此，笔者试图唤醒其最后一丝理智的期冀，已被证明是水中捞月、痴人说梦。

坦白而言，即便是下达最终通牒之后，笔者亦曾几度踯躅：是否应当将漏洞细节移交至交由 gfw.report 等中立机构代为善后，以避免引发大范围恐慌？

然则，基于以下五点考量，笔者最终无奈选择了直接公开披露：

其一，海量VLESS协议的使用者，甚至包含其忠实粉丝群体，实则是被RPRX长期的营销话术与所谓“绝对安全”的神话所裹挟。正如本次的RPRX回应，**RPRX极其擅长用话术代替技术，颠倒黑白，若不直接展示该协议的致命缺陷，便无法击碎这层信息茧房，让大众真正认清其宣传的虚假本质**。

其二，该漏洞根植于VLESS协议的核心架构设计之中，**无法被彻底修正**。即使本文提供的PoC被针对性打上补丁，审查方依然能轻易通过其他变种技术手段实现同等探测。因此，该漏洞是私密提交还是公之于众，于其最终结果而言已无实质区别。

其三，漏洞从公开到审查系统实际部署尚存时间窗口。即使直接公开，VLESS协议用户也有足够的时间进行迁移。更为现实的是，即便私下通知维护者修补，任何具备逆向经验的安全人员皆可**从其修正性的commit中轻松反推出利用路径**。

This file has been truncated. show original

There are other more modern iterations of the same idea like TLSMirror that
might be more robust:

github.com/net4people/bbs

TLSMirror: Looks like TLS Censorship Resistant Transport Protocol is Looking for Developer Feedback

opened 07:48PM - 04 Jul 25 UTC

xiaokangwang

[TLSMirror](https://www.v2fly.org/en_US/v5/config/stream/tlsmirror.html) is a Lo…oks like TLS Censorship Resistant Transport Protocol. Its primary objective is create an connection between client and server that looks like a port forwarder or SNI proxy to a third party service. This allow users to deploy a looks like TLS proxy service without the need to acquire a domain name or TLS certificate, and make sure the connection looks like a connection to a well-known server name, rather than a domain name operated by service operator. Conceptually, TLSMirror is very similar to other looks like TLS protocols like [REALITY](https://github.com/XTLS/REALITY), [ShadowTLSv3](https://github.com/ihciah/shadow-tls/blob/master/docs/protocol-v3-en.md), [Restls](https://github.com/3andne/restls), [JLS](https://github.com/JimmyHuang454/JLS). However, it is designed to be a more user twistable protocol that allow users to adjust its protocol behavior freely, and by design resistant to packet length fingerprinting before and after handshake. While all other protocols mentioned above generate the carrier traffic or otherwise requires making change to the client hello of the carrier traffic. TLSMirror by design does not require any change to the client hello or server hello or otherwise any packet while the carrier connection is being handshake and setup. As a result, the carrier traffic can either come from the embedded traffic generator for more precise control, or even be externally generated from a web browser or even a external device like a smartphone, game console, IoT device or even a telescreen. During the entire transmission of payload traffic, the carrier traffic is not impacted at all, and continue to function. This means shape of traffic of the original connection is always preserved, and the content of the handshake message is never changed in anyway. This allows ALL client hello, server hello fingerprint or traffic shapes be used to carry proxy traffic, not just those can be generated by uTLS. By doing so, TLSMirror automatically has defense against [Aparecium](https://github.com/net4people/bbs/issues/481) or other post handshake length based detection, and the embedded traffic generator will consistently generate programmable and probabilistically generated traffic get get mixed with payload traffic, making it very difficult to discriminate TLSMirror traffic based on its shape, as the traffic is always bit-identical to the original traffic until it is ready for payload traffic. Additionally, TLSMirror is designed to work with TLS1.2 traffic(including AEAD with explicit nonce), and avoided the pitfall of many websites disabling TLS1.3 support to avoid being used as a forwarding site. The explicit nonce issue for TLS1.2 AEAD ciphers has been specifically addressed, and visible nonce fields are automatically adjusted when configured to do so. The design of TLSMirror is rather simple: it will forward the carrier traffic as is to the destination server without modify its content, until the connection is ready for payloads. Once the connection is ready for payloads, the tlsmirror client and servers will insert application data frames to the TLS connection with a different TLSMirror transport key than the original client, and remove any application data frame, whose content can be decrypted with tlsmirror transport key. The data from successful decryption are then forwarded to application as payload traffic. Currently this protocol is still incomplete with enrollment confirmation(confirm connection is not redirected to forwarded site via a external channel), traffic shaping, and external traffic generator connection ready signaling(wait sometime or packets before using externally generated carrier connection), and traffic generator gracefully recall not implemented. However, it is currently seeking developer feedback about bugs and weakness of its protocol design while it is still being developed. Please compile from the primary branch of [v2ray-core](https://github.com/v2fly/v2ray-core) directly to try it.

Anyway, if you get to implement any of them let me give you some pointers on how
to implement pluggable transports. For not PTs are not libraries of arti but
standalone programs that arti/c-tor talks to using the pt protocol[0]. Most PTs
currently are written in go and use goptlib to communicate with arti:

But you can get some inspriation on proteus, an experimental PT written in rust:

Specifically their implementation of the pt spec:

github.com/unblockable/proteus

src/cli/pt/control.rs

3bc360aef

use std::net::SocketAddr;

#[derive(Debug)]
#[allow(dead_code)]
pub enum PtLogLevel {
    Error,
    Warning,
    Notice,
    Info,
    Debug,
}

pub enum Message<'a> {
    Version,
    VersionError,
    EnvError(&'a str),
    _ProxyDone, // Connecting through upstream proxy unimplemented
    ProxyError(&'a str),
    ClientReady(SocketAddr),
    ClientError(&'a str),

This file has been truncated. show original

Feel free to come to the anti-censorship matrix/irc channel or our mailing list
if you have questions:

Happy hacking.

[0] Pluggable Transport Specification (Version 1) - Tor Specifications

Quoting pryty via tor-dev (2026-06-19 13:52:05)

···

Hi, dear developers and tor-dev

I have been following the development of Arti closely and would like to suggest a new and modern feature:
Adding support for the REALITY protocol as a optional new PT protocol in Arti.

I suggest REALITY as a new optional protocol, since REALITY unlike traditional PTs which rely on traffic obfuscation or domain fronting, REALITY borrows real TLS sessions from existing websites, which could be very useful for Tor users, who needs to bypass DPI.

Additionally, I would be willing to work on this new feature, if it's acceptable to you. However, in my opinion, it could be implemented as an new PT plugin via tor-ptmgr, with corresponding configuration changes in arti-client.
I look forward to your feedback.

Best regards,pryty26
---

Sent with [Proton Mail](Redirecting to: /mail) secure email.
(pryty017@proton.me)

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
_______________________________________________
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-leave@lists.torproject.org