[Proposal] mimicry-pt: An LSTM-based Pluggable Transport mimicking YouTube/game site traffic

[silentwaves]

Hello everyone,

I am currently developing a new Pluggable Transport called mimicry-pt.

Motivation and Background:

Modern censorship systems like the Great Firewall (GFW) identify and block such “randomized” traffic in real time. Simply “making nothing visible” is not an effective strategy for circumventing sophisticated and persistent censorship.
(Reference: How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic )
I believe the next evolution will be “mimicry”—that is, making Tor traffic appear as legitimate and essential services like YouTube, Zoom, and WeChat. In some censored areas, access to these services is maintained because completely blocking them would result in serious socioeconomic damage.

My project, “mimicry-pt,” uses an LSTM model to replicate the statistical distribution of packet size and timing to counter modern DPIs. While the current prototype focuses on YouTube, the model can be trained to mimic any high-traffic protocol.

Overview:
The goal of this project is to counter advanced traffic classification by using LSTM (Long Short-Term Memory) models to shape Tor traffic. Unlike existing transports that focus on obfuscation, mimicry-pt shapes the packet timing and size distributions to statistically match a “cover” identity, such as YouTube video streaming or browser games.

Key Technical Details:

Traffic Shaping: It generates a (delay, size) scenario based on an LSTM model trained on real-world traffic.

Statistical Similarity: Achieves a Wasserstein divergence of <25% for YouTube covers.

Active-Probing Defense: The bridge serves a decoy HTML page to unauthorized requests.

Implementation: The client is written in pure Python (stdlib only) for maximum portability while the bridge uses PyTorch for inference.

Current Status:
This is currently a research prototype. It has been tested and verified within a local Chutney network, but it has not been deployed or tested on the live Tor network yet.

Next Steps:
I am planning to:

Integrate uTLS for realistic TLS fingerprinting.

Optimize upload throughput (currently limited by the YouTube cover’s natural POST frequency).

Formalize the PT API for easier integration with Tor.

I’ve made the repository public today and would love to get feedback, critiques, or suggestions from the anti-censorship team and the wider community.

**Future Potential:**Even in a future where quantum computers can decrypt TLS traffic, the sheer volume of legitimate “cover” traffic makes analyzing every connection computationally and economically impossible. Removing “suspicious” markers from Tor traffic would present censors with a “find the needle in a haystack” difficulty, and the cost of targeted analysis would be prohibitively high.

GitHub Repository: https://github.com/SilentWavesCore/mimicry-pt

Best regards,
SilentWaves

[silentwaves]

I have a fundamental question for the community. How effective do you think this “statistical imitation” approach is against modern censorship systems?

I plan to address the discrepancies between the transport protocol and reality (YouTube actually uses QUIC) and implement uTLS support later. Would falsifying packet size and timing allow me to bypass the latest machine learning-based classifiers used by censorship agencies? Do I need to make it more realistic?

I’d like to know if this approach is worth pursuing as a practical transport. Any opinions on its effectiveness in the “real world” would be extremely helpful.

I welcome any feedback, questions, or critical thoughts you might have! > Please feel free to tear this idea apart—I’m here to learn and make this a practical tool.

[unic3rn]

YouTube is blocked in Russia, for example. Could the model mimic some kind of UDP-based video/audio calling software? Like the RU government’s “messenger” uses WebRTC. It maybe could work like that in the real world.

A VPN protocol AmneziaWG uses UDP, but it randomizes some values to make every user a little bit more different than the others, so what do you think about it?

[silentwaves]

Thank you for your reply!

This is a very important practical point that I hadn’t considered sufficiently. If YouTube is blocked in the target country, traffic like that of YouTube itself will be considered suspicious. I think the choice of ID to spoof needs to be not only statistically compelling but also take regional characteristics into account.

WebRTC-based apps (Telegram calls, VK, government messaging apps, etc.) are very effective, especially in Russia. These apps are widely used, UDP-based, and perform symmetrical uploads, thus eliminating the approximately 20KB/sec upload bottleneck that YouTube spoofing inherits from HTTP/1.1.

Regarding AmneziaWG, I think the idea of ​​per-user randomization is very important. mimicry-pt’s LSTM already generates statistically diverse scenarios per session (no two connections are exactly alike), which is the same principle applied in the traffic pattern layer. Combining this with protocol-level header randomization (as AmneziaWG does with WireGuard) allows both layers to be covered simultaneously.

In a censorship environment like Russia’s, using WebRTC-based spoofing over a QUIC transport (such as QuicTor) seems like the most practical combination. This is a very good idea, and I’d like to look into it!

[Shelikhoo]

Thanks for sharing your research idea. There are some issue that might impact the ability to promote this pluggable transport, but in general research into new protocols are more than welcomed, and the issues listed below may change as time move on.

Resource consumption

Although modern hardware often have more than enough resource to run a few models, many users that needs Tor the most might be running their Tor client on resource constrained environment, like low end android phone or iOS device(an vpn service in iOS only have 50MByte of memory allowance). As a result, the more resource intensive an application is, the more difficult it will be to promote that application.

Covering sites

Youtube is often not allowed in many region where anti-censorship is necessary. But I don’t think this is a fundamental limitation, so long as this design could work for other covering sites as well.

[silentwaves]

@Shelikhoo

Thanks for sharing your research idea. There are some issue that might impact the ability to promote this pluggable transport, but in general research into new protocols are more than welcomed, and the issues listed below may change as time move on.

Resource consumption

Although modern hardware often have more than enough resource to run a few models, many users that needs Tor the most might be running their Tor client on resource constrained environment, like low end android phone or iOS device(an vpn service in iOS only have 50MByte of memory allowance). As a result, the more resource intensive an application is, the more difficult it will be to promote that application.

Covering sites

Youtube is often not allowed in many region where anti-censorship is necessary. But I don’t think this is a fundamental limitation, so long as this design could work for other covering sites as well.

Thank you for your response.

Your point regarding resource constraints is valid. LSTM inference is performed entirely on the bridge server side. The client simply receives a pre-generated and stored one-time scenario (a set of instructions regarding timing and size) and follows it. Furthermore, since it’s delivered as the first frame upon connection, and additional scenarios are pushed as needed during the session, it shouldn’t require much machine-side resources. The client itself is written in Python using only standard libraries and has no machine learning-related dependencies. Therefore, it should run very lightweight even in resource-constrained environments.

The 50MB limit on iOS is a more stringent constraint, but because the client logic is minimal (SOCKS5 + HTTPS), a native iOS implementation is possible without bundling a machine learning runtime.

Regarding cover sites, as you pointed out, this isn’t a fundamental constraint. Cover IDs are pluggable, and YouTube just happened to be the first to implement them. WebRTC-based apps (such as Telegram calls) are being considered as the next target, especially in regions where YouTube is blocked.

[Shelikhoo]

Yeah, If the machine learning model is only running on server, then there won’t be the need to worried about the resource constraint of user’s device. Yes, just as you have described, it would not be very hard to get this design to work on using other sites as cover.

I believe if you are considering to eventually bundling this into tor browser, it would be really beneficial to open an issue here: Issues · The Tor Project / Anti-censorship / Team · GitLab . This would be give this idea more visibility and discussion, which it definitely deserve.

[silentwaves]

@Shelikhoo

Yeah, If the machine learning model is only running on server, then there won’t be the need to worried about the resource constraint of user’s device. Yes, just as you have described, it would not be very hard to get this design to work on using other sites as cover.

I believe if you are considering to eventually bundling this into tor browser, it would be really beneficial to open an issue here: Issues · The Tor Project / Anti-censorship / Team · GitLab . This would be give this idea more visibility and discussion, which it definitely deserve.

Thank you!

It seems like it would be good to publish it on GitLab.
I didn’t know such a place existed. Thank you for letting me know!

[silentwaves]

Hello everyone! Thank you for your continued interest! We’ve pushed some important updates to the repository.

uTLS Integration: Rewritten the client system from the Python standard library to Go. The Go client now uses HelloChrome_120 over uTLS, directly copying the ClientHello from Chrome 120 (including GREASE and extension order). The JA3 hash has been verified to match Chrome 120.

PT Managed Proxy Protocol: Implemented CMETHOD/SMETHOD standard output signaling, allowing mimicry-pt to be launched directly from torrc via ClientTransportPlugin/ServerTransportPlugin.

End-to-End Verification: Confirmed operation on a local Chutney network. Tor was 100% bootstrapped and passed chutney verify (circuit construction + data transfer) with the Go client.

What’s next:

WebRTC / video call cover identity — The YouTube cover limits upload to ~20 KB/s due to the nature of the cover (YouTube is download-heavy). A Zoom or Telegram call cover would fix this and is more appropriate for regions where YouTube is blocked.

Live Tor network testing — All verification so far has been on a local Chutney network. Real-world bridge deployment and measurement is the next milestone.

Collaboration potential — The LSTM traffic shaping layer is transport-agnostic. It could potentially sit on top of existing transports like Snowflake (handling timing/shape while Snowflake handles NAT traversal).

Feedback of any kind is welcome — questions, suggestions, or criticism.

GitHub: GitHub - SilentWavesCore/mimicry-pt · GitHub

[unic3rn]

You can request a Tor Project GitLab account here.

@silentwaves

Telegram call

Well, Telegram and WhatsApp calls are throttled. They, it seems, do blocking by fingerprinting them and throttling them. WebRTC works, Zoom, other non-fingerprinted messenger apps using the UDP-protocol work.

[Protium_serratum]

@silentwaves

Modern censorship systems like the Great Firewall (GFW) identify and block such “randomized” traffic in real time. Simply “making nothing visible” is not an effective strategy for circumventing sophisticated and persistent censorship.

I used a method similar to this to mask the headers of wireguard packets (so these packets look random), but never triggered blocking.

[silentwaves]

@unic3rn

@silentwaves

Telegram call

Well, Telegram and WhatsApp calls are throttled. They, it seems, do blocking by fingerprinting them and throttling them. WebRTC works, Zoom, other non-fingerprinted messenger apps using the UDP-protocol work.

Thanks for that insight — it’s very useful to know Telegram/WhatsApp are being throttled by fingerprinting.

For the next cover identity, I’m leaning toward Zoom (signaling over HTTPS/TCP 443) since it fits the current HTTP-based architecture and is widely used even in restricted regions. WebRTC-based covers like Discord or Google Meet are also interesting but would require moving to UDP, which is a bigger protocol change.

Do you have a sense of which of these services sees the most usage in heavily censored regions like Russia or Iran? That would help prioritize which cover to implement and capture training data for.

And thanks for pointing me to GitLab — I’ve already submitted an account request, so once it’s approved I’ll open a proper issue there!

[silentwaves]

@Protium_serratum

@silentwaves

Modern censorship systems like the Great Firewall (GFW) identify and block such “randomized” traffic in real time. Simply “making nothing visible” is not an effective strategy for circumventing sophisticated and persistent censorship.

I used a method similar to this to mask the headers of wireguard packets (so these packets look random), but never triggered blocking.

Thank you for sharing your experience — that’s a really useful data point!

It may still work in some regions. However, obfs4 is already blocked in the most heavily censored environments (China, Iran, etc.), which suggests a trend towards more advanced DPI (Deep Packet Inspection).

It’s also worth noting that VPN detection is already a solved problem in the world of enterprise security. Because companies need to prevent data leaks via unauthorized VPNs, major security vendors already offer robust fingerprinting for WireGuard, OpenVPN, and similar protocols. If censorship authorities decide to license or adopt this technology, there will be no room for countermeasures overnight.

The fundamental difference with mimicry-pt is that while obfs4 tries to make traffic appear featureless, mimicry-pt actively impersonates legitimate traffic using a model trained with LSTM. Censors don’t see “unknown and suspicious encrypted data” — they see a “Zoom call” or “business HTTPS traffic.” And that’s precisely the traffic they cannot easily block without disrupting legitimate activity.

[unic3rn]

With censorship, it’s always shifting. If I say that something works today, it might not tommorow.

But i.e., Yandex, a Russian company, has a service called “Yandex Telemost“, which uses Jitsi.

Google Meet and Zoom work, but they might get blocked.

[silentwaves]

Thank you for providing information from a real-world perspective.

That’s a very important point. Because censorship is constantly changing, mimicry-pt is designed to allow switching cover IDs. Even if Zoom were blocked tomorrow, we would only need to switch to a new cover model without changing the underlying transport code. (I updated yesterday to separate the inference model and bridge server system.)

Yandex Telemost/Jitsi is an interesting proposal and option, especially in Russia. Since it’s a Russian service, it’s less likely to be blocked. However, there’s a concern. Since it’s a domestic service, does the traffic normally remain within Russian servers? If so, mimicking while connecting to an overseas bridge could raise suspicion. Do you know if it’s routing through international servers, or if it uses standard WebRTC over HTTPS/443 as a fallback?

[unic3rn]

@silentwaves

However, there’s a concern. Since it’s a domestic service, does the traffic normally remain within Russian servers? If so, mimicking while connecting to an overseas bridge could raise suspicion. Do you know if it’s routing through international servers, or if it uses standard WebRTC over HTTPS/443 as a fallback?

It probably uses stun.yandex.ru, which is hosted in Moscow.

So the better direction to go is probably just “Jitsi”, since it can be hosted anywhere.

It could be hard to do, but it’s interesting if mimicry can clone any website, then you can collect a list of “working” public websites and have those as a fallback, while masking the traffic as https traffic.

[silentwaves]

Thank you!

Jitsi’s servers are located overseas.

In that case, I’ll try creating a Jitsi spoofing model.

Actually, mimicry-pt already supports pluggable cover identities and has successfully modeled YouTube, gaming sites, news sites, and more.

If successful, traffic to the overseas bridge will blend seamlessly with real Jitsi, making Tor traffic statistically unidentifiable — potentially a stronger alternative to WebTunnel.

For reference, here are the results of our current YouTube traffic similarity experiment:

[silentwaves]

Hello everyone, I have a major discovery!

I had a sudden thought that existing mimicry-pt might be meaningless because DPI analyzes packets after network hops, so I investigated.

Result: I found that the approximation does not break down even after network hops.

The usual concern is whether traffic shaping that looks good at the source is maintained after actual network hops. Proxies and routers can generate jitter, buffering, and queuing, potentially destroying the spoof before DPI can detect it.

Therefore, I applied network transformation (Gaussian jitter σ = 1–60ms + buffering spikes) under identical conditions to both actual YouTube traffic and Tor traffic shaped with LSTM, and measured the statistical distance in the output. Results for inter-packet delays (watching_small: short/low-quality video streaming pattern):

Condition	Similarity	KS stat	p-value
No transform (source)	95.9%	0.041	0.39
LAN (σ=1ms)	96.3%	0.037	0.54
ISP (σ=10ms)	96.8%	0.032	0.70
International (σ=60ms)	96.8%	0.032	0.72

KS < 0.05 and p > 0.05 means that the two distributions are statistically indistinguishable. This disguise is maintained across the network and actually improves as jitter increases. This is because jitter smooths out the subtle differences between real and synthetic traffic.

What these results show is very significant and demonstrates the effectiveness of LSTM shaping for DPIs used to analyze traffic.

Please feel free to ask any questions, criticisms, or collaborate regarding mimicry-pt. I’m still exploring which services would be the best candidates to mimic — suggestions are very welcome, either here or via DM.

[unic3rn]

@silentwaves

Jitsi’s servers are located overseas.

Well, anyone can create a Jitsi instance, so it shouldn’t even look that suspicious for the DPI machine.

You can search for working sites/services by looking at censorship data.

Internet Censorship in Russia - OONI Explorer

Observatory Dashboard | Censored Planet Dashboard

And you can look at the data of any country.

[silentwaves]

Thank you for providing the data. It was very helpful. While I couldn’t find specific data on Jitsi, in Russia, YouTube’s low latency makes it a strong candidate for spoofing IDs when handling high-traffic content. It would clearly be ineffective in China.

From a broader perspective, is it possible to mimic reverse proxies and CDN nodes for domestic services like VK, and use them as infrastructure to deliver VK content to Russian users outside of Russia? This is a natural and common traffic pattern, but I’m concerned about whether services like VK employ a strict IP whitelisting system in their delivery infrastructure.

Again, thank you for introducing me to such a wonderful site.

If anyone has data on Jitsi’s latency, or knows whether VK or similar services employ an IP whitelisting system, please share the information.