4

I am inspecting the TLS(1.2) protocol, and I notice that after the key exchange (handshake), data applications flows from server to client freely (because they have the session key).

However, I noticed that this content (say, the server response to a GET request) is NOT signed digitally by the server. That is, if some server sent me illegal content that I did not ask for, they could incriminate me for having that content later and I do not have any proof that it was they that send me this content. The record itself is no proof, as it could have been tampered with by me.

Also, see this question.

I would not expect the server to sign every application data exchanged, because this somehow defeats the purpose of exchanging a session key, but why not signing a hash (or a HMAC with the session key) with the private key of the server at the end of the communication? If both parties sign it, then as I see it, they both obtain benefits.

Notice

I am not trying to achieve non-repudiation. I know that even if I hold a valid server signature with a timestamp, it is not enough (keys can always be claimed stolen). But at least, it serves the purpose of proving the provenance of content.

Tal-Botvinnik
  • 143
  • 5
  • 1
    The content/payload of the TLS connection is not signed. TLS is not meant to allow you to prove at a later time that the server sent you the content. The only goal of TLS is to allow you to know, when receiving the content, that you're receiving it from the server, unaltered, despite an attacker in the middle. – Z.T. May 11 '19 at 15:52

1 Answers1

4

... if some server sent me illegal content that I did not ask for, they could incriminate me for having that content later and I do not have any proof that it was they that send me this content.

You can neither proof that somebody has send you some content nor can someone proof that someone has not sent you this content. Also, if someone sends you incriminating content they most likely don't want you to be able to proof this anyway and thus would not use a transport method which lets you proof this.

I would not expect the server to sign every application data exchanged ... but why not signing a hash (or a HMAC with the session key) with the private key of the server at the end of the communication? If both parties sign it, then as I see it, they both obtain benefits.

This was simply not a design goal of TLS. TLS is designed to protect against sniffing or modifying by some man in the middle, not that some party can prove that the other has sent something. In other words: TLS is not a secure everything you want protocol but has a specific goal - which is not the goal you expect from it.

Additionally, in order to let both parties sign their sent data both parties need to have a certificate. While certificates for server are the most common case (but it can be done without, like with PSK) certificates for the client are uncommon.

Also, if the signature is only added at the end of the connection as you propose the peer might deliberately or accidentally close the connection before the signature was sent. It is common though that the data gets already processed while more data still get received - which make it possible to incriminate you but make it impossible for you to proof it.

but why not signing a hash ... with the private key of the server at the end of the communication?

The purpose of certificates inside TLS is for authentication (and maybe key exchange - but this is deprecated and removed in TLS 1.3). Authentication needs to be secure at the moment it is done and thus the certificate needs to be sufficiently secure for the moment.

Signing instead should provide proof long after the data where transmitted. This means that the certificate might need to be stronger (depending how long the proof should be fine) and that the private key of the certificate needs to be protected for as long the proof should be fine. If the private key is not guaranteed to be protected that long somebody else might create faked signed messages or might successfully claim that what you present is faked.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for this thorough answer. What about an optional signing procedure of record at the end that takes place if and only if both parties have certificates and the client asks for this? If a server wants to be reliable (say, a news webpage), why not open this procedure to the clients? Is it just an incentive dilemma? – Tal-Botvinnik May 11 '19 at 16:44
  • @Tal-Botvinnik: again, TLS was designed for a special purpose - to protect the communication against a man in the middle. It was not designed as the protocol which handles all the security problems you might have. – Steffen Ullrich May 11 '19 at 16:51
  • Thanks. Please do not assume that I don't understand the purpose of TLS. My only question is that, given that it is possible and does not hurt TLS at all, does such a procedure exist? Or is there another way of doing it? Or is there a reason to avoid doing such procedure? Or is it pointless because of some other attack? In any case, I'm accepting your answer. – Tal-Botvinnik May 11 '19 at 17:07
  • @Tal-Botvinnik I think this doesn't exist because this need is too rare. Client certificates are very rare. Needing a proof of receiving something from the server is even more rare. If someone wants something like that, they add gpg on top, or they use something like signal protocol. TLS will probably not add features that are not needed by web browsers and RESTful APIs (which mostly work like web browsers). – Z.T. May 11 '19 at 17:21
  • @Tal-Botvinnik: as far as I know such procedure does not exist within TLS. See also my updated answer on why this might be a bad idea, i.e. what lifetime is expected for a signature and what for authentication and what this means for strength of certificate and protection of private key. – Steffen Ullrich May 11 '19 at 18:25
  • Thanks @SteffenUllrich. I guess that a cryptographically strong Wayback Machine (https://archive.org/web/web.php) is out of reach nowadays, then. (EDIT: link) – Tal-Botvinnik May 11 '19 at 18:30