Proving authenticity of data accessed over TLS by an untrusted third party

Question

Is there any way an untrusted third party who has access to content from a website over HTTPS can prove the authenticity of the data (i.e. that it was distributed by a server in possession of a specific TLS private key)? The way TLS works makes it such that a packet capture and copy of the master key is insufficient to prove authenticity, since the HMAC key is derived from the master key, which makes it possible to forge the message. Because the third party is untrusted, having them verify the TLS themselves then endorse the authenticity by digitally signing the material is not a solution either.

I'm pretty sure there is no solution under these constraints, but there may be something I missed.

Answer 1

I fully agree with your analysis that such a proof is impossible with common websites:

• The private key of the server is only relevant inside the TLS handshake and can be used to prove that a specific TLS handshake was done with a specific endpoint with a specific key pair.
• After the handshake the transferred data get encrypted and integrity protected. The keys used for this depend only on the master secret. The master secret is the same for client and server which means that the client can also derive the keys used by the server for encryption and integrity protection. Knowledge of these keys enables the client to decrypt and integrity check the data send from the server.
• But since the used algorithms are symmetric they can also be used to encrypt and integrity protect new data. Since there is no additional server-side secret involved in payload protection (i.e. no signature based on the servers private key or similar) it is impossible to detect if data were encrypted by the server or by the client.
• Since no additional authenticity proofs are provided by the underlying network layers (i.e. TCP, IP, ...) nor by default at the application layer (HTTP) one cannot conclude from client provided data that these data actually were generated by a specific server.

Note that there is for many years an ongoing but still active effort to provide such authenticity at the application layer (HTTP) - see Signing HTTP Messages. And there also seem to be implementations of this draft. So with luck a server will already provide such signatures in which case these can be used to proof, that the server (or somebody else in possession of the private key) has send a specific content.