Attested TLS Was Supposed to Be the Last Trust Boundary. It Isn't. Formal Methods Show How.

A team led by Muhammad Usama Sardar, together with IBM’s Viacheslav Dubeyko and Jean‑Marie Jacquet, used the ProVerif verifier to model seven real‑world mechanisms that claim to tie a TEE’s attestation report to a TLS 1.3 handshake. Their paper “Intra‑handshake.fail,” accepted at ESORICS 2026, shows that none of the mechanisms—ranging from the client’s TLS nonce (used in Meta’s WhatsApp private‑processing design) to the server’s public key and various nonce combinations—prevent a relay attacker from swapping the encrypted channel while still presenting a valid attestation. The attack works if the adversary extracts the ephemeral TLS private key from the enclave or otherwise interposes during the handshake, letting the client encrypt to the attacker even though the attestation proves the integrity of the original TEE. The disclosure earned CVE‑2026‑33697 (severity 7.5) and three additional CVEs under responsible disclosure with projected scores around 9.1.

The flaw strikes at the heart of the confidential‑computing promise that a remote‑attestation report eliminates the need to trust any party beyond the silicon vendor. Industry groups such as the Confidential Computing Consortium and several IETF drafts (e.g., draft‑fossati‑tls‑attestation, draft‑fossati‑seat‑early‑attestation, draft‑ritz‑seat‑facts) have been pushing “attested TLS” as a single‑handshake solution for cloud‑native workloads. By demonstrating that the binding problem persists across all seven examined schemes, the Dresden team forces a rethink