TLS and certificates

STATIC terminates supported HTTPS traffic locally and establishes a second TLS connection to the origin. Keeping these two handshakes separate is essential to understanding which fingerprint a website can observe.

The browser-facing handshake

For an HTTP proxy request, the browser first sends CONNECT host:443. STATIC acknowledges the tunnel, then accepts a TLS handshake inside it. It also accepts direct TLS on the listener. Its rustls server offers h2 and http/1.1 via ALPN. STATIC issues a leaf certificate for the requested server name from a local CA and caches issued leaf certificates in memory.

The browser must trust that local CA to load intercepted HTTPS pages. Only the public certificate should be installed in a trust store. STATIC owns the CA key; the key backend varies by configuration (for example keychain or file-backed storage in the packaged WSL path). The desktop app or operator handles host trust installation. CLI installation explains the platform steps.

The origin-facing handshake

The active profile’s tls section describes hello variants, cipher suites, version bounds, signature algorithms, groups and key shares, extension order, ALPN, session options, and optional HTTP/2 settings. STATIC chooses a candidate, builds a TlsClientPlan, and passes supported fields to wreq and its TLS backend for the new origin connection.

The two connections are shown in the STATIC overview diagram. The local rustls server and outbound wreq client have different responsibilities and different handshake behavior.

The plan is not the wire itself. Some requested extension types are omitted from explicit permutations when the backend cannot model them. Exact ClientHello or JA3 parity cannot be inferred from the JSON alone; capture and inspect actual outbound traffic when parity matters. The tls/fingerprint.rs JA3 helper is scaffolding for tests, not a runtime parser of the browser’s ClientHello.

Variant selection and fallback

On the HTTP/2 downstream path, STATIC tries profile candidates that advertise h2, can try an HTTP/1.1 candidate, and ultimately has a transparent wreq fallback after eligible upstream connection failures. The resulting origin protocol is recorded independently of the client-facing protocol. On the HTTP/1.1 downstream path, it uses an HTTP/1.1 upstream mode.

WebSocket upgrades use separate raw upstream TLS and tunnel code. Do not assume the normal wreq TLS persona applies to them. The Linux eBPF packet path also remains separate from TLS planning.

Read the certificate provider, profile planner, and wreq adapter.