Is TLS Server Finished signed by the server?

Question

I am exploring some non-orthogonal uses of TLS for research. I was wondering if it is correct to say that the TLS Server Finished is signed by the server.

Answer 1

I think it would be better summarized as:

The the Finish message is encrypted with the session key.

or

The Finish message, containing an HMAC over the handshake transcript, is encrypted with the session key.

As @dave_thompson points out in comments, this is essentially equivalent to signing the transcript (though the Finish message itself is not signed).

---

Here's my understanding of the TLS Finish message (@Steffen, @forest, @dave_thompson, feel free to correct my understanding).

TLS 1.2 (RFC 5246)

Section 7.4.9 Finished gives this:

Meaning of this message:

The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

Structure of this message:

 struct {

      opaque verify_data[verify_data_length];
  } Finished;

 verify_data

     PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

 finished_label

     For Finished messages sent by the client, the string
     "client finished".  For Finished messages sent by the server,
     the string "server finished".

Hash denotes a Hash of the handshake messages. ...

handshake_messages

     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

My understanding is that that hash of all previous handshake messages is used as (part of) the seed for a pseudo-random function (PRF), which is used to generate 12 or more (depending on cipher suite) psuedo-random octets, which are then encrypted using the AES session key that was just agreed to in the handshake.

So I would say "the hash of the entire handshake, as seen by the server, is sent in the first encrypted message, and the other side must verify that it matches the hash of the entire handshake as seen by the client". (which I know is more of a mouthful than "server signs the Finish message", but what can you do).

---

TLS 1.3 (RFC 8446)

Section 4.4.4 is analogous to RFC 5246's Section 7.4.9 above, but it accounts for the 0-RTT mode, and they have changed the PRF to an HMAC using the negotiated key. The core idea is the same: the Finish message includes a hash of the entire handshake, and it is encrypted using the negotiated session key.

Answer 2

The TLS server finished message is encrypted with the shared secret key generated earlier in the handshake.

EDIT: For additional clarity, the client (before the server finished message) sends a random byte string that both the client and the server use to compute the shared secret key. The random byte string itself is encrypted with the server's public key (which means the server will only be able to compute the shared secret key if it has the server's private key). The public key is verified to belong to the server earlier in a similar random byte string way.

EDIT 2: In response to further comments The current breakdown of protocol support according to Qualys SSL labs 1/31/2019:

Additionally Random byte strings are still used as part of the keying material (nonces used to generate the ephemeral keys), Server Hello and Client Hello per RFC 8446

Finally this answer does not include discussion of ephemeral keys (using RSA to exchange keys which we use as a pre-master secret which then gets fed with a random value [nonce] into HKDF for tls 1.3 or PRF for tls 1.2)...I hope all these edits shed some light on why my original answer was intentionally brief and precise... If you want to dive into the deep depths of the implementation read the RFC! If you want a distilled answer you come to a place like this. If you want a distilled, but cryptographically precise answer go to the crypto stack exchange.

TLDR This answer is now an abomination