dpi-detector

mirror of https://github.com/Runnin4ik/dpi-detector.git synced 2026-10-19 09:23:17 +00:00

History

Kirill Minovsky f38a72f833 fix(fingerprint): size the padding slot against the finished hello The two Chrome records whose hello can fall under the 512-byte floor — chrome123 and chrome131android, at 497 bytes with the shortest GREASE ECH body — sent an unpadded hello where the reference client pads, because the padding slot measured only what had been written before it. ECH is appended last (TLS 1.3 requires it) and Chrome shuffles the extension order, so the slot counted neither the ECH body nor anything else that followed it; a slot that tried to reach the floor overshot by the whole body (803 bytes on the wire against the bundle's 517). `ClientExtensions::encode` now encodes the extensions that follow the padding slot into a scratch buffer, sizes the pad against the finished hello, and appends them — the same thing BoringSSL does when it sizes its pad, and the reason its hellos land on exactly 512. The per-extension encoding moved into one helper so both passes write an extension the same way. Both records get their padding back: `padding_to: Some(512)` and `CHROME_PADDING_AND_ECH_EXT_ORDER`, Chrome 99–107's list with the padding slot and the ECH the wrapper sends — padding in the order, ECH added outside it, as BoringSSL's table has it. They pad when the body is short (one connection in four) and stay above the floor otherwise, which is exactly what the client does; the desktop chrome131 keeps no padding, whose hybrid-group hello is never near the floor. Verified: eight `dump` runs per record — chrome123 and chrome131android carry 512 bytes on the short-body connections with JA4 `t13d1517h2_8daaf6152771_b1ff8ab2d16f` (the value the bundle's own padded capture measures) and 526/558/590 otherwise with `t13d1516h2_8daaf6152771_02713d6af862`; chrome107 stays at 512 (`t13d1516h2_8daaf6152771_e5627efa2ab1`) as before. `tools/fingerprint all`: `headers-diff` SAME everywhere, `hello-diff` SAME everywhere but the shufflers, and on these two only the per-connection body draw differs. `cargo test --workspace` (184 + 58) and `cargo clippy --workspace --all-targets` clean. `vendor/rustls/PATCH.diff` regenerated (1357 lines) and proved with `patch -p1` against a pristine crates.io copy.	2026-09-18 18:08:47 +03:00
..
dpi-core	fix(fingerprint): size the padding slot against the finished hello	2026-09-18 18:08:47 +03:00
dpi-detector	feat(fingerprint)!: one profile per shape, and names that carry the version	2026-09-18 15:57:48 +03:00

Kirill Minovsky f38a72f833 fix(fingerprint): size the padding slot against the finished hello

The two Chrome records whose hello can fall under the 512-byte floor — chrome123
and chrome131android, at 497 bytes with the shortest GREASE ECH body — sent an
unpadded hello where the reference client pads, because the padding slot measured
only what had been written before it. ECH is appended last (TLS 1.3 requires it)
and Chrome shuffles the extension order, so the slot counted neither the ECH body
nor anything else that followed it; a slot that tried to reach the floor overshot
by the whole body (803 bytes on the wire against the bundle's 517).

`ClientExtensions::encode` now encodes the extensions that follow the padding slot
into a scratch buffer, sizes the pad against the finished hello, and appends them —
the same thing BoringSSL does when it sizes its pad, and the reason its hellos land
on exactly 512. The per-extension encoding moved into one helper so both passes
write an extension the same way.

Both records get their padding back: `padding_to: Some(512)` and
`CHROME_PADDING_AND_ECH_EXT_ORDER`, Chrome 99–107's list with the padding slot and
the ECH the wrapper sends — padding in the order, ECH added outside it, as
BoringSSL's table has it. They pad when the body is short (one connection in four)
and stay above the floor otherwise, which is exactly what the client does; the
desktop chrome131 keeps no padding, whose hybrid-group hello is never near the
floor.

Verified: eight `dump` runs per record — chrome123 and chrome131android carry 512
bytes on the short-body connections with JA4 `t13d1517h2_8daaf6152771_b1ff8ab2d16f`
(the value the bundle's own padded capture measures) and 526/558/590 otherwise with
`t13d1516h2_8daaf6152771_02713d6af862`; chrome107 stays at 512
(`t13d1516h2_8daaf6152771_e5627efa2ab1`) as before. `tools/fingerprint all`:
`headers-diff` SAME everywhere, `hello-diff` SAME everywhere but the shufflers, and
on these two only the per-connection body draw differs. `cargo test --workspace`
(184 + 58) and `cargo clippy --workspace --all-targets` clean. `vendor/rustls/PATCH.diff`
regenerated (1357 lines) and proved with `patch -p1` against a pristine crates.io
copy.

2026-09-18 18:08:47 +03:00

dpi-core

fix(fingerprint): size the padding slot against the finished hello

2026-09-18 18:08:47 +03:00

dpi-detector

feat(fingerprint)!: one profile per shape, and names that carry the version

2026-09-18 15:57:48 +03:00