Using a TLS Extension in a Fake ClientHello to Wrap the Original ClientHello

[rugameuser]

Hello! What do you think about the idea of using a fake TLS ClientHello packet with a custom TLS extension to "wrap" the original ClientHello packet?

According to RFC 8449, the maximum size of a TLS extension is 16,384 bytes, so the original ClientHello should fit within this limit. Typically, ClientHello packets are relatively small (around 517 bytes, excluding implementations like BoringSSL/etc, which may produce larger packets but should still fit within the extension size).

Here’s a potential approach:

1. Data that shouldn't reach the destination (e.g., by setting TTL=4):
   • fake ClientHello packet.
   • add a padding (or another appropriate type) extension with a size matching the original ClientHello packet (e.g., 517 bytes).
2. Sending the original data (e.g., by setting TTL=64):
   • send the original ClientHello packet with no modifications and other application data packets.

Behavior:

• The fake packet, would include an additional 4 bytes (2 byte extension type and 2 bytes original ClientHello length) for a packet that isn’t meant to reach the destination.
• The DPI TLS parser should parse the fake packet, process its extensions (including the padding), and effectively ignore the original ClientHello packet.
• This behavior could potentially bypass restrictions enforced by DPI, with something like --dpi-desync=fake being sufficient to achieve the bypass.

I don't know whether this approach fits within the RFC requirements for a valid TLS ClientHello packet. While some irregularities might technically violate the specification, DPI parsers are often less strict, focusing instead on practical parsing.
The idea leverages the assumption that DPI parsers may process the fake packet and skip over the original.

And what do you think? Is this approach viable? Would it effectively desynchronize DPI mechanisms while remaining practical?

[bol-van]

i see only one difference from current fake approach.
equal fake/real length
i havent seen a dpi that requires this scheme to bypass.
have you ? or your idea is a theory ?

[bol-van]

i can construct or modify tls fake in runtime
but i still dont understand by what value to increase handshake and padding
is it necessary to wrap the whole original tls hello
or a fixed value is enough (static file will do)

[rugameuser]

but i still dont understand by what value to increase handshake and padding

The value is first client packet size

Fields in a fake packet that should be increased by the size of the first packet from the client:

• Record size (2 bytes)
• Handshake size (3 bytes)
• Extensions length (2 bytes)
• Padding length (2 bytes)

Therefore, changing just 9 bytes in fake (in cases where the fake packet already includes a padding extension) will be sufficient. All other data remains unchanged.

Static files will break the TLS byte sequence order. The TLS parser will not expect this according to TLS specifications..

[bol-van]

ok. now all is clear. thanks for your idea

[bol-van]

Pls check the latest commit (source only, need to compile).
--dpi-desync-fake-tls-mod option contain comma separated list of tls fake mods :

rnd - randomize random and session id fields (runtime)
rndsni - randomize SNI hostname (one time at launch)
padencap - the feature we were talking about (runtime)

I confirm on my ISP fake without padencap does not work but with padencap works

[rugameuser]

Pls check the latest commit (source only, need to compile). --dpi-desync-fake-tls-mod option contain comma separated list of tls fake mods :

rnd - randomize random and session id fields (runtime) rndsni - randomize SNI hostname (one time at launch) padencap - the feature we were talking about (runtime)

I confirm on my ISP fake without padencap does not work but with padencap works

This is great. It seems to be working as expected. Thank you!