I'm wondering if HTTPS can be used as proof that a server reported an answer.

If I understand correctly, the initial handshake is for HTTPS is the only time that the public/private key of the server is used. After that point a symmetric key is used, so the data passed back is not signed by the origin, just encrypted. Is this correct? If so, is there anyway to get signatures from arbitrary sites, given they support HTTPS?

If as a client I record the entire HTTPS session, is there any way I can prove to a 3rd party that the data I say I received was actually sent by the server?

1 Answer 1


Possibly, sometimes.

What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes.

A cipher suite is split into a number of algorithms for different functionality:

  • Key exhange
  • Bulk encryption
  • Message authenticity

For example, TLS_DHE_RSA_AES_256_CBC_SHA256 would use ephemeral Diffie-Hellman and RSA for the key exchange, AES-256 for bulk encryption, and HMAC-SHA256 for message authenticity.

When the key exchange happens at the start, the long-term RSA key from the certificate is used to sign Diffie-Hellman key exchange parameters. The DH key exchange is used to agree upon a master key. The master key is then used to derive other keys, including 256 bits for the AES key (encryption key) and a number of bits for the authentication key (used in HMAC-SHA256, in this case).

Each record is authenticated using the authentication algorithm defined in the cipher suite. Usually, this is a HMAC hash.

Now, in terms of proving that the data was received after the fact, there are two cases:

  • If a non-ephemeral key exchange is used (e.g. RSA key exchange, not DHE or ECDHE) then the captured traffic can be entirely recovered, including validity of the authenticity hashes, given the private key of the server certificate.
  • If an ephemeral key exchange is used, then even if you get hold of the long-term key (server's private key) after a connection has occurred, you cannot recover the master key, and therefore you can't recover the messages or prove the validity of the messages. This is due to a property known as "forward secrecy", which arises due to the fact that the private elements of the key exchange are generated specifically for that session, and are discarded when the key exchange completes.

If, at the time of the connection, you decide that you do want to prove the content at a later date, you could save the master key of the session somewhere. By giving this key to the 3rd party who captured the conversation, you could show them the contents and they'd be able to see that the authenticity records were valid.

  • Who determines the algorithms used in the cipher suite, client or server? May 6, 2016 at 18:08
  • @SteveEnix The client presents a list of supported cipher suites, and the server picks which to use from that list. In most server implementations this is done by finding the union of the client-supported suites and the server-supported suites, then ranking them based on a configurable preference list and picking the top item. If you want a more in-depth description of the SSL/TLS protocol, check out How does SSL/TLS work?.
    – Polynomial
    May 6, 2016 at 18:12
  • Is the servers private key required? I'm thinking of the situation where we have the Client, Server, and Eve. Eve want's proof that the Client performed an operation with Server. Let's say, authorizing a transaction into a swedish account Eve owns. Eve needs to know that Client isn't spoofing that information back, but doesn't have Servers private key. Can Eve provide a key to use for the exchange, and can Client give the information it gets from server to eve in a way that can be verified by Eve.
    – Ryan Leach
    Dec 9, 2016 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .