TLS: randomize padding, fix ALPS codepoint, optional ECH policy

[RsNest]

Summary
Hardens the synthetic TLS transport (MTProxy ee fake-TLS) against static DPI fingerprinting by removing constant-size signatures and eliminating characteristic burst patterns.

Changes
Padding (S1): Replace fixed 513-byte ClientHello padding target with a per-connection random value in [512, 562], staying above the 511-byte F5 device threshold.
Record size (S5): Replace fixed 2878-byte application data record cap with a per-record random value in [2048, 4095], so bulk transfers no longer produce a constant chunk-size pattern.
Packet coalescing: Buffer encrypted MTProto packets at the TcpConnection layer and flush them together after a random 5–30 ms delay. This merges multiple small messages into fewer, larger TLS records, eliminating the burst pattern where several packets are sent within milliseconds of each other. File transfer connections bypass coalescing to preserve throughput.
Testing
Built locally on Windows (Debug, MSVC v143); verified app runs and connects.
Wireshark captures confirm varying TLS record lengths during data transfer.
Wireshark captures confirm coalesced packets: individual chat messages that previously produced separate TLS records now appear as single, larger records (e.g. 738, 1120 bytes vs typical 200–450 bytes per message).
No UI changes, no new files, no new build flags.

[CLAassistant]

All committers have signed the CLA.

[axkurcom]

sounds good, but codebase is so large...

[Flowseal]

Padding (S1): Replace fixed minimum padding (~513 B total) with a per-connection randomized floor (496 + RandomIndex(41)), so ClientHello length is not a constant signature.

But fixed 512 padding is the default behavior for small packets. It won't be difficult to check the range 496-536 for them, such packets are much rarer and may cause even more questions. May be it's a half-measure, but not a solution imo

ALPS (S7): Use IANA application_settings codepoint 0x4469 instead of legacy draft 0x44CD, aligning with Chrome 115+ wire format.

dump from the latest Chrome version:

Extension: application_settings (len=5)
Type: application_settings (17613)

17613 = 0x44CD

[RsNest]

Padding (S1): Replace fixed minimum padding (~513 B total) with a per-connection randomized floor (496 + RandomIndex(41)), so ClientHello length is not a constant signature.

But fixed 512 padding is the default behavior for small packets. It won't be difficult to check the range 496-536 for them, such packets are much rarer and may cause even more questions. May be it's a half-measure, but not a solution imo

ALPS (S7): Use IANA application_settings codepoint 0x4469 instead of legacy draft 0x44CD, aligning with Chrome 115+ wire format.

dump from the latest Chrome version:

Extension: application_settings (len=5)
Type: application_settings (17613)

17613 = 0x44CD

Thanks. On S1, fair point: the current randomized floor is meant only as a minimal measurable step to remove a constant-length signature, not as a final indistinguishability solution. I can clarify that in the PR and keep stronger profile/capture-driven sizing for a follow-up step. On the ALPS point, could you clarify the codepoint expectation? The comment mentions 0x4469, but the dump snippet below shows 17613 (0x44CD), so I want to make sure I align with the exact wire format you expect.

[RsNest]

I already tested the change in captures: there is no malformed packet output in Wireshark, the TLS record is parsed correctly, and the resulting ClientHello/application data lengths are no longer constant between connections.

[Flowseal]

On the ALPS point, could you clarify the codepoint expectation? The comment mentions 0x4469, but the dump snippet below shows 17613 (0x44CD), so I want to make sure I align with the exact wire format you expect.

You say that 0x44CD is legacy, but the ClientHello dump from the latest Chrome version shows that its still in use

[roman901]

One host, this TG with patch and latest browsers:

Client sends 17513

Part of dump from Firefox:

Which is using 17513

Chrome sends 17613

[roman901]

Let's use 44CD - with that TG JA4 hash is equal with latest (146) Chrome
[JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd]

[ilya-fedin]

This looks useless. All browsers go into ECH, now you want to make it optional (who is going to build it with non-default option anyway?) making the code more complicated without any reason.

[RsNest]

Thanks, fair point.

I'll remove the default-off ECH option and keep ECH enabled by default.

And yes, separating the ClientHello refactor from the actual wire-format changes makes sense — I'll split that into a separate commit to make the review easier.

[ilya-fedin]

I really advice to maintain PR's scope as little as possible and avoid refactors, especially if you're using AI (which it seems you do).

[ilya-fedin]

Also, if you're using AI, prevent it from adding compile-time/env-based settings. That's not used by tdesktop. Ideally such things shouldn't be configured by the user. But if it's absolutely necessary, then use the experimental settings mechanism (base::option).

[RsNest]

Thanks, got it. I'll keep that in mind.

[ilya-fedin]

• Refactor: move ClientHello generation into mtproto_tls_client_hello.{h,cpp}; wire from mtproto_tls_socket.

Either do it in a separate commit so that the changes are reviewable or maybe it would be even better to not do it at all

[ilya-fedin]

Also, the files should be removed right in the commit they were added to, not in separate commits. So that it doesn't look like "add in one commit to immediately remove it in the next one".

[ilya-fedin]

Use already existing DESKTOP_APP_TEST_APPS

[ilya-fedin]

Hmm, this changes the same place as #30513 but in other way. I wonder which one is right?

[V3nilla]

Hmm, this changes the same place as #30528 but in other way. I wonder which one is right?

Looks like you mentioned wrong PR. Are you talking about #30513?

[ilya-fedin]

Yeah, I meant #30513

[V3nilla]

Yeah, I meant #30513

After looking at the info from their TG channel, this PR looks more correct, because there are enough problems fixed(like Malformed Packets) + mimicry for a real browser (Chrome). Quite a lot of people have tested this PR and offered their fixes to it

[RsNest]

Official Telegram Desktop client — multiple small packets sent in rapid bursts (e.g. packets #60703, #60704, #60706 within 200ms at ~460s mark). Uniform incoming record sizes (~186 bytes). Fixed record size pattern visible across the session.

[RsNest]

Modified client (this PR) — coalesced records visible: 738 and 1120 bytes indicate multiple MTProto packets merged into single TLS records. Wider size variance (217–1120 bytes) compared to official client. No rapid-fire bursts — packets are spaced out by the 5–30ms coalescing delay.

[SagePtr]

I'm probably dumb, but can the padding mathematically happen? If ClientHello includes X25519MLKEM768 key of 1216 bytes, it mathematically cannot fit into 512..562 bytes total. In the wild, I never seen padding in PQ-enabled browser, so wondering what exactly we are mimicking with 512..562 padding

[john-preston]

@SagePtr you're right, client hello here is always more than a KB, so those small paddings are irrelevant.

To author and guys around, please stop vibecoding changes to protocol implementation without deep understanding. This won't end well.

[RsNest]

@SagePtr you're right, client hello here is always more than a KB, so those small paddings are irrelevant.

To author and guys around, please stop vibecoding changes to protocol implementation without deep understanding. This won't end well.

We are trying to build a more resilient client with our own hands because the official Telegram community has done almost nothing to actually help people in Russia deal with blocking and DPI.
Yes, some decisions may be imperfect, some patches may be debatable, and mistakes can happen — but at least people are doing something, testing ideas, and discussing them instead of staying silent.
If someone truly has deep knowledge of TLS, ClientHello, and fingerprinting, great — join in, suggest better solutions, open PRs, and help. But sitting on the sidelines and only saying that everything is wrong is no longer enough.

[RsNest]

I'm probably dumb, but can the padding mathematically happen? If ClientHello includes X25519MLKEM768 key of 1216 bytes, it mathematically cannot fit into 512..562 bytes total. In the wild, I never seen padding in PQ-enabled browser, so wondering what exactly we are mimicking with 512..562 padding

I think you're right about the overall size. With X25519MLKEM768 enabled, ClientHello is already much larger than 512..562 bytes, so that old target no longer really applies in PQ-TLS scenarios.
In my case, the goal was not to force the whole ClientHello into that exact range, but rather to avoid having one completely fixed padding size and one perfectly stable fingerprint across all connections.
Even if the final ClientHello is much larger, adding some variability still helps avoid sending exactly the same structure every time. It is not meant as a complete solution, just as one small step toward making the fingerprint less static.
I agree that this part should probably be revisited with more realistic size ranges for PQ-enabled handshakes.

[DavidOsipov]

Isn't a fail-fast approach much more favorable here than do-nothing? I suppose it's better to help the guys from Digital resistance

[1koh]

@SagePtr you're right, client hello here is always more than a KB, so those small paddings are irrelevant.

To author and guys around, please stop vibecoding changes to protocol implementation without deep understanding. This won't end well.

Please do something. This process is becoming irreversible.

[axkurcom]

To author and guys around, please stop vibecoding changes to protocol implementation without deep understanding

i fully agree and get it - as "maintainer to maintainer":
low-level details, contracts, invariants, and protocol nuances
must be consciously understood, not shipped as raw AI output...
it is crazy and unforeseeable

but i don’t think this means people shouldn’t use ai at all,
it just needs to be done deliberately,
with clear understanding, and with risks properly controlled)

[avbor]

Just take a look at the graph showing the platform's accessibility from Russia:

You are losing your audience, and we are losing our connections. It seems to me it is high time to take proactive measures; a 2-byte fix—which hasn't even been released across all platforms yet—is clearly insufficient.

[john-preston]

@avbor sure the availability without proxies / vpn is dying, they banned the endpoints. But this doesn't have anything to do with this PR. The "2-byte fix" really fixed working through myproxy, which is best you can expect right now. I hope we will be able to keep it working through unbanned mtproxies.

[avbor]

@john-preston

That’s not entirely accurate.
There are hundreds of thousands of users utilizing various proxies, and this has absolutely no impact on the overall availability of the service.
Yes, there is a fix, and yes, it currently works.
But, firstly, it has only been released on the desktop version.
Without mobile clients, it doesn't make much sense.
Secondly, in my view, this has merely postponed a new block by a week or two.

[1koh]

@john-preston I hope we will be able to keep it working through unbanned mtproxies.

DPI currently doesn't ban MTProto servers, as it did in 2018. Currently, DPI simply detects Telegram traffic based on known signatures and doesn't allow it. My MTProto servers connect perfectly with version 6.7.2 clients, but they don't work with earlier versions.

[john-preston]

@1koh I believe that main official endpoints are still banned by IP, there is no sense in not doing that.

[avbor]

I believe that main official endpoints are still banned by IP

Yeap, that is correct.

And yes, the only truly effective strategy is the use of proxies.
There is a convenient distribution mechanism in place, ready-made solutions are available, and there is a large community that adapts these solutions for ordinary users.
However, Telegram's failure to act in a sufficiently timely manner has resulted in the situation depicted in the graph above. Unfortunately.

[1koh]

@john-preston I believe that main official endpoints are still banned by IP, there is no sense in not doing that.

We can't solve the IP blocking issue with the main official endpoints. But we can ensure client-MTProto connectivity. We host MTProto proxies in locations where there is connectivity to official Telegram endpoints.

[Flowseal]

I believe that main official endpoints are still banned by IP

Yeap, that is correct.

And yes, the only truly effective strategy is the use of proxies. There is a convenient distribution mechanism in place, ready-made solutions are available, and there is a large community that adapts these solutions for ordinary users. However, Telegram's failure to act in a sufficiently timely manner has resulted in the situation depicted in the graph above. Unfortunately.

The graph shows that unavailability began towards the end of march, these are the usual IP bans that have nothing to do with mtproto blocking. It's still easier for people to turn on vpn and use telegram without a proxy (especially on mobile devices). Yes, there were some problems with ClientHello, due to which DPI detected the proxy with minimal effort, but they were solved.

[avbor]

@Flowseal

I know perfectly well what this graph shows, and I can clearly see just how much or how little easier it has become for people to use a VPN.
I can literally feel the decline in Telegram’s audience firsthand.
Ok, go right ahead and keep believing that all of this is enough.

[Flowseal]

I know perfectly well what this graph shows, and I can clearly see just how much or how little easier it has become for people to use a VPN.
I can literally feel the decline in Telegram’s audience firsthand.
Ok, go right ahead and keep believing that all of this is enough.

We are here to discuss MTProto detection, not ip bans, which have nothing to do with this topic, because nothing can be done about them. Proxies are now working as before, but the plot won't get any better

[SanchoZZ2]

Я считаю, что основные официальные конечные точки по-прежнему заблокированы по IP

Да, это верно.
И да, единственная по-настоящему эффективная стратегия — использование прокси. Для этого есть удобный механизм распространения, готовые решения и большое сообщество, которое адаптирует эти решения для обычных пользователей. Однако Telegram не смог отреагировать достаточно оперативно, и в результате сложилась ситуация, показанная на графике выше. К сожалению.

График показывает, что проблемы с доступностью начались ближе к концу марта. Это обычные IP-баны, которые не имеют ничего общего с блокировкой mtproto. Людям по-прежнему проще включить VPN и пользоваться Telegram без прокси (особенно на мобильных устройствах). Да, были проблемы с ClientHello, из-за которых DPI с минимальными усилиями обнаруживал прокси, но они были решены.

I will try to summarize somehow: The presented graph shows the availability of telegrams without bypassing blocks. Indeed, the main servers are banned by IP address. The previous patch was a solution to the problem of blocking MTPROTO proxies by a characteristic fingerprint when establishing a TLS connection, and it has nothing to do with blocking IP addresses, as other services on IP addresses with proxies were working.
The current discussion and PR are created for two reasons:

1. The previous patch is still easy to detect again, and the DPI signatures will be released quite quickly. Yes, it is difficult to predict the speed of re-blocking with new signatures, but everything indicates that this patch will not last long (more than a month). Developing another patch after the current one stops working is very disruptive to the predictability of service availability, forcing users to switch to other platforms. Therefore, the community is looking for a more reliable and difficult-to-detect solution before the old one stops working.
2. There is no information from the Telegram team about the improvements to the mtproto protocol and the client in terms of bypassing blocks.

I do not speak English, so I translated it using a translator.

[SagePtr]

Even if the final ClientHello is much larger, adding some variability still helps avoid sending exactly the same structure every time.

Did you try to read the code you are fixing and figure out under which circumstences what branches are executed? The padding is applicable only if entire ClientHello is between 256 and 512 bytes. This can never happen mathematically in this case.

Also, isn't the goal of FakeTLS to mimic existing browser behavior in order to be as indistinguishable from them as possible, rather than inventing custom randomly sized padding schemes which are not used by any of real browsers and are therefore easy to detect?

[avbor]

Proxies are now working as before, but the plot won't get any better

Not at all. Right now, for the vast majority of people, nothing is working. Where are the Android and iOS releases?
And yes, in this PR we discusses the fact that the changes made are insufficient for the future.

[1koh]

@Flowseal The graph shows that unavailability began towards the end of march, these are the usual IP bans that have nothing to do with mtproto blocking. It's still easier for people to turn on vpn and use telegram without a proxy (especially on mobile devices). Yes, there were some problems with ClientHello, due to which DPI detected the proxy with minimal effort, but they were solved.

The graph shows Telegram traffic. The MTProto proxy masks the traffic behind a fake SNI using Fake-TLS. It's no surprise that this graph doesn't show traffic passing through the MTProto proxy. All my MTProto proxies have been running for almost two months and haven't been banned by IP yet.

[Flowseal]

Not at all. Right now, for the vast majority of people, nothing is working. Where are the Android and iOS releases?

what does this have to do with this PR and our topic?

It seems to me that it's time to stop offtopic, the discussion is overheated, its a pull request about mtproto first of all and not about the availability of telegram in general

[RsNest]

Even if the final ClientHello is much larger, adding some variability still helps avoid sending exactly the same structure every time.

Did you try to read the code you are fixing and figure out under which circumstences what branches are executed? The padding is applicable only if entire ClientHello is between 256 and 512 bytes. This can never happen mathematically in this case.

Also, isn't the goal of FakeTLS to mimic existing browser behavior in order to be as indistinguishable from them as possible, rather than inventing custom randomly sized padding schemes which are not used by any of real browsers and are therefore easy to detect?

I appreciate the detailed review. The padding change was a mistake on my side — I didn’t verify which code path actually runs with the current PQ ClientHello. I’m not trying to push random protocol tweaks; I’ll fix my own oversights, incorporate this feedback, and push an updated revision shortly rather than arguing around it.

[ilya-fedin]

the official Telegram community has done almost nothing to actually help people in Russia deal with blocking and DPI

Let's be fair, this stance isn't entirely correct. 99% of the work was done half a year ago, in b72deb1 (updating to that time's actual Chrome client hello). Other clients should have similar commits since they all did it based on some internal document of their specialist. Yeah, they made bugs in two lines but who and how would find them before TSPU rules were deployed? The community (not only the telemt one!) has made a good reasearch and that's a very good thing but still the PRs provided were of a bad quality: fixing one bug, introducing a new one.

It's entirely unfair to say that Telegram has done nothing and everything was done by telemt community as it's told on habr and I guess meant by you. What really happened is: Telegram has made a big fix with a bug in two lines half a year ago, the community has done a good research, attempted to fix code but failed yet the research helped the devs to fix the initial bug. Everyone has done something.

[RsNest]

the official Telegram community has done almost nothing to actually help people in Russia deal with blocking and DPI

Let's be fair, this stance isn't entirely correct. 99% of the work was done half a year ago, in b72deb1 (updating to that time's actual Chrome client hello). Other clients should have similar commits since they all did it based on some internal document of their specialist. Yeah, they made bugs in two lines but who and how would find them before TSPU rules were deployed? The community (not only the telemt one!) has made a good reasearch and that's a very good thing but still the PRs provided were of a bad quality: fixing one bug, introducing a new one.

It's entirely unfair to say that Telegram has done nothing and everything was done by telemt community as it's told on habr and I guess meant by you. What really happened is: Telegram has made a big fix with a bug in two lines half a year ago, the community has done a good research, attempted to fix code but failed yet the research helped the devs to fix the initial bug. Everyone has done something.

Я понял ваш посыл, и в целом понял позицию всех, кто здесь писал.

Повторюсь: мы не рассчитывали, что PR примут в первый же день, и в целом не ожидали моментального аппрува. Нам скорее хотелось получить обратную связь от разработчиков Telegram: двигаемся ли мы вообще в правильную сторону, насколько можно и нужно менять кодовую базу, и имеют ли смысл такие небольшие, не критичные изменения.

Вы посчитали эти изменения бесполезными или ненужными — мы это тоже услышали и учли. Самое важное, что мы получили из этой дискуссии — это мысль Preston о том, что сначала нужно чётко понять, какую именно проблему мы пытаемся решить, и как вообще определить, что она действительно решена.

Моя задумка, как и задумка сообщества telemt, была в том, чтобы подтолкнуть команду к изменениям, которые могут сделать клиент стабильнее и устойчивее.

Что касается изменений, которые Telegram сделал полгода назад — тех самых двух строк: а какой практический результат они дали? Стал ли мессенджер действительно устойчивее?

Не вижу особого смысла сейчас выяснять, кто прав, а кто виноват. Мы получили огромный объём обратной связи, и это уже очень важно. Спасибо.

[Hi-Angel]

I just tested this PR and it fixes a critical bug of Telegram desktop no longer being able to connect to any proxy — a problem that started 3-4 hours ago.

Currently, Android Telegram works fine with proxy, however desktop telegram (with the same proxy) hangs infinitely trying to connect. That's with latest 6.7.5.

This branch fixes the problem.

[RsNest]

I just tested this PR and it fixes a critical bug of Telegram desktop no longer being able to connect to any proxy — a problem that started 3-4 hours ago.

Currently, Android Telegram works fine with proxy, however desktop telegram (with the same proxy) hangs infinitely trying to connect. That's with latest 6.7.5.

This branch fixes the problem.

Hi! I’m also using a custom Telegram Desktop build with my own fixes, and everything works fine for me on desktop Telegram with proxies.

[Bumbula]

The fix actually works, Telegram is back to life.

[anton-tagunov]

@RsNest, could you share your build? None of the proxies are working for me today.

[Hi-Angel]

@anton-tagunov here's mine, it's an Archlinux package.

[anton-tagunov]

@Hi-Angel thank you, but I am виндузятник. :-(

Has anybody built the fork for Windows? I can try to do it tomorrow only.

[Hi-Angel]

As of ½ an hour ago the PR it seems no longer works.

Like, there's a public proxy I can access with netcat nc -v 157.180.95.47 443 however, inside Telegram this proxy just loads indefinitely.

[Hi-Angel]

Okay, some proxies just started working… but not the one I pointed to in particular, so something may still be going on.

[RsNest]

Okay, some proxies just started working… but not the one I pointed to in particular, so something may still be going on.

DPI doesn't sleep 🫠

[Hi-Angel]

DPI doesn't sleep 🫠

Yeah, I understand, but DPI uses heuristics in attempts to distinguish MTProto from usual sites traffic, and your PR supposed to make MTProto more indistinguishable from such traffic, which means there's something else in the traffic that DPI can cling to.

Anyway, every bit matters, so I'll be very happy once you address the feedback and your commits will become part of the mainstream Telegram 😊