1

Suppose I download a file hxxps://example.com/somefile.txt with a client that logs everything, including short-term session keys.

Do these logs constitute sufficient proof that the given file has indeed been served by someone having a private key for example.com?

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
bohdan_trotsenko
  • 123
  • 5
  • Is the client which is capturing the traffic and providing the session keys considered trusted? Or is it possible that the client is trying to prove something which never happened by making up data? – Steffen Ullrich Sep 17 '17 at 16:27
  • 1
    My assumption was that the client is not necessarily trusted by the party *verifying* the proof (by examining the logs). Of course I could be wrong. – John Morahan Sep 17 '17 at 16:36
  • Sign the files using gpg or a similar protocol. This can be verified later. – vidarlo Sep 17 '17 at 18:44
  • 2
    Dupe https://security.stackexchange.com/questions/143375/how-to-prove-some-server-sent-some-file-over-https and https://security.stackexchange.com/questions/144906/can-you-prove-to-a-3rd-party-that-a-https-tls-session-took-place – dave_thompson_085 Sep 18 '17 at 05:53

1 Answers1

5

No, such logs would not prove (to a third party) that the given file was served by someone holding the private key.

TLS works in two phases:

  1. The server makes use of its private key to prove its identity to the client and negotiate a session key.
  2. The session key is used to encrypt and authenticate the application data.

The client and server both have access to the session key. The server's private key is not involved in the second phase at all.

So, having negotiated a genuine session key with the server and captured a genuine handshake to prove it, a malicious client could then proceed to use this session key to falsify the rest of the log and claim that the server sent it a different response.

John Morahan
  • 1,971
  • 2
  • 10
  • 9
  • Hi @John, is there a reason for the server and the client to not sign the record (or a HMAC of the record) at the end of the protocol? Same way as chess players sign the sheet at the end of the game. It would provide this proof and at the same time it would serve as an insurance for the server against misbehaving clients. – Tal-Botvinnik May 11 '19 at 15:20
  • I don't know. If I had to guess, I'd say there just wasn't a reason *to* sign it, and doing so would negatively impact performance. – John Morahan May 11 '19 at 18:14
  • I see. I'm thinking about the goal of proving content provenance, see this question: https://security.stackexchange.com/questions/210003/why-isnt-the-record-of-a-tls-data-application-exchange-signed-by-the-server – Tal-Botvinnik May 11 '19 at 18:33