TLSNotary Proof

A TLSNotary Proof leverages Secure Multi-Party Computation (MPC) to split the TLS session key between the client (the Prover) and a semi-trusted third party (the Notary). This allows the Notary to cryptographically attest that the data presented by the Prover was indeed the exact, unaltered data stream from a specific TLS session with a target server, without the Notary seeing the full data itself. The process hinges on the Page Signer component, which produces a verifiable signature over the HTTP request and response.

The primary application is providing verifiable off-chain data to blockchain oracles and smart contracts. For example, a DeFi protocol needing a stock price can use a service that generates a TLSNotary Proof to attest that the price was fetched directly from a reputable financial data API (like Bloomberg or Nasdaq). This creates a cryptographically verifiable data feed, reducing reliance on pure trust in oracle nodes and mitigating risks of data manipulation at the source-fetching layer.

The protocol involves three distinct roles:

• Prover: The entity (e.g., an oracle node) that initiates the TLS session with the target website and wants to prove the data it received.
• Notary: A separate, semi-trusted service that holds a share of the session key. It collaborates with the Prover via MPC to generate the attestation without learning the full session data.
• Verifier: The entity (e.g., a smart contract or a user) that receives the final proof and can cryptographically verify its validity against the Notary's public key and the server's certificate.

TLSNotary Proof offers specific advantages for trust-minimized systems:

• Data Integrity: Provides cryptographic proof that data came unaltered from a specific TLS endpoint.
• Source Authenticity: Binds the data to the official server's TLS certificate, verifying the source.
• Privacy-Preserving: The Notary does not see the plaintext data, only cryptographic commitments.
• Standard Compliance: Works with standard TLS 1.2/1.3, requiring no cooperation from the data source.

While powerful, the protocol has inherent constraints:

• Notary Trust Assumption: Requires a semi-trusted Notary that does not collude with the Prover.
• Prover Trust: The Verifier must trust the Prover to correctly execute the MPC protocol.
• Source Trust: The proof only verifies data came from a server; it does not verify the correctness of the server's own data.
• Complexity & Cost: The MPC process is computationally intensive, adding latency and cost compared to a simple API call.

The protocol's security model relies on a trusted third-party Notary server. This Notary holds a private key share and participates in a Multi-Party Computation (MPC) with the client to sign the proof. If the Notary is compromised or colludes with the server, it can forge proofs or violate client privacy. This introduces a semi-trusted or 1-of-N honest assumption, which is a central point of failure compared to trustless systems.

TLSNotary's core mechanism depends on accessing the pre-master secret from a TLS 1.2 handshake. This creates two major limitations:

• Protocol Dependency: It is incompatible with TLS 1.3, which fundamentally changed the key exchange to protect the master secret from all parties, including the client. This restricts its use to legacy or specific TLS 1.2 endpoints.
• Client-Side Control: The client must be instrumented to extract and share the session secret, which is not possible with standard browsers or off-the-shelf HTTP clients.

While the web server sees only encrypted traffic, the Notary server learns the plaintext data during the proof generation process. This is a necessary part of the MPC protocol. Therefore, the client's query and the server's response are exposed to the Notary, requiring the client to trust the Notary not to misuse this information. Techniques like salting or encrypting sensitive payloads can mitigate but not eliminate this exposure.

A TLSNotary proof cryptographically attests that a specific piece of data came from a specific web server at a specific time (data provenance). It does not cryptographically verify the semantic truth, accuracy, or business logic of the data itself. For example, a proof can verify that a JSON response containing {"price": 100} came from api.example.com, but it cannot prove that 100 is the correct or fair market price. This shifts the trust from the data source's integrity to its operational honesty.

Deploying TLSNotary securely is operationally complex:

• Notary Infrastructure: Running a secure, highly available Notary service with key management and protection against side-channel attacks is non-trivial.
• Client Hardening: The client application must be modified to integrate the TLSNotary library, handle secret shares, and communicate with the Notary, increasing attack surface.
• Auditability: The entire toolchain, including the MPC code and the instrumented TLS library, must be audited for correctness to ensure proofs are sound.

Understanding TLSNotary's trade-offs is clearer when compared to other oracle designs:

• Authenticated APIs: Require the data source to cryptographically sign data, but need their cooperation.
• Committee-based Oracles: Use economic stakes and consensus among many nodes, avoiding a single Notary but introducing latency and cost.
• Zero-Knowledge Oracles: Can prove statements about web data without revealing it to any third party, but are currently more computationally intensive and complex to construct for arbitrary websites.

A Zero-Knowledge Proof is a cryptographic method where one party (the prover) can prove to another (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. TLSNotary is a specific type of ZKP applied to web traffic.

• Key Property: Enables verification without data disclosure.
• Relation: TLSNotary proofs are a practical implementation for proving the content of HTTPS sessions.

Transport Layer Security (TLS) is the cryptographic protocol that provides secure communication over a computer network, most notably for HTTPS. It ensures privacy and data integrity between two communicating applications.

• Role in TLSNotary: The protocol creates the session that a TLSNotary proof attests to. The proof cryptographically verifies that specific data was transmitted within a TLS session without exposing the session keys.

A blockchain Oracle is a service that provides external, real-world data to smart contracts, which cannot access off-chain information natively. TLSNotary proofs are a critical technology for creating verifiable oracles.

• Application: Used to prove that an oracle fetched specific data from a trusted HTTPS endpoint, bringing cryptographically verified real-world data on-chain.
• Example: Proving the exact price feed or sports score retrieved from an API.

In the context of TLSNotary, a Witness is a trusted third party that participates in the protocol to observe and partially sign the proof, ensuring the prover cannot forge the attestation. The witness does not see the plaintext data.

• Function: Acts as an impartial auditor of the TLS handshake and session.
• Security Model: Prevents a single malicious party from creating a false proof, relying on a 2-of-2 threshold signature scheme.

Selective Disclosure is the ability to reveal only specific, necessary parts of a dataset while keeping the rest private. TLSNotary proofs enable this for web-sourced data.

• Mechanism: A prover can generate a proof that a webpage contained a particular data point (e.g., "the price was > $50") without revealing the entire page content or other sensitive information on the site.
• Use Case: Essential for privacy in DeFi oracles and identity verification.

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and zk-STARKs (Scalable Transparent Arguments of Knowledge) are advanced forms of zero-knowledge proofs. They are distinct from, but conceptually related to, TLSNotary.

• Comparison: While TLSNotary proves facts about a specific TLS session, zk-SNARKs/STARKs are general-purpose for proving arbitrary computations. They are often used for transaction privacy and scaling (ZK-Rollups).
• Trade-off: TLSNotary is optimized for a specific web data use case, whereas zk-SNARKs/STARKs are more flexible but computationally intensive.