0

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.

1

2 Answers 2

2

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.

2
  • 1
    heh, you said "finnish"
    – schroeder
    Jan 29, 2019 at 22:24
  • 2
    Very close :-) The Finished messages are encrypted (with some cipher, not necessarily AES) and MACed, either separately or by AEAD which combines them, and the MAC part is closer to (but not quite) signing. Also a nit: 1.3 verify_data uses HMAC where 1.0-1.2 used PRF, but PRF in 1.2 was doubled HMAC and 1.0-1.1 doubled keyed hash very similar to HMAC. And while matching the verify_data has the effect of matching the transcript hash and (derived) key, it doesn't constitute sending the transcript hash, and is effectively signing the transcript. Jan 30, 2019 at 3:26
-1

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: enter image description here

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

5
  • 2
    The question was not if the message was encrypted but if it was signed. Signing is a different thing than encryption. Insofar your answer does not address the question. Jan 30, 2019 at 5:32
  • @SteffenUllrich If somebody is coming here it is because they either were too lazy or couldn't figure out the voluminous information in the RFCs. With that in mind I generally will attempt to distill this information down to the essential details. My answer is concise and afaik precise. In the sense that both parties would be the only ones privy to the shared key it functions as a logical signature ( allows for attribution given it depends on a previous step of attribution) but I wouldn't just call it signed...that would imprecise.
    – DarkMatter
    Jan 30, 2019 at 13:22
  • @DarkMatter: Encryption and signing are different concepts which can be used independently from each other or together. The question was about signing, your answer is about encryption. Given that you don't address signing at all in your answer it is not clear if the message is signed in addition to encryption or if it is not signed and only encrypted. Jan 30, 2019 at 13:26
  • @SteffenUllrich Of course they are different concepts. If you really think my answer is ABOUT encryption then I ask you to read it again and think about my carefully chosen wording (not just it says encryption so clearly it isn't an answer). If you ask is the sky green and I say..."the sky is blue" have I given you an answer to your question?
    – DarkMatter
    Jan 30, 2019 at 13:29
  • 1
    Your EDIT describes plain-RSA key exchange which is mostly obsolete; it became much less popular post-Snowden, and is completely removed from TLS 1.3 as of last year. Although the key exchanges actually used now share the (critical) property that only the legit server and client know the resulting secret keys, which is why symmetric encryption and MAC can be used. Jan 31, 2019 at 18:53

You must log in to answer this question.

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