Confidential computing: attested TLS protocol has critical flaws

What happened?

Researcher Muhammad Usama Sardar from the Technical University of Dresden (TU Dresden) has published two studies demonstrating that the attested TLS protocol, designed to cryptographically bind a server's identity to its execution within a Trusted Execution Environment (TEE), fails to deliver on its security promise. In the first paper, presented at the AsiaCCS 2026 conference under the title Identity Crisis in Confidential Computing, diversion attacks were identified against two state-of-the-art attested TLS protocols. In the second, titled Intra-handshake.fail and accepted for ESORICS 2026, seven intra-handshake attestation mechanisms were analyzed, and none succeeded in preventing relay attacks.

The research was conducted using ProVerif, a widely accepted formal verification tool for symbolic analysis of security protocols. The results have been independently verified, lending robustness to the conclusions. Sardar and his co-authors (Mariam Moustafa and Tuomas Aura in the first study; Viacheslav Dubeyko and Jean-Marie Jacquet in the second) have shown that attested TLS, as currently implemented, fails to provide the level of security that the industry promises.

Why is this important?

Confidential computing is promoted as the technical foundation of the European sovereign cloud. Companies like Intel, with its TDX (Trust Domain Extensions) technology, and Google Cloud claim that their TEEs protect data even from the cloud provider itself. Intel on its product pages promises that TDX “will add safeguards to data sovereignty and governance.” Google Cloud describes its confidential computing infrastructure as offering “complete and auditable control over access to customer data.”

However, attested TLS is the mechanism that allows the client to verify that it is communicating with a genuine TEE before exchanging sensitive data. If this protocol is vulnerable, an attacker can redirect the connection to a malicious server running the same software, without the client detecting it. As Sardar notes: “In confidential computing, you have to trust the hardware manufacturer. There's no way around that. But the protocol layer was supposed to provide everything else. Our research shows it provides much less than assumed.”

Furthermore, in May 2025, The Register reported that management engines operating below the operating system on Intel and AMD chips fall outside what European sovereignty frameworks like SecNumCloud actually evaluate. This left an open question about the upper layer: the protocol designed to prove that the chip itself can be trusted. The new research answers that question, and the answer is not reassuring.

Consequences for businesses and users

The flaw directly affects any organization relying on confidential computing to protect sensitive data in the cloud: regulated sectors such as finance, healthcare, or public administration. The promise of data sovereignty is weakened, and customers must assume that even with TEEs, an external attacker could intercept communications. Cloud providers will need to review their implementations and possibly redesign attestation protocols.

In the first study, Sardar and his colleagues demonstrated diversion attacks against two state-of-the-art attested TLS protocols. A connection intended for a specific server can be silently redirected to another compromised machine running the same software, anywhere in the world, without the client knowing. The original server has done nothing wrong; the attacker simply exploits the fact that the protocol verifies software integrity, not geographic location.

The second study, Intra-handshake.fail, goes further. It examines what the industry calls “intra-handshake attestation,” where evidence is generated during the TLS handshake itself, and tests seven different ways to cryptographically bind that evidence to the underlying connection. None of them succeeded in preventing relay attacks. Even the strongest binding mechanisms (level 3, which binds evidence to the application traffic key) proved vulnerable.

For users, this means that any data processed under the promise of confidential computing could be exposed to malicious intermediaries. Companies migrating sensitive workloads to the cloud relying on these guarantees must reconsider their security strategies. Cloud providers, for their part, face an architectural challenge: there is no simple patch. Sardar suggests that the solution may require fundamental changes in how attestation is defined.

What should readers know?

• Attested TLS does not verify the geographic location of the server, only the software integrity. This allows redirection attacks to any machine running the same software anywhere in the world.
• Relay attacks are possible even with the strongest binding mechanisms (level 3, which binds evidence to the application traffic key).
• The research was conducted using ProVerif, a widely accepted tool for formal protocol analysis, and the results have been independently verified.
• There is no simple patch; the problem is architectural. Sardar suggests that the solution may require fundamental changes in how attestation is defined.
• This finding adds to previous concerns about management engines in Intel and AMD chips, which fall outside European sovereignty frameworks. The combination of both problems calls into question the viability of a sovereign cloud based on confidential computing.