Add PSK extension to MTProxy ClientHello

[Katze-942]

The current MTProxy masquerade already mimics Chrome almost completely, but it's still missing a few details. This PR adds a pre_shared_key extension to the fakeTLS ClientHello used by the MTProxy transport.

This does not implement real TLS session resumption. Telegram does not store TLS tickets, does not resume TLS sessions, and does not use the PSK for any cryptography. It is purely imitation: the fakeTLS ClientHello gets a well-formed PSK, similar to what modern browsers often send on repeat TLS connections.

Why this matters

Right now in Russia, MTProxy fakeTLS is being blocked at the TLS handshake stage. This is caused by the mass of Chrome ClientHellos that have no pre_shared_key — which can also be reproduced with an ordinary browser.

When you reopen a site in a normal browser, it also sends pre_shared_key, and most likely that's why the DPI is less strict and lets a large number of ClientHellos through.

How it's implemented

A pre_shared_key extension is added:

• extension type: 0x0029
• PSK identity length: a few random values taken from a real capture
• binder length: random 32 or 48
• obfuscated_ticket_age: 4 random bytes
• identity and binder payload: random bytes
• extension is emitted last, as required by TLS 1.3

Does this break anything?

In TLS 1.3 a client may offer a PSK identity. The server is not required to accept that PSK. If the server doesn't select an identity, the handshake can simply proceed as a normal full handshake.

I also wondered whether a DPI could track the fake PSK. In my opinion this would be extremely expensive: a PSK can live for a very long time, and storing that volume of keys would simply become too costly.

Summary

This is not a full browser model, and it may be only a temporary patch, but to me it's very cheap and safe. Among other options that could bypass TSPU (Russia's DPI system), I found:

• using ALPN=http/1.1;
• using a different fingerprint, e.g. Firefox-like;
• reducing the burst of parallel TLS connections (probably the hardest one).

But IMO the other options also look like temporary patches. Let me know if you have any suggestions for improvement.

[Katze-942]

but random identity on each clienthello is easily detectable?

I don't think it's easily detectable. A random-looking PSK identity is normal by itself. To prove that it's fake, DPI would need to correlate it with real tickets issued by the server, which is not straightforward in TLS 1.3.

[ion-lane]

Will adding a PSK help change the fingerprint or reduce the number of simultaneous handshakes?
I don't think so. It won't help bypass the Telegram block in Russia.

[Katze-942]

but random identity on each clienthello is easily detectable?

I don't think it's easily detectable. A random-looking PSK identity is normal by itself. To prove that it's fake, DPI would need to correlate it with real tickets issued by the server, which is not straightforward in TLS 1.3.

this isn't ok when a client sends ~3-6 ClientHello with different PSKs in 1 second

Okay, I did find one inconsistency in my implementation. I noticed in packet captures that Chromium does not send PSK on every ClientHello.

Sorry about that. I’ll mark the PR as a draft for now and come back with a fix.

[axkurcom]

this isn't ok when a client sends ~3-6 ClientHello with different PSKs in 1 second

that isn't normal, when client sends similar CH 3-10 times per second,
indifferently, with the same psk or different)))

[SignFinder]

IMHO it is a good option in the case when millions of TG users are blocked.