fully trustless proofs - when possible?

[milahu]

in what situation would a "fully trustless proof" work?

"fully trustless proof" sounds like an impossible task because TLS itself does not provide data integrity TLS provides only session key integrity

sounds like this would require the server to provide data integrity by providing signatures of the sent data

tlsnotary.org says

What's the catch? TLSNotary does require a trust assumption. A Verifier of a proof must trust that the Notary did not collude with the Prover to forge it. This trust can be minimized by requiring multiple proofs each signed by different Notaries. In some applications the Verifier can act as the Notary themselves, which allows for fully trustless proofs!

A Verifier of a proof must trust that the Notary did not collude with the Prover to forge it.

this is already a hard task...

see also

Does a trace of SSL packets provide a proof of data authenticity?

The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake.

The actual connection is encrypted and authenticated using symmetric operations. Anybody who knows those symmetric keys can forge a ciphertext that decrypts and authenticates successfully with these keys. So you can't prove which data was exchanged.

Is it possible to store / record HTTPS client auth traffic as a signed document?

TLS does not provide non-repudiation. The signature is proof that you communicated with the other party, but it is not proof of when the communication took place (because gmt_unix_time is deprecated) and it is not proof of what was communicated, only that the communication took place

After the handshake, both sides have the same symmetric keys for both sides. Both sides can generate a transcript that shows the other side sent, encrypted and authenticated with the expected keys, any data. There is no way to know whether that is true or not.

To achieve non-repudiation, you would need to add a digital signature at the end of the connection, signing a hash of the entire connection until the disconnect message was received. But there is no such feature in TLS.

no site is signing the application traffic with their own private key but encryption and MAC are only based on a shared secret created during the key exchange.

Validate HTTPS traffic at later time

TLSv1.3 explicitly prevents this kind of traffic analysis "at later time", i.e. without having the internal state of both sides. This is called "perfect forward secrecy" (PFS).

[sinui0]

because TLS itself does not provide data integrity

TLS does provide data integrity, but only between the Client and Server.

And yes, it's true that TLS does not provide non-repudiation.

TLSNotary modifies the client side of the connection using multi-party computation in order to provide the properties claimed on the website. The crux of how this works is in the 3-party key exchange. This provides data provenance/authenticity because the Client/Prover is not in possession of the Server MAC key.

By "fully trustless proofs" we are referring to having no trust assumption between the Prover and Verifier. There is still trust in the TLS certificate chain, ie the certificate authorities, as with any TLS connection.

[milahu]

By "fully trustless proofs" we are referring to having no trust assumption between the Prover and Verifier.

does "no trust assumption between the Prover and Verifier" mean that the verifier is forced to play a passive role? so the verifier cannot initiate requests?

so prover and verifier can still collude to create fake proofs (obviously) so we still need multiple verifiers (which can still collude...)

The crux of how this works is in the 3-party key exchange. This provides data provenance/authenticity because the Client/Prover is not in possession of the Server MAC key.

MPC-TLS

The Prover is not solely capable of constructing requests, nor can they forge responses from the Server.

so the verifier works like a man-in-the-middle between prover and server effectively breaking the "symmetric encryption with a shared key" property of TLS but from the TCP traffic flow, the prover is the man-in-the-middle between server and verifier

nice idea : ) but for my app (p2p web scraper) it will be better to use a https proxy or vpn server as a tunnel because a passive verifier-role would be too limiting for my app

[th4s]

Hi :wave:

does "no trust assumption between the Prover and Verifier" mean that the verifier is forced to play a passive role? so the verifier cannot initiate requests?

Yes, the verifier does not initiate any requests. No trust assumption means, that the verifier will verify the correctness of the encrypted TLS traffic, the certificate chain, as well as some application-specific assertions over parts of the plaintext, all by himself.

so prover and verifier can still collude to create fake proofs (obviously) so we still need multiple verifiers (which can still collude...)

What you refer to is probably this setup. In this setup there is the trust assumption that prover and notary do not collude. If you do not trust the credibility of a single notary you could indeed require multiple different notaries.

so the verifier works like a man-in-the-middle between prover and server effectively breaking the "symmetric encryption with a shared key" property of TLS but from the TCP traffic flow, the prover is the man-in-the-middle between server and verifier

I would avoid calling it man-in-the-middle, because this is exactly what it is not. The three-party handshake breaks the TLS key into two parts, one for the prover and the other one for the verifier. The prover with the help of the verifier communicates with the server and forwards all (encrypted) traffic to the verifier. Because the prover does not have the full TLS key he has to cooperate with the verifier for encrypting requests and decrypting responses to/from the server.