Outer-Inner TLS (OI-TLS)

Introduction DPI appliances routinely block HTTPS connections based on TLS ClientHello contents such as SNI, ALPN, cipher lists, or JA3 fingerprints (). OI-TLS inserts an entry node between the client and backend. On-path observers see only a normal TLS 1.3 connection to an IP address, whereas the true ClientHello is tunneled inside the outer channel.

Motivation and Relationship to Existing Work Encrypted Client Hello (ECH) protects SNI within a single TLS handshake but requires clients, DNS, and origin servers to support ECH and to deploy DNSHPKE keys. OI-TLS targets operators that can deploy a terminating entry proxy in front of unmodified backends; only the entry node needs changes. OI-TLS also hides the entire ClientHello (cipher list, JA3, ALPN), not only SNI. Unlike domain-fronting techniques, OI-TLS does not rely on CDN misconfiguration; entry nodes are explicit infrastructure.

Terminology OuterTLS – TLS 1.3 session between client and entry node, no SNI, certificate bound to entry IP. InnerTLS – TLS 1.3 (or 1.2) session between client and backend, carried as application data inside OuterTLS. Entry Node – Frontend proxy that terminates OuterTLS, parses the inner ClientHello, selects a backend, and relays InnerTLS records. Backend – Origin server that terminates the InnerTLS connection.

Architecture Client --OuterTLS--> Entry Node --InnerTLS--> Backend. 1) DNS discovery: client queries `_oitls.example.com TXT "v=1 ttl_outer=10"` or an HTTPS RR `example.com HTTPS ... oi-tls=1` to learn that OI-TLS is supported. 2) OuterTLS: client connects to the entry IP (A/AAAA answer) with TLS 1.3, no SNI, ordinary extensions. 3) InnerTLS: client generates a standard ClientHello with the real SNI and transmits it as encrypted application data. 4) Session lifetime: outer tunnel normally stays up for the session, but entry nodes MUST enforce an advertised TTL and drop tunnels where the inner handshake never starts. After the inner handshake completes, entry nodes MAY close the outer tunnel.

DNS Signaling Clients SHOULD retrieve `_oitls` TXT/HTTPS records using DoH/DoT (, ) to hide the signal from DPI; UDP queries still work but leak metadata. The TXT record may carry parameters such as outer TTL or ALPN hints. The entry IP is taken from the original A/AAAA answer. If no OI-TLS record exists, the client falls back to plain TLS.

Deployment Considerations Entry Integration: OI-TLS can run within HAProxy/nginx modules or standalone proxies. The entry node inspects only the first inner record. Backend Requirements: none—backends see an ordinary TLS session and can host HTTP/1.1, HTTP/2, WebSocket, etc. Certificate Validation: OuterTLS MUST use trusted certificates (e.g., ACME for entry IPs). DNS discovery SHOULD use trusted DoH/DoT. OuterTLS TTL: entry nodes MUST enforce an advertised TTL (e.g., 5–10s) and drop tunnels with no inner ClientHello. After the inner handshake, outer tunnels MAY be closed. Rate Limiting: operators SHOULD cap concurrent OuterTLS sessions and inner handshakes to mitigate CPU-based DDoS.

Implementation Status Reference code and Docker labs are available at https://github.com/EvrkMs/OI-TLS. The labs include a baseline HTTPS flow where DPI observes SNI and an OI-TLS flow where DPI’s SNI extractor fails. These labs demonstrate the logic and are not production SDKs; real deployments require separate client/entry implementations.

Security Considerations OI-TLS hides ClientHello metadata but does not defend against IP blocking, volumetric DDoS, or backend compromise. Entry nodes become trusted points of failure; if compromised they reveal all SNI values. Proper certificate validation and DoH/DoT are required to avoid MITM. Entry nodes must be protected via Anycast, load balancing, and rate limiting.

IANA Considerations This document makes no requests of IANA.