Opening Book getlantern · circumvention

Censorship decides in the opening of the flow.

So we made the opening the whole game — an evolving repertoire of opening moves for getting through.

examp le.com
↑ the name, split across the boundary — so the inspector never reads it whole
↓   the theory
♚01
the opening is observed; the verdict comes early

How a censor actually decides

A modern censor doesn't read your whole conversation. It glances at the opening of every connection — the TLS ClientHello, the server name, the JA3/JA4 fingerprint, the sizes and timing of the first few packets — files the flow under TLS, QUIC, DNS, WebRTC… applies a policy — and for many, that opening verdict is the whole story.

  • Positive mimicry. Resembling an allowed category works. Resembling nothing in particular does not.
  • Unclassifiable is its own category. High-entropy traffic with no recognisable shape gets throttled or dropped on principle, and increasingly so.
  • The leverage sits in the opening. Which is also the cheap part to change: a few hundred bytes, once per connection.
♟02
a calculated opening, anchored at genuine Chrome

What a gambit is

A gambit shapes the opening — here, a TLS handshake, the worked example throughout: what goes in the ClientHello, how it's framed into records, and how those bytes are split across TCP segments and timed on the wire — fragmenting the hostname across a segment boundary, say, so a name-matching censor never sees it whole. The opening needn't be a ClientHello, though: the same move anchors a QUIC Initial, a DNS query, a WebRTC or HTTP opening just as well (§08).

Anchored at a real Chrome handshake — a fidelity floor, so the handshake is never a poorer imitation of Chrome than Chrome itself — then mutated outward to find a variant that slips past while a real server still accepts it.
♜03
parameters, not code — shippable in hours

A strategy is a parameter set, not code

It's a portable parameter set across three layers — so a move can be reasoned about, mutated, signed, and delivered without shipping a new client.

// a gambit — deltas over a genuine-Chrome anchor anchor: chrome-137 clienthello: { extension_order, grease, padding, ech, … } // what's in the hello records: { size_limit, split } // how it's framed wire: { segment_split: sni_boundary, delay } // how it hits the wire // signed · versioned · anti-rollback

The vocabulary is wide — which extensions, in what (seeded) order; whether to GREASE, pad the hello to a length, offer post-quantum, grease or really negotiate ECH; how the hello is cut into records; where the bytes split across TCP segments and how they're timed. Each knob is a delta over the anchor, so one integer can be the whole move. (This is the TLS dialect's genome; a QUIC, DNS, WebRTC, or HTTP gambit carries the layers of that protocol's opening instead — §08.)

Most moves stay well-formed — a different-but-valid Chrome — and run anywhere. A tagged minority reach for byte-level tricks and are reviewed before they ship. The genome can write more than any one engine plays today: the lean client now runs the well-formed moves, the framing and timing layers, and — on stock BoringSSL, no fork — explicit extension and cipher order plus session-id injection; only the last byte-exact tricks (an exact seed, padding to a length, a raw hello) still wait for the Go engine and a dedicated byte-builder.

♞04
discover once, deploy across both

One parameter set, two execution engines

Because a gambit is just parameters, the same one drives two different engines — and reaches two different client populations.

executor · rust

BoringSSL

Lean, iOS-capable, byte-exact Chrome — the engine on the lightweight client.

executor · go

uTLS

The full ClientHello toolbox, already deployed across the established fleet.

♛05
the server is the oracle; no client phone-home

The repertoire is found by search

No one hand-writes the winning moves. A search — a genetic algorithm guided by a language model grounded in a corpus of known techniques — proposes and mutates gambits, reasoning about why the last attempt failed.

A gambit works if its traffic reaches one of our servers. The server is the oracle — a connection that arrives is the proof.
  • Fitness is server-side. Candidates run head-to-head across comparable users; whichever reaches more, wins.
  • Servers rotate. So a blocked address can be told apart from a blocked strategy — search and fleet co-evolve.
  • Fitness penalises standing out. Reward getting through and penalise becoming conspicuous. A strategy that wins by creating a new anomaly has not won.
  • There is no end state. The censor adapts, so the repertoire has to keep moving.
♝06
power where it pays, fidelity where it counts

Why the fingerprint code stays native

The parts that must look byte-exact — the real TLS fingerprint — stay in native, audited code, where they can be exact and stay current. Most evasion is a recombination of those vetted building blocks; a sandboxed module is held in reserve for genuinely novel logic.

♙07
opening theory — the rest is a different game

Where a gambit stops

A gambit shapes the opening, and only the opening — the hello, its records, the first few segments. Once the handshake completes the gambit is silent; the rest of the connection runs as the transport sees fit.

That's the wager. A censor files its verdict on the first few hundred bytes; if the opening passes, the opening was the game. Shaping the long tail is expensive and high-volume, and the opening is cheap — a few hundred bytes, once. So the book is opening theory: it spends its moves where the verdict is made, and leaves the middlegame to the transport.

Room is reserved for post-opening moves, unused for now, against the day a censor learns to read past the opening.
♘08
the board is wider than one protocol

Beyond TLS: other protocols, other ports

The opening a censor reads isn't always a TLS hello — it's whatever the protocol leads with, and the verdict lands on that opening just the same. A QUIC Initial packet, its ClientHello buried in encrypted crypto frames. A DNS query — resolution itself, the thing every connection needs first. A WebRTC call's STUN binding and DTLS handshake, the shape of every video meeting. An HTTP request that can ride a CDN it shares with half the web. A remote-desktop or mail session that opens in the clear before it upgrades. Each is a board the censor has its own reasons not to wall off — block it and you block the real thing that lives there.

So the repertoire generalizes past TLS: a gambit need not be a ClientHello. Anchor at a genuine opening of that protocol, mutate outward, and let the same discovered book — signed, versioned, scored by what reaches the server — find the moves. TLS is simply the dialect we play first; QUIC, DNS, WebRTC, and HTTP are the same game on a wider board. The protocol, and the port it speaks on, become part of the move — chosen for the company they keep.

⚐09
from a fragment to a living book

Roadmap

P1Shape the opening on the wire — SNI-boundary fragmentation + timing. built
P2The signed gambit genome + the ClientHello knobs. built
P3Gambits computed per connection.
P4Byte-level moves for the hard cases.
P5The discovery loop, running against the live fleet.