Attestation Proves Code, Not the Server You Meant

Confidential computing’s promise breaks at the point where teams try to turn a trust check into a location or sovereignty guarantee. Attested TLS can confirm that code looks genuine and unmodified, but it does not reliably prove the client is talking to the intended machine or below-OS stack, so the standard “attest then release secrets” flow can still hand data to the wrong host. Independent research verified the flaw in two attested TLS designs and found diversion and relay attacks that redirect a connection to another machine without the client noticing. The work, including Identity Crisis in Confidential Computing and Intra-handshake.fail, covers Intel TDX, Google Cloud Confidential Computing, and management-engine-dependent environments on Intel and AMD silicon, with CVE-2026-33697 referenced in the reporting. The forward risk is simple: sovereignty claims built on remote attestation may be unprovable even when the attestation succeeds. For operators that use confidential computing to decide whether to release secrets, attestation is not enough proof that the service is the right physical or sovereign one.

Part of the PlainSec briefing for 2026-07-05

Sources