I read that TLS 1.3 supports encrypted handshake. Is it achieved using encrypted_extensions?

Does it mean that the records which contains handshake messages are encrypted/protected from the point of view of record-protocol?


Does it mean that the handshake protocol itself encrypts its message payload and records are plain text from record-protocol perspective?

  • 1
    $\begingroup$ The record layer takes care of the encryption of the late part of the handshake. $\endgroup$
    – SEJPM
    Jun 2 '17 at 17:05
  • $\begingroup$ Refer 8gwifi.org/docs/tlsv13.jsp $\endgroup$
    – anish
    Sep 2 '18 at 15:44

In TLS 1.3, all messages after ServerHello are encrypted. This encryption happens before EncryptedExtensions is sent. The traffic keys protect the record layer payload; they transform TLSPlaintext structs into TLSCiphertext structs.

During the handshake, the following messages are transmitted:

  • Client $\rightarrow$ Server: ClientHello (generate client nonce)
  • Client $\rightarrow$ Server: ClientKeyShare (generate ephemeral Diffie-Hellman parameter $X = g^x$)
  • Server $\rightarrow$ Client: ServerHello (generate server nonce)
  • Server $\rightarrow$ Client: ServerKeyShare (generate ephemeral Diffie-Hellman parameter $Y = g^y$)

At this point, both Client and Server can calculate the pre-master secret $g^{xy}$, and this is part of what goes into a PRF to derive a handshake master secret (HMS). Then you derive a handshake secret traffic key $t_{hs}$, which depends on HMS and the nonces.

The EncryptedExtensions message is the first one sent after $t_{hs}$ is generated. This and the rest of the handshake messages (like ClientCertificateVerify, ServerFinshed, etc.) are encrypted with $t_{hs}$. See how the keys are computed here.

You can see sample handshake traces here. (Since TLS 1.3 is still in draft form, this will be obsoleted soon.)

  • 2
    $\begingroup$ You may want to link to the relevant sections of the current drafts as well (and not just the test vectors): Section 5.2 for the statement that the traffic keys protect the record layer payload. Section 4.3.1 for the encrypted extensions and the note that it uses the traffic keys as well and Section 7.3 for the computation and usage of the traffic keys. $\endgroup$
    – SEJPM
    Jun 2 '17 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.