Suspicion of TSPU protocol detection after a Fake-TLS handshake

[6lGRUSHAl6]

It seems that TSPU (RF) algorithms have learned to accurately detect MTProto traffic inside Fake-TLS, based on payload analysis after connection establishment.

I captured a traffic dump (Wireshark) and discovered the following blocking pattern:

1. Normal availability check and initial handshake succeed. The server responds to TCP SYN, and the TLS Client Hello and Server Hello exchange completes.
2. As soon as Application Data transmission (the actual MTProto session setup) begins, TSPU intervenes in the process.
3. The connection is not actively terminated (DPI does not send a TCP RST), but packet drops occur. The client starts spamming [TCP Retransmission], trying to reach the server, but there is no further response.

By the way, if you simply test server availability, the connection establishes perfectly.

I am using the latest version of mtg (2.2.8) as well as the latest version of Telegram.

[9seconds]

Please see here: telegramdesktop/tdesktop#30733 We can do nothing about it.

[rkline0x]

For other server-side maintainers landing here — there IS one server-side trick that doesn't require client cooperation: announce a small TCP MSS in the SYN-ACK, and the client kernel fragments its outgoing ClientHello across multiple TCP segments. At MSS=256, ALPN and signature_algorithms typically land in segment 2/3 of a Telegram ClientHello, and a DPI that JA4-fingerprints from the first packet alone gets the wrong hash.

teleproxy v4.14.0 ships this automatically on the public listener: https://github.com/teleproxy/teleproxy/releases/tag/v4.14.0 — full mechanism and the throughput trade-off are documented at https://teleproxy.github.io/features/dpi-resistance/#forced-clienthello-fragmentation-automatic.

Not a complete fix — a DPI that fully reassembles TCP streams still computes the right JA4 — but TSPU has been observed to operate on intact segments at line-rate, so single-packet fragmentation is enough to defeat many deployments today. Filed in case the same trick is useful in mtg.

[6lGRUSHAl6]

Thanks for the suggestion @rkline0x I tested this on my VPS.

Unfortunately, TSPU (Russian DPI) is smart enough to bypass this trick via full stream reassembly.

So, while the TCP MSS trick is great, in my region TSPU apparently performs full stream reassembly when needed, making this workaround ineffective right now.