ostp/ostp-core
ospab 89a5eea20d §C: protocol version gate via key derivation (reject old clients)
The base already derives all secrets from the access key, so derived
secrets were never the gap — the gap was that nothing distinguished a
current handshake from an older-format one, so an old client could still
connect to a new server.

Rather than the plan's literal "plaintext version byte before the crypto
layer" (which would add a constant, DPI-visible marker and defeat the
project's stealth north-star), fold the version INTO the HKDF derivation:

- Add PROTOCOL_VERSION (= 4 for 0.4.0), mixed into the IKM of
  derive_all_secrets so a different version yields a completely different
  obfuscation key / psk / padding. No marker ever appears on the wire —
  the output stays indistinguishable from random.
- A pre-0.4.0 peer derives a different obfuscation key, so the 0.4.0
  server cannot recover its handshake header and drops it as an
  unauthorized probe. Bump PROTOCOL_VERSION on any future wire break.

Verified:
- cargo test -p ostp-core: 36/36 incl. new test_protocol_version_gates_
  old_clients (old-version obf key does NOT recover the session_id).
- Loopback E2E: new client <-> new server connects and tunnels HTTPS
  (curl via SOCKS5 returns egress IP).
- Old v0.2.98 client vs new server: handshake times out / aborts, server
  accepts 0 clients — exactly the plan's §C criterion.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-27 16:57:23 +03:00
..
src §C: protocol version gate via key derivation (reject old clients) 2026-06-27 16:57:23 +03:00
Cargo.toml feat: implement custom Reality protocol with ChaCha20Poly1305 and X25519 2026-05-29 15:00:17 +03:00