Overview of web proofs

Transport Layer Security (TLS)

TLS (Transport Layer Security) is the cryptographic protocol that powers HTTPS connections. It's no exaggeration to say that almost every bit of information transmitted across global computational networks relies on some form of TLS connection.

Similar to TCP/IP, the TLS protocol involves a client connecting to a server. The combined data sent between the client and server is referred to as the "transcript". When your browser connects to, for example, https://github.com, TLS performs a cryptographic handshake to verify the website’s identity and establish a secure communication channel.

TLS provides three core security guarantees:

1. Confidentiality – Data is encrypted and protected from eavesdroppers
2. Integrity – Data cannot be tampered with during transit
3. Authentication – Server identity is verified through digital certificates

Web Proofs

vlayer web proofs are cryptographically signed attestations of TLS transcripts that enable secure integration of Web2 data into your applications. An external party, called a Verifier, takes a transcript of a TLS connection, authenticates its origin (server), and ensures the data hasn't been tampered with.

What makes web proofs more complex is that the transcript isn't signed by the server. If it was, verifying the signature would be sufficient, and there would be no need for web proofs.

To preserve privacy and authenticate data origin, TLS connections use symmetric encryption. Symmetric encryption is both secure and fast, but it doesn't help authenticate the data, as the encryption key is shared by both the client and server. This makes it impossible to determine whether the data was provided by the client or the server. Thus, the Notary essentially acts as a third party, joining the TLS connection and notarizing its content.

The Notary

The Notary is a third-party server that joins a two-sided TLS connection by maintaining a link with the client while the client connects to the server. From the server's perspective, nothing changes—it still sees the client as a single entity. However, on the client side, the setup is different: the client holds one half of the encryption key, while the Notary holds the other. They collaborate using a Multi-Party Computation (MPC) algorithm to manage the connection, encrypting messages and decrypting server responses.

MPC vs Proxy Mode

TLSNotary supports two notarization modes: MPC and Proxy. MPC mode offers the strongest security guarantees by ensuring no single party ever holds the full session keys. Proxy mode trades some of those guarantees for dramatically faster verification.

MPC mode works by splitting the TLS session keys between the prover and the Notary. Each party holds a share; neither can reconstruct the full key alone. Because the Notary participates in the handshake directly, it can verify the transcript without ever reading its contents, and the prover has no ability to tamper with or fabricate the session. The tradeoff is speed: coordinating key shares across two parties during an active TLS connection requires multiple cryptographic round trips, which adds significant latency and bandwidth consumption.

Proxy mode keeps the TLS session intact between the prover and the target server, but routes it through the Notary's infrastructure. The Notary observes the encrypted traffic as it passes through. Once the session ends, a zero-knowledge proof ties that traffic to the completed TLS session, giving the Notary grounds to sign the attestation without having decrypted anything. Because there is no live cryptographic coordination during the handshake, this is substantially faster. The narrower security assumption is that an attacker cannot control both the prover and the network path through the Notary at the same time.

MPC is the most secure protocol. It remains secure even if the prover is fully malicious. However, it is sensitive to network latency and bandwidth. Proxy mode is much faster, but it is only secure if an adversary cannot both compromise the prover and intercept the verifier's network traffic at the same time. If that assumption matches your deployment, try the difference on your own connection. The rest of this page describes how MPC mode works in detail.

Notarization

The Notary can sign off on the content of the transcript. But how can it verify and sign something it never sees? This is where MPC comes into play. What really happens, is that the client creates a cryptographic commitment of the decrypted transcript, a Merkle Tree root of the transcript. Through MPC, the client proves to the Notary that this commitment matches the encrypted transcript the Notary witnessed. Upon successful notarization, the Notary signs the client's commitment.

Selective Disclosure

TLS connections, like HTTPS, often contain sensitive data, such as login credentials or session keys. Leaking this information could result in account hijacking. Therefore, it's crucial that neither the Notary nor the Verifier can access sensitive data. To mitigate security risks, the client redacts parts of the transcript before delivering the proof.

Verification

The Verifier can then take the redacted transcript from the client, along with the Web Proof signature from the Notary, to authenticate the result.

Key Security Features of web proofs:

• The client cannot produce a fake notarization without the Notary.
• The Notary cannot see the content of the transcript at all.
• The Verifier can only access the redacted transcript.