I want to be able to prove that a given content returned by a HTTPS server was in fact served.
I have looked over the whole TLS protocol and I found I can use ServerKeyExchange to get the server's signature of a random string that I can send to the server, in order to start the Diffie-Hellman exchange.
However, I haven't found the way for me to get the server's signature of the content it's serving.
Is there any way to do so?
In TLS, neither the client nor server signs any content. The cryptographic signatures that are used in the initial handshake are meant for authentication: the client obtains some guarantee that it talks to the right server, and (if client certificates are used) the server obtains some guarantee that it talks to the right client. However, neither of these guarantees is transferrable: though the client knows that the data it gets comes from the server, the client gets no proof that could be shown to a third party. That's authentication, not non-repudiation.
Even if the client records everything pertaining to the whole connection (all data bytes sent and received, all the negotiated cryptographic keys, and so on), this proves only one thing: that, at some unspecified point in time, the server was, indeed, a TLS server, and has been involved in at least one TLS connection. Everything else, including all the data puportedly received and sent by the server, could have been fabricated afterwards, so it cannot be a proof (in the cryptographic sense).
Thus, you haven't found a way to "get the server's signature of the content it is serving" for the reason that this signature does not exist. If you want the server to sign things, this must be arranged at the protocol level, inside the TLS tunnel: have the server duly sign the data and send the signature as part of what TLS calls "application data". Of course the server will have to be aware of the operation, and this is not part as normal TLS (HTTPS) processing.
Alternatively, have some bailiff or a similar official connect to the server, obtain the data, and sign it himself, thereby guaranteeing (in a legal way) that the server indeed serves these data content.
The goals of TLS Protocol, in order of their priority, are as
follows:
Cryptographic security: TLS should be used to establish a secure connection between two parties.
Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
Neither the server nor the client sign the data by itself. They only signs part of the handshake with a specific suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake.
Also, from here, you can read:
Standard TLS does not have non-repudiation support.
