The FakeTLS listener (--listen-faketls-domain) no longer answers Telegram clients with a ServerHello
that no real TLS server would send.
Why (#145)
Our ServerHello copied the first cipher suite from the client's ClientHello. Official Telegram clients
(TDLib, Android, Desktop) put a GREASE value (0x0a0a, 0x1a1a, … 0xfafa) first, as browsers do. So
every ee connection from a Telegram client got a ServerHello that selected GREASE. RFC 8701 forbids
servers from doing that, so no real server does it. Wireshark shows it as Cipher Suite: Reserved (GREASE).
A DPI box could flag those flows passively from one field of the server's first packet. It would not need
active probing or a look at the client side. That undermines the whole point of FakeTLS camouflage.
Fixed
- The ServerHello now selects the client's first TLS 1.3 suite (
0x1301–0x1303) and skips GREASE and
everything else. That is what the official MTProxy does. If the client offers no TLS 1.3 suite, it falls
back toTLS_AES_128_GCM_SHA256(0x1301).
Clients authenticate the FakeTLS handshake by the HMAC in the server random, not by the selected suite, so
nothing changes for them. Only the inbound listener was affected: the upstream side (--mtproto-proxy with
an ee secret) sends its own ClientHello, which starts with 0x1301.
What it costs
Nothing measurable. Choosing the suite is a scan over the client's cipher list, which is a few dozen bytes,
once per connection.
Dependencies
rustls0.23.43 → 0.23.45 andrustls-webpki0.103.13 → 0.103.15 (#146). The rustls release fixes
GHSA-2mjx-qc3c-rqvc (moderate): TLS 1.3 handshake
messages were accepted across encryption level boundaries.