Intra Handshake.fail

This repo contains the artifacts for formal specification and analysis of the candidate binding mechanisms for binding in intra-handshake attestation for standardization for attested TLS protocols:

We provide a formal proof of insecurity of all the above candidate binding mechanisms of intra-handshake attestation using the state-of-the-art tool ProVerif and propose a mitigation for the discovered security vulnerabilities. Our study reveals that it may not be possible to achieve strong application-traffic (level 3) binding using intra-handshake attestation alone. This can be exploited for relay attacks, where an attacker makes a client accept an evidence from a different machine. So the client cannot be sure that it connects to its desired server.

We responsibly disclosed the vulnerability in intra-handshake attestation -- as noted in security advisory issued -- to the vendors, which resulted in CVE ( CVE-2026-33697 ) of CVSS 7.5.

Detailed vulnerability disclosure timeline

Comparison with other vulnerabilities in confidential computing literature

Severity is based on NIST metrics .

The comparison of the above with CVSS 7.5 for intra-handshake.fail indicates that attested TLS is not mature yet compared to the rest of the confidential computing stack, and is currently one of the weakest links in the ecosystem. We are investigating further and we are confident there are more high-severity vulnerabilities in intra-handshake attestation which are yet to be discovered.

Figure 1: Simplified relay attack for mechanism #1.

Affected Implementations

Meta's AI : CVE-2026-33697 [ Severity = HIGH (CVSS 7.5) ]

Cocos AI : security advisory [ Severity = HIGH (CVSS 7.8) ] and CVE-2026-33697 [ Severity = HIGH (CVSS 7.5) ]

Edgeless Systems Contrast : security advisory [ Severity = HIGH (CVSS 7.4) ]

CCC Attestation SIG 's adopted project intra-handshake attestation : declared vulnerable to relay attacks and archived

DH shared secret ( gxy ) used as shared secret between client and server

Handshake traffic key ( htsc ) used for encryption of handshake messages

Application traffic key ( atsc ) used for encryption of application data

We consider TLS Server as RATS Attester, which is typical in confidential computing.

Correlation of Evidence to a DH Shared Secret (G1)

Correlation of Evidence to Client’s Handshake Traffic Key (G2)

Correlation of Evidence to Client’s Application Traffic Key (G3)

All analyzed binding mechanisms and the corresponding implementations of intra-handshake attestation are vulnerable to relay attacks.

Early exporter helps achieve level 1 binding.

Our proposed mechanism helps achieve level 2 binding.

It may not be possible to achieve level 3 in intra-handshake attestation alone without additional assumptions.

Implications of Research for IETF SEAT WG

We believe post-handshake attestation alone, such as draft-fossati-seat-expat , can achieve level 3 binding.

The research suggests that recent hybrid proposals (combination of intra-handshake attestation and post-handshake attestation) draft-fossati-seat-early-attestation and draft-ritz-seat-facts may add unnecessary complexity of intra-handshake attestation without adding any security benefit compared to post-handshake attestation alone, such as draft-fossati-seat-expat .

Implications of Research for IETF TLS WG

Remote attestation within the handshake is very dangerous, since to our knowledge, it is one of the highest scored vulnerabilities in confidential computing literature (see this ).

We very strongly recommend the developers and maintainers of intra-handshake attestation to urgently move to post-handshake attestation.

Muhammad Usama Sardar ( : muhammad_usama.sardar at tu-dresden.de)

Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet

Preprint is available here .

Scientific Publication

The work is accepted for publication at ESORICS and should be cited as follows:

Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet. 2026. Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS. In 31st European Symposium on Research in Computer Security (ESORICS) 2026, September 14-18, 2026, Rome, Italy. LNCS, 20 pages.

Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet. 2026. Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS. In 31st European Symposium on Research in Computer Security (ESORICS) 2026, September 14-18, 2026, Rome, Italy. LNCS, 20 pages.

and then use as {{Intra-handshake.fail}}

For citing this repo:

and then use as {{Intra-handshake.fail-repo}}

We gratefully acknowledge the following for insightful discussions on this work:

We also gratefully acknowledge the following who gave feedback on state-of-the-art that we utilize as the basis:

Several others at the IETF, IRTF, and CCC have contributed by providing feedback.

We sincerely thank Karthikeyan Bhargavan, Bruno Blanchet, and Nadim Kobeissi for the foundational formal model of draft 20 of TLS 1.3 in their work .

We use state-of-the-art symbolic security analysis tool ProVerif for the specification of the protocols.

Install the latest version (2.05 at the moment) of ProVerif: see for details. See Section 1.4 of manual for installation options:

via OPAM: Section 1.4.1

from sources: Section 1.4.2 or simply try the script by replacing 2.04 by 2.05

from binaries: Section 1.4.3

The formal model uses the fixed version of diversion attacks in intra-handshake attestation from our work as the starting point to focus on relay attacks in intra-handshake attestation in this work. The rationale is that we consider it more useful to show the added value of this contribution to the community by using the fixed version of diversion attacks in intra-handshake attestation as the baseline, rather than showing the same diversion attacks from ID-Crisis paper , and the discovered CVE (CVE-2026-33697) -- which the analysis could not find -- practically demonstrates the added value. This modeling choice makes it clear that even with the diversion attacks fixed, high-severity relay attacks would still remain in intra-handshake attestation.

Note: Similar to the fixed version of diversion attacks in intra-handshake attestation from our work, we model non-PSK-based handshake. From ID-Crisis paper :

For modeling TLS 1.3, we consider handshakes based on Diffie-Hellman over either finite fields or elliptic curves, represented as (EC)DHE. This is because we are unaware of any publicly available specification or implementation of attested TLS with PSK-based handshakes.

For modeling TLS 1.3, we consider handshakes based on Diffie-Hellman over either finite fields or elliptic curves, represented as (EC)DHE. This is because we are unaware of any publicly available specification or implementation of attested TLS with PSK-based handshakes.

While it would be nice to model PSK-based handshake, the rationale is that the correlation properties studied in this work do not necessarily require it.

The artifacts consider the case of server authentication only, as client authentication is optional in TLS 1.3. No claims are made other configurations.

Artifacts organization

The artifacts are quite flexible for modification and testing of different intra-handshake attestation binding mechanisms by simply changing single rdata parameter in the Client and Server processes. Folder aggregate contains all analyzed and proposed binding mechanisms to select via and uncomment. Other folders contain one specific binding mechanism.

Folders binder1 till binder7 contain code for binding mechanism #1 till #7, respectively.

Folder proposal contains code for our proposed binding mechanism for mitigation.

Folder aggregate contains code for all analyzed and proposed binding mechanisms to select via uncomment.

The name of files within each folder are the same. So the following commands can be used to run any of those.

Running automatic proofs

For completeness, optional commands for running other properties are also provided for each.

With other properties

Generation of traces for failing properties

In order to additionally generate a trace for each property which results in "false", create a subfolder (e.g., traces in the following command) for results before executing.

Then to execute: run as follows:

Subfolder traces will contain the traces in .dot as well as .PDF.

With other properties

To additionally save in log file together with display:

With other properties

To additionally see the Horn clauses generated in ProVerif:

a. use command-line option -test as follows:

b. add one of the following two settings inside the input (*.pv) file:

set verboseClauses = short. to display the Horn clauses

set verboseClauses = short. to display the Horn clauses

set verboseClauses = explained. to additionally display a sentence after each clause it generates to explain where this clause comes from.

set verboseClauses = explained. to additionally display a sentence after each clause it generates to explain where this clause comes from.

With other properties

a. use command-line option -test as follows:

To run in interactive mode:

With other properties

We shared our results with the community for review and to raise awareness on high-severity vulnerabilities and apply appropriate mitigations for the safety of their users:

Practical Cybersecurity list

Agent2agent list thread1 and thread2

UFMRG: thread1 and thread2

CFRG thread1 and thread2

Attestation SIG: thread1 and thread2

TAC: thread1 and thread2

OCP Security: message1 , message2 , message3 and message4

If you know any other relevant mailing list that we should inform, please let us know.

(Japanese) BlackHatNewsTokyo

(Several languages) Hackernoon

Information Security News

TheNextGenTechInsider

(Russian) Security Lab

(Turkish) hardwaremania

If you have written an article on this and would like to be added here, please send me a PR.

Upcoming and Recent Talks and Research Visits

If you are around on any of the following venues of upcoming talks (in reverse chronological order) on topics related to the project, you are very welcome to join/meet.

This FAQ is only for informational purposes to address several requests (#8). A follow-up paper under submission more formally answers these questions.

For binders that contain pubEK (binder4, binder6, and binder7)

FAQ1 . Is "leakage" of privEK necessary for attacks for binder4, binder6, and binder7?

Answer . No, the leakage per se is not necessary. Please see section 7.1.4 in Intra-handshake.fail paper , stating:

The core problem is that if the privEK is accessible to anyone other than an AI agent, it invalidates such a binding. For instance, such a binding is trivially invalid if privEK is provisioned at runtime, since the privEK owner can produce such a binding even without a TEE. Even when the privEK owner remains honest, a vulnerability in the provisioning protocol may be exploited. Moreover, privEK may be extracted on a different machine than the desired one. Finally, privEK may be leaked due to vulnerabilities in the TEE.

The core problem is that if the privEK is accessible to anyone other than an AI agent, it invalidates such a binding. For instance, such a binding is trivially invalid if privEK is provisioned at runtime, since the privEK owner can produce such a binding even without a TEE. Even when the privEK owner remains honest, a vulnerability in the provisioning protocol may be exploited. Moreover, privEK may be extracted on a different machine than the desired one. Finally, privEK may be leaked due to vulnerabilities in the TEE.

FAQ2 . Why is leakage of keys assumed in the threat model?

Answer . This is a standard assumption for formal analysis; for example, see the formal analysis of TLS 1.3 . It is typical in formal analysis to analyze the consequences due to leakage of keys. There is no perfect system and keys may potentially be leaked. In particular, please note that the machine where the key is leaked is not necessarily the client's desired machine. Leakage of a single privEK anywhere in the world is sufficient for binders that contain pubEK . Sec. 6.1 of Intra-handshake.fail paper states:

For RA, we assume that private keys of some machines can be leaked by vulnerabilities within the TEE, such as traditional side channels, transient execution, and implementation errors [34]. The rationale for this assumption is that TEEs typically do not protect against such attacks, as recently demonstrated by BadRAM [26] (CVSS score of 5.3), Fabricked [57] (CVSS score of 5.9), wiretap.fail [58], and TEE.fail [15].

For RA, we assume that private keys of some machines can be leaked by vulnerabilities within the TEE, such as traditional side channels, transient execution, and implementation errors [34]. The rationale for this assumption is that TEEs typically do not protect against such attacks, as recently demonstrated by BadRAM [26] (CVSS score of 5.3), Fabricked [57] (CVSS score of 5.9), wiretap.fail [58], and TEE.fail [15].

For more details, please see Sec. 4.2.1 of ID-Crisis .

Also, attack in Fig. 5(a) of Intra-handshake.fail paper -- for example -- does not require any key leakage at all.

FAQ3 . Side channels are out of scope of TEEs. Why is it assumed?

Answer . Ironically, out of scope actually helps these attacks. Side channels set as out of scope by TEE vendors is exactly the reason they can be exploited by breaking a machine in the basement. For more details, please see Sec. 8.1 of ID-Crisis .

FAQ4 . Fine, but the verifier will distinguish the basement machine from the desired machine?

Answer . To the best of our knowledge, no public cloud provider implementing confidential computing at the time of writing provides a list of legitimate machines that it owns. A basement machine is thus indistinguishable from the desired machine. Please see ID-Crisis and Edgeless Systems GHSA .

FAQ5 . Why are there no assumptions with the properties in the paper?

Answer . Please note that a property that can be proven without assumptions is stronger than the one with assumptions. As a result, assumptions actually weaken the correlation properties. In fact, the correlation properties are meant to evaluate the binding strength . Therefore, correlation properties do not need any assumptions as a baseline. Table 4 in the Intra-handshake.fail paper shows an evidence that some protocols can satisfy some properties under the same baseline without any additional assumptions. For further details, please see Sec. 6.3 of Intra-handshake.fail paper and IETF/IRTF discussions .

FAQ6 . Why are WeakDH , WeakHash , and BadElement considered in relation to RFC9846 for TLS 1.3?

Answer . This is a standard assumption for formal analysis of TLS 1.3. As Sec. 6.1 of Intra-handshake.fail paper says:

For TLS, we assume a threat model similar to Bhargavan et al. [8].

For TLS, we assume a threat model similar to Bhargavan et al. [8].

One has to understand that the goal here is to evaluate the binding strength . Please see IETF/IRTF discussions for further details.

FAQ7 . Under what conditions does the proposed mitigation work?

Answer . Sec. 7.2 of Intra-handshake.fail paper states:

Including both pubEK and the key derived from hs ensures that the adversary would need to have both to get the Evidence accepted by the client. Hence, the protocol does not fail as long as one of privEK or hs is secret.

Including both pubEK and the key derived from hs ensures that the adversary would need to have both to get the Evidence accepted by the client. Hence, the protocol does not fail as long as one of privEK or hs is secret.

The mitigation does not work when both privEK and hs are leaked. The conditions were not formally analyzed in this work. They are analyzed in follow-up paper.

Feedback/ /Critique/Contributions

We would love to have your contributions and feedback (especially critique! yes, this is how the science progresses, but please be genuine!). Muhammad Usama Sardar by email , submit a minimal PR, or open an issue. For your contribution to be dealt promptly, please consider the following remarks:

Remark 1 . This is an official repo of Intra-handshake.fail paper . Not everything attested TLS (and even intra-handshake attestation) needs to be put into this repo. The paper has a specific scope, and everything out of scope has to be dealt with outside of this repo. If you are unsure, please drop an email to .

Remark 2 . This paper is based on the work that concluded around December 2025. Please see vulnerability disclosure report to the IETF on 11 Jan, 2026 as evidence. A huge amount of follow-up work has been done in the past months. Some of that is under submission; some of that is in progress for submission. If the contents of your PR are already answered by those papers, it will not be merged in this repo. As all of our work is available under the Apache-2.0 License, we remain fully committed to making the artifacts from those papers open source under the same license for reproducibility, extensibility, and further research.

Remark 3 . ESORICS has a strict page limit. A total of 20 pages are allowed. A single word over that is desk rejected (including Appendix; it happened with us before). We could put only a limited number of things in 20 pages, while keeping it still readable. Please explain clearly and precisely how your question and/or concern relates to the paper.

Remark 4 . If your proposed code changes the formal model, threat model, and properties, it has to be supported with strong evidence. The reviewers have reviewed a specific formal model, threat model, and properties. Changing those settings is not fair.

Remark 5 . Huge PRs are very unlikely to be merged. Multiple small, precise, concise and to-the-point PRs are much appreciated and more likely to find their way to be merged.

Remark 6 . Please indicate any usage of AI-assistance upfront.

Remark 7 . The acknowledgment list for this repo is locked as the camera-ready version for ESORICS has been submitted. Any further contributions or discussions that the authors find insightful and helpful would be acknowledged in the draft .

Remark 8 . Please be aware that we are currently dealing with several critical (up to 9.8 CVSS) CVEs in intra-handshake attestation. Please keep your contributions focused on the most urgent items. If you do not respond to our questions, your PR will not be merged.

Remark 9 . If possible, please review the extensive discussion in IETF/IRTF and the threads before submitting an issue. If you raise an issue that has been discussed there, we can only refer you back to those discussions.

Remark 10 . Disputes are welcome. Please first quote the statement from the paper that you dispute. Then present your rationale of why you believe the statement is wrong. Please be as precise and concise as possible.

Remark 11 . Remote attestation is a very heated topic. Please be respectful.