2

So after SSL handshake the master secret is used to securely transfer data encrypted using symmetric cryptography. My question is simple: after SSL handshake, when the server (for example my bank) sends to me message encrypted symmetrically, is the message body (when my computer decrypts it) signed by server's public key or not?

SECOND QUESTION: If answer to question 1 is yes, then if I would receive some data (for example my bank statement) from the server, could I present this data signed by trusted server's key (bank's key) to some third party to prove that this data originated from particular company (because it's signed by asymmetric key that this company is using)?

THIRD QUESTION: If answer to question 1 is yes, then does the message (when decrypted symmetrically) received from server (after handshake) contains timestamp which could be used to prove, in the way similar to one presented in QUESTION 2, that this message originated at this-and-this time (for example a week ago)?

user84415
  • 39
  • 2
  • Message body is "record layer" of TLS, RFC 5246. Did you mean MAC for content integrity? Did you mean some "trusted timestamp" or HTTP server time according to HTTP RFCs? Proving statements about character strings and hashes is doable and practical with libsnark. – Vadym Fedyukovych Jun 23 '18 at 13:57
  • Dupe https://crypto.stackexchange.com/questions/5455 and https://crypto.stackexchange.com/questions/29751 and https://crypto.stackexchange.com/questions/47478 and several on security e.g. https://security.stackexchange.com/questions/187577/can-you-use-https-to-prove-document-was-sent-from-domain . I thought the theory of StackExchange is that people doing searches find existing answers. – dave_thompson_085 Jun 24 '18 at 03:14

1 Answers1

2

..., is the message body (when my computer decrypts it) signed by server's public key or not?

It's not signed. The "message body" (i.e. application data) is only protected by a HMAC. This HMAC relies on a shared secret known both to client and server created together with the encryption key based on the pre-master secret generated during the key exchange. Given that client and server have both the same key for encryption and the sane secret for HMAC the client might create any encrypted application data itself. This means it is impossible for some third party to figure out if the application data in some packet capture originated from the server or was faked by the client.

Steffen Ullrich
  • 1,558
  • 9
  • 11