Andy is going to connect to a server Selma over TLS. Later, Andy would like to be able to publish everything (the ciphertexts, the plaintexts, all his keys) and prove to a mediator what data he sent to Selma over TLS; or prove what data Selma sent to him over TLS. Is there any way I can do this?
More specifically: We need some way that a third party could look at the information Andy published and convince themselves that he's not lying. Selma is an existing, unmodified TLS server; it can't be modified. Assume that Selma is trusted: i.e., the third party will be willing to trust that Selma isn't trying to fool them and isn't in collusion with Andy. However, the third party doesn't trust Andy: they'll want a way to verify Andy is not lying about what data was sent/received over the TLS connection. It's OK for Andy to use some clever/sneaky/weird combination of TLS options and features and random values/nonces, if that helps achieve this goal. It's OK to use client certs. Andy is willing to reveal his private key and all session keys when he publishes his data.
Is there a way to achieve these goals and enable Andy to prove what data was sent/received over the TLS connection with Selma?
I do know it might be possible for Andy to later prove that he did open a TLS connection with Selma (because the TLS protocol has Selma sign or decrypt something). But that's not enough for my purposes; I want Andy to be able to demonstrate what data was sent over the TLS connection. It's not enough to merely demonstrate that a TLS connection between Andy and Selma existed at one point in time.
My analysis: I can't see a way to achieve this goal. It seems we'd need a way to make Selma sign something that depends upon the application data. However, in the TLS protocol, what Selma signs seems to be independent of the application data. The Finished message has a running hash of the contents of all of the handshake messages, but it doesn't seem to include any of the application data, and in any event it isn't signed. I looked at multiple key exchanges and at features like session renegotiation and false start, but still couldn't find a way to do it. I've seen Does a trace of SSL packets provide a proof of data authenticity?, which says the answer is no if Andy and Selma don't do anything strange. Does the answer change if Andy has the freedom to abuse the protocol or send whatever he wants?
To rephrase: if the answer to my question is "it can't be done", that means that the data is fully deniable: regardless of what Andy does, Andy can always change his mind and later come up with a fake transcript and lie about what data was sent/received. On the other hand, if the data isn't deniable in some circumstances, then that presumably must imply some kind of "yes" answer to my question.