Do you mean that you can prove to a third party that a TLS transcript is accurate? Then the answer is no. TLS authenticates application data with a symmetric algorithm based on a negotiated secret. To verify authenticity, you need to disclose that secret, but you can also use the secret to authenticate a made-up application data stream. I think it's still possible to prove that a decryption is correct if everyone agrees that the ciphertext is genuine, but that's the extent of it.
It is technically possible to verify the authenticity of a TLS transcript without disclosing the secret key. You would need a zero knowledge proof. Where you prove that you know a key that is consistent with the TLS handshake and that is consistent with the symmetric part of TLS.
If the cipher suite used has authenticity in the symmetric part, that proof would be enough.
There are no implementations of this to my knowledge, and all the general zero knowledge proof caveats of speed, proof-size, etc all still apply.
It is definitely possible though. It would be cool to make. Why would anyone need this though?
This seems to be the other direction. I assume the question was about extracting a cryptographic proof from a TLS session that (say) a bank statement downloaded over HTTPS (in HTML, no API) has not been tampered with. I really doubt this is possible, and quite a few TLS users would treat such an unexpected non-repudiation property as a vulnerability in TLS.
The TLS session, and the 'secret inputs' to the TLS handshake, will always give proof that the received message originated from a TLS session from someone who held the private key to the used certificate. Or from someone who received a session key from that private key holder.
If you want to fix this, you need the authenticity of the ciphertext to be proven to the recipient without the recipient being able to transfer it. An interactive zero knowledge proof could maybe do that.
What do you mean? The asymmetric ephemeral keys used in a TLS handhake with Diffie Helman result rather directly into the symmetric session key used by TLS. The signature of the handshake with the certificate links the ephemeral keys to the certificate, and hence the symmetric session key is linked mathematically to the certificate.
That's what I meant with a common understanding of what the ciphertext is.
I don't think this is possible if all you have is your own recording of the ciphertext, with no proof that it was actually transferred over the wire. This is the typical situation with packet capturing at one endpoint only.
