Transport and reachability

The layers inside one connection

Backend WebSockets require an inner encrypted session. The classical variant is Noise_NK_25519_ChaChaPoly_SHA256, client anonymous, backend authenticated by a static X25519 key pinned in the app (with a key id so it can rotate). Without it, the plaintext framing would hand any TLS-terminating relay live capabilities, including a recipient's delivery token, a mailbox's drain key. With it, a man in the middle holding a perfectly valid certificate is not authorised merely by that certificate to complete the pinned inner handshake. The client requires the layer on every socket: the connection is not reported open until the backend has proved itself, plaintext frames are never parsed after establishment, and a decrypt failure closes the socket rather than falling back. The Swift and Node implementations are tested against one byte-exact transcript.

The hybrid inner layer

Build 147’s archived beta includes a hybrid variant: X25519 plus an ephemeral ML-KEM-768 key per socket and an encapsulation to a pinned static backend ML-KEM-768 key. Selection depends on the endpoint descriptor and available KEM pin. The recorded backend supports it; classical descriptors remain a distinct supported case. Build 148 source includes subsequent work and is not the same release.

The ephemeral KEM component is intended to protect recorded transport against later static-key compromise. The static KEM input participates in backend authentication. Those are goals of this custom composition under its assumptions and implementation checks; the separate v5 root-key proof does not prove this transport.

The handshake grows from 50 + 49 bytes in the classical variant to 2,322 + 1,137 bytes in the hybrid variant before outer transport overhead. That changes the observable traffic shape; the application frame-padding rule remains separate. Malformed inputs and authentication failures are rejected, but a common error path alone is not proof of constant-time processing or absence of every oracle.

The dial ladder

On a healthy network the app makes exactly one ordinary dial, cache-first, and nothing else. Only after a reconnect has already failed does the racing dialer probe alternatives (direct, DNS-over-HTTPS-pinned, a bundled origin address, and each adopted relay) as staggered, jittered connects that are each byte-identical to a real session start (an ephemeral-key inner handshake message; nothing identifying). An on-path observer during that window sees the device contact several endpoints in short order: a weaker version of the fingerprint any multi-strategy client has, bounded to one race per outage.

• Liveness watchdog. A quiet connection sends a standard WebSocket ping after 20 seconds of inbound silence, so a throttled-but-open socket that looks connected (the failure that ate messages and rang indefinitely on a throttled path) is detected and the ladder gets the failure signal it needs.
• Throttle-shape detection. A proven-clean baseline followed by a majority-lossy window latches a TLS-over-TCP pin for calls, because a rate-policed UDP flow never trips a simple kill trigger.
• DoH fallback. Two public resolvers are queried concurrently over HTTPS; they learn the client's IP, the Auris hostname and timing, and nothing after. Answers cache for five minutes.

User-run relays

A relay is a door in front of the backend that someone other than Auris operates, configured with the project’s relay tooling on a compatible server. Two modes matter:

Passthrough

The relay multiplexes on the TLS server-name field and forwards raw TLS bytes without terminating the client’s TLS session. The operator carries bytes, sees IP, timing and volume (the same view the user's ISP has) and nothing else. The relay's optional TURN leg on port 443 lets calls survive "throttle everything that is not web traffic".

Terminating

The relay terminates TLS and re-opens it toward the backend. The inner layer provides the content boundary: the operator sees padded opaque frames and should not obtain plaintext routing capabilities or create authenticated application frames under the stated cryptographic assumptions. It can still observe metadata and disrupt delivery.

The design avoids a public relay directory and health/version endpoint; descriptors travel inside encrypted chats and are inert until adopted through an operator-trust disclosure. Lack of a directory does not prevent active scanning or discovery through traffic. Adopted relays join a call's ICE set only when the normal path is already failing, because a TURN leg sees both ends' addresses. Evidence that a network needed a relay is remembered per interface kind for seven days, never per network.

What an on-path observer sees

• Contact with the pinned endpoint (or a relay), the IP pair, and per-frame sizes and timing inside TLS. Frame sizes quantise to 256-byte buckets.
• The keepalive shape every mainstream messenger has: small periodic frames on a quiet connection.
• The dial-race burst during an outage.
• Call-shaped traffic to a peer or relay, with packet sizes and timing, which may reveal activity and speech-related structure even under layered encryption; call traffic shaping is research, not shipped.
• During the hybrid rollout, the larger inner handshake that marks a new client.

What would establish reachability

The client has multiple connection paths. This is an implemented recovery mechanism, not evidence that Auris works on every censored network in September 2026. A country-wide statement requires recent measurements on named networks, devices and versions. This documentation review did not perform in-country field tests or confirm a current public relay fleet.

Useful evidence reports connection success, time to first useful message, sustained delivery, call setup and two-way audio separately. It records failures and denominators, network/provider conditions and test dates. A reachable WebSocket does not establish usable calls; a port number or encrypted handshake does not establish resistance to traffic classification or active probing.

TURN over TCP can recover connectivity where UDP fails, with retransmission and head-of-line costs for real-time traffic. Direct and relayed routes can each perform better on particular networks. The design needs measurements across paths rather than a universal quality ranking.

Known endpoints, hosting networks, distribution channels and traffic patterns remain possible blocking targets. Relay descriptors shared privately can still be discovered. The guide explains relay adoption and its metadata trade-offs; the research section explains how to report measurements without overstating them.