Why TLS Authentication Stops at the Handshake

TLS does one job extremely well: it authenticates the server to the client during the handshake, using a certificate to prove the server is allowed to use the name on that certificate. That happens once, upfront, before a single byte of application data flows.

The problem is that the web has moved past that model. When your browser loads a modern webpage, the initial HTML often references dozens of resources hosted on different domains. At Cloudflare, those resources are frequently served from domains that differ from the one in the address bar. Each new domain normally means a brand new TLS handshake, with the associated latency and cryptographic cost.

We once tried to solve this by issuing "cruise-liner" certificates with dozens of names on them. That approach had real downsides: it required predicting which subresources a page would request, and it meant problems with one domain could impact unrelated customers. Connection coalescing solves this only when you know the full set of domains in advance. Most of the time, you don't learn that until the browser actually makes the requests.

The core architectural issue is that TLS operates below the application layer. To the TLS connection, the data it carries is opaque — it has no idea which domains the client might ask for next. Only higher-layer protocols like HTTP know that. Yet we still need strong authentication to prevent any website from impersonating another.

What Exported Authenticators Provide

Exported Authenticators (EAs) bridge that gap, offering application-layer authentication that is cryptographically as strong as TLS authentication — and bound to the specific TLS channel over which they travel.

An EA is not a single message but a trio, mirroring the structure the TLS server uses during the handshake to prove certificate ownership:

  • A Certificate message, identifying the entity.
  • A CertificateVerify message, proving knowledge of the corresponding private key.
  • A Finished message, which acts as a MAC to guarantee the first two components haven't been tampered with.

That structure gives you proof that the EA was created by the entity holding the certificate. But proof of creation alone isn't enough. Because EAs operate at the application layer, they don't provide transport. Without extra protection, a malicious TLS server could create its own connection to the legitimate server, relay the client's request, and forward the valid EA back — impersonating any server that supports EAs.

To prevent that, EAs use channel binding. Every TLS connection produces a unique set of keys. EAs are constructed from one of those keys, so they are cryptographically tied to a single TLS session. If an EA is copied from one connection and replayed on another, verification fails. That binding guarantees you are talking directly to the server you intend to reach, not through a relaying intermediary.

From Draft to RFC

Exported Authenticators were first proposed in 2016 and have moved through the IETF standardisation process, which starts with Internet Drafts (I-Ds) and culminates in published RFCs. After years of comment and revision, the TLS Working Group has reached consensus, and the draft awaits a final text submission to the RFC Editors.

Security protocol design is deliberately conservative. Subtle flaws are easy to introduce and can have outsized consequences, as seen in the TLS renegotiation vulnerabilities reported in 2009 and the custom EC(DH) parameters vulnerability from 2012. Design errors get replicated across independent implementations, magnifying their impact.

To minimise that risk, EAs stick closely to the TLS 1.3 handshake design. TLS 1.3 was scrutinised by dozens of experts and subjected to multiple rounds of formal verification, so reusing its patterns lets EAs inherit years of accumulated security expertise.

Formal Verification at Work

The TLS Working Group demanded more than good design instincts before granting consensus. Formal methods — creating a mathematical model of the protocol, its desired security properties, and an attacker — provide strong guarantees against entire classes of attack. Because EAs reuse TLS 1.3 structure, much of the original analysis could be reapplied, giving a significant head start on proving EA security.

The complete formal model and proofs for EAs are publicly available, built using Tamarin, a theorem prover for security protocols. Formal analysis caught subtle edge cases in TLS 1.3's own development, and the same discipline is now being applied to EAs.

Formal methods aren't a silver bullet. Even TLS 1.3, heavily analysed, eventually had an attack found — but that attack landed in a blind spot at the protocol's edges, demonstrating that formal analysis pushes attackers to narrower and narrower territory. As proof techniques become increasingly rigorous, protocol design flaws that remain discoverable become rarer.

What Authentication Becomes Possible

Once the EA draft becomes an RFC, the capabilities unlocked by binding application-layer authentication to TLS begin to take shape. Exported Authenticators open the door to serving extra identities over a connection after it's established, allocated based on actual requests rather than predictions.

They also enable entirely new authentication flows — for instance, extension proposals like OPAQUE-EA build on EAs to support password-based login where the server never sees the password itself. The transition from draft to RFC is the gate that makes such work deployable at Internet scale.