Attested TLS relay flaws show where confidential computing binding fails

At a glance

What this is: This is Anjuna’s analysis of a peer-reviewed attested TLS flaw showing that some protocols can be relayed because attestation evidence is generated too early to bind safely to the eventual encrypted channel.

Why it matters: It matters because identity and trust decisions for enclaves, workloads and confidential computing deployments cannot rely on proof that is valid in general but detached from the specific session being established.

Context

Attested TLS is a trust-binding pattern for confidential computing, used to prove that a client is talking to a genuine enclave before sensitive traffic is exchanged. The problem in this article is not whether attestation works in principle, but whether it is tied to the right moment in the connection lifecycle. For teams governing workload identity and machine-to-machine trust, that distinction determines whether the proof protects the session or merely documents the software state.

The article’s core point is that a sound root of trust can still be composed incorrectly. When evidence is generated during the handshake but the channel key does not yet exist, the proof and the protected traffic are separated in time, which creates a relay window. That makes this a governance issue as much as a protocol issue: teams need to know which trust assertions are session-bound and which are only enclave-bound.

Key questions

Q: What breaks when attested TLS evidence is generated during the handshake?

A: The binding between enclave proof and the eventual encrypted channel breaks. An attacker can relay the attestation challenge to a genuine enclave, capture valid evidence, and then direct the client’s traffic elsewhere. The result is a trusted proof attached to the wrong connection, which is why attestation must be bound to session creation, not merely to enclave identity.

Q: Why does relay risk remain even when enclave attestation is valid?

A: Because validity of the evidence only proves that a real enclave signed something, not that the proof belongs to the channel the client is using. If the session key does not exist when the evidence is produced, the attacker can separate proof from transport. The control problem is channel binding, not attestation integrity alone.

Q: What are the signs that attestation and channel binding are not aligned?

A: Look for designs where attestation completes before the session key exists, where the same evidence can be replayed across connections, or where a client accepts enclave proof without tying it to a unique session. Those patterns indicate that a relay attack could succeed even though the attestation evidence itself is genuine.

Q: Should teams treat enclave attestation and secret provisioning as separate controls?

A: Yes. Attestation should establish that the enclave is genuine, while secret provisioning should make possession of the session credential contingent on that success. When those steps are separated, a relayed or diverted endpoint never receives the authenticating material, which closes the attack path described in the article.

Technical breakdown

Why intra-handshake attestation can be relayed

Intra-handshake attestation asks a TEE to produce evidence while the TLS session is still being negotiated. That evidence may be cryptographically valid, but it is not yet cryptographically tied to the final session key carrying application data. An attacker can relay the attestation challenge to a real enclave, collect genuine proof, and then terminate the client connection on a different endpoint. The client sees valid attestation, but the traffic lands elsewhere. The flaw is therefore in composition, not in the attestation primitive itself.

Practical implication: do not treat valid enclave evidence as proof of the specific channel unless the protocol binds both to the same session state.

Why timing, not hardware, is the weak point

Confidential computing hardware such as Intel TDX, AMD SEV-SNP, and Arm CCA still provides isolation and measured execution. The research described here does not dispute that root of trust. Instead, it shows that evidence produced before the session key exists cannot be retroactively joined to the encrypted channel in a way that stops diversion. In security design terms, the problem is a lifecycle mismatch: the proof arrives before the asset it is supposed to protect has been instantiated.

Practical implication: evaluate whether your attestation design proves enclave integrity only, or enclave integrity plus channel continuity.

Why attest-then-provision is stronger than attest-inside-handshake

The alternative pattern is to attest first, then release a secret only to enclaves that pass, and finally derive the private session from that secret. In this design, possession of the key becomes evidence that attestation already succeeded, so a relayed endpoint cannot complete the session unless it was actually provisioned. The security property shifts from proving a claim during transport to making the transport itself dependent on prior proof. That is a cleaner trust model for workload identity and confidential computing workloads.

Practical implication: prefer secret provisioning after attestation when the goal is to prevent endpoint diversion rather than merely verify code integrity.

Threat narrative

Attacker objective: The attacker’s objective is to make a client trust and encrypt to the wrong machine while preserving the appearance of valid enclave attestation.

1. Entry occurs when an attacker relays an attestation challenge from a client to a real enclave during the TLS handshake.
2. Credential access is replaced by proof harvesting, because the attacker obtains genuine attestation evidence without controlling the attested machine.
3. Impact follows when the client encrypts traffic to the attacker-controlled endpoint instead of the intended enclave, enabling silent connection diversion.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Attestation timing is now a trust-governance issue, not just a protocol detail. The flaw described in this article shows that valid enclave evidence can still be the wrong evidence if it is produced before the session it is supposed to protect exists. For identity teams, that means the question is no longer simply whether attestation is present, but whether the trust assertion is bound to the correct lifecycle moment. The practitioner conclusion is to govern attestation as a session control, not a compliance checkbox.

Confidential computing remains sound, but composition errors create avoidable exposure. The article is careful to separate hardware trust from protocol design, and that distinction matters. Teams that collapse those two layers will overreact to a narrow flaw or underreact to a real binding failure. The stronger governance posture is to treat enclave integrity, connection binding, and secret release as separate control decisions. The practitioner conclusion is to validate the sequence, not just the primitives.

Session-bound trust is the named concept this article sharpens. A proof of software integrity is not the same as proof of channel ownership, and this research makes that distinction operational. In environments where workloads, services, and confidential computing enclaves exchange sensitive data, identity assurance has to extend beyond evidence generation to evidence-to-channel binding. The practitioner conclusion is to redesign trust so the channel inherits the attested state instead of merely receiving it.

Attest-then-provision is the safer operating model for enclave trust. If a machine cannot receive the secret until attestation succeeds, diversion attacks lose the key material they need to complete the impersonation. That changes the governance question from “can we verify the enclave?” to “can an unverified endpoint ever obtain the session credential?” The practitioner conclusion is to prefer provisioning models where attestation gates secret release.

This is a reminder that workload identity can fail through timing, not just theft. Security leaders often focus on exposed secrets, but here the secret may be fine while the binding logic is wrong. That expands the governance lens for confidential computing and NHI-adjacent workload trust. The practitioner conclusion is to review whether your identity model assumes authenticity at handshake time when it should enforce authenticity before session creation.

What this signals

Session-bound trust is becoming the decisive control point for confidential computing. Security teams should assume that any proof generated before a session exists can be valid yet still insufficient. The programme question is no longer whether attestation exists, but whether the binding logic survives relay, replay, and diversion attempts.

Workload identity needs lifecycle-aware binding, not just stronger evidence. In practice, the safe design pattern is to gate secret release on successful attestation and then derive the session from that secret. That shifts the trust decision from a message in transit to a control that the verified enclave must possess before communication begins.

For practitioners

• Audit attestation timing across all enclave connections Map whether attestation evidence is created inside the TLS handshake or before any session exists, then identify where the proof and the channel are not bound together.
• Move secret release behind successful attestation Require enclave verification before any shared secret, token, or session material is provisioned, so a relayed endpoint never receives authenticating credentials.
• Test for relay and diversion resistance Simulate a relayed challenge against your confidential computing path and confirm that the intended enclave is the only endpoint able to complete authentication.
• Separate enclave integrity checks from channel-binding checks Treat measured boot or attestation results as one control and channel ownership as another, then verify that both are required before sensitive traffic is accepted.

Key takeaways

• The article shows that attested TLS can fail when evidence is generated too early to bind to the session it is meant to protect.
• The flaw is a composition problem between attestation and channel establishment, not a failure of confidential computing hardware or remote attestation itself.
• Security teams should prefer designs where attestation gates secret release and the session inherits trust from the verified enclave.

Key terms

• Attested TLS: Attested TLS is a trust pattern that combines remote attestation with a TLS connection so a client can verify an enclave before exchanging sensitive data. Its security depends on whether the attestation evidence is cryptographically bound to the same session that carries application traffic.
• Remote Attestation: Remote attestation is the process of proving, with cryptographic evidence, that a workload is running inside a specific trusted environment. It matters in AI governance because it replaces a verbal trust claim with checkable proof that the inference session used the intended protected boundary.
• Channel Binding: Channel binding ties an authentication session to the underlying secure transport so that the session cannot be replayed on a different channel. It is a control against relay attacks, but it only helps when the receiving service enforces it consistently.
• Attest-Then-Provision: Attest-then-provision is a control pattern in which a secret is released only after a target enclave has successfully attested, and the resulting session is derived from that secret. It reduces relay risk because the authenticator exists only inside the verified environment.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to operational security decisions across modern environments.