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.