Предлагаемое решение
v4.14.0 ships an automatic server-side mitigation: the MTProxy listening socket now announces a 256-byte TCP MSS in its SYN-ACK, forcing the client kernel to fragment the outgoing ClientHello across 2-3 TCP segments. ALPN and signature_algorithms land in segment 2/3 of a typical Telegram ClientHello, so a DPI that JA4-fingerprints from a single packet computes the wrong hash and the signature misses.
No configuration, no client change, no operator action — restart the binary, the SYN-ACK MSS is on the wire.
Trade-off documented honestly: Linux applies the listening-socket MSS to both directions of each accepted connection, so server→client segments are also capped at 256. Packet count rises ~5× and per-byte TCP/IP overhead grows from ~3% to ~15%. Modern hardware with TSO/GSO handles the CPU side; the existing 20MB MTProto E2E test still completes well inside its timeout.
Not a complete fix — JA4 evasion via fragmentation only works against single-packet extractors. A DPI that fully reassembles TCP streams still computes the right hash. But many DPI deployments don't reassemble at line-rate because it's expensive at scale, and TSPU has been observed to operate on intact segments. Pairs with the existing ServerHello segmentation so both sides of the handshake become unfriendly to single-packet inspection.
Возможно ли в связи с этим сделать подстройку MSS у прокси, чтобы разбивать запрос. В Telemt добавили и вроде работает
Для какой платформы актуально?
Все платформы
Дополнительный контекст
No response
Предлагаемое решение
v4.14.0 ships an automatic server-side mitigation: the MTProxy listening socket now announces a 256-byte TCP MSS in its SYN-ACK, forcing the client kernel to fragment the outgoing ClientHello across 2-3 TCP segments. ALPN and signature_algorithms land in segment 2/3 of a typical Telegram ClientHello, so a DPI that JA4-fingerprints from a single packet computes the wrong hash and the signature misses.
No configuration, no client change, no operator action — restart the binary, the SYN-ACK MSS is on the wire.
Trade-off documented honestly: Linux applies the listening-socket MSS to both directions of each accepted connection, so server→client segments are also capped at 256. Packet count rises ~5× and per-byte TCP/IP overhead grows from ~3% to ~15%. Modern hardware with TSO/GSO handles the CPU side; the existing 20MB MTProto E2E test still completes well inside its timeout.
Not a complete fix — JA4 evasion via fragmentation only works against single-packet extractors. A DPI that fully reassembles TCP streams still computes the right hash. But many DPI deployments don't reassemble at line-rate because it's expensive at scale, and TSPU has been observed to operate on intact segments. Pairs with the existing ServerHello segmentation so both sides of the handshake become unfriendly to single-packet inspection.
Возможно ли в связи с этим сделать подстройку MSS у прокси, чтобы разбивать запрос. В Telemt добавили и вроде работает
Для какой платформы актуально?
Все платформы
Дополнительный контекст
No response