0

The TLS 1.3 extension includes this table indicating which Extensions can be sent in which Records:

+--------------------------------------------------+-------------+
| Extension                                        |     TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066]                            |      CH, EE |
     ... 

CH stands for Client Hello (sent by the Client), and EE stands for Encrypted Extensions (sent by the Server) -- these are record sent in the TLS Handshake.

My question is... Why does the Server need to send the SNI extension in the Encrypted Extension record? What purpose does this serve.

I fully understand the premise of SNI and why the Client will send the extension in the Client Hello. But I am unsure as to what purpose the same extension serves in the Encrypted Extensions field.

My own capturing and decrypting of TLS 1.3 traffic has caught zero instances of the SNI extension being sent in Encrypted Extensions... so as far as I can tell, this seems to be optional?

1 Answer 1

1

As seen in the cited table the server_name extension is defined in RFC 6066. To cite from this standard:

A server that receives a client hello containing the "server_name" extension MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. In this event, the server SHALL include an extension of type "server_name" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty.

And this is exactly what happens when doing a quick check against some server which requires SNI:

screenshot wireshark showing server_name extension on server side

3
  • In my testing, I would frequently see a SNI extension in the CH, and no SNI in the Encrypted Extension. According to your answer, I can interpret that if SNI was used to select a Server Certificate to send, then the SNI extension must appear in the EE? So if no SNI extension exists in EE, I can assume sending the SNI header wouldn't technically be necessary (if it wasn't mandatory in TLS 1.3).
    – jester
    Mar 27, 2023 at 22:55
  • 1
    @jester: The meanings of MUST include (your expectation) and SHALL include (RFC) are equivalent according to RFC 2119. So if no SNI extension exists in EE this should be taken as signal, that the given server name was not needed to select the certificate. Mar 28, 2023 at 4:53
  • Excellent. Thank you for confirming!
    – jester
    Mar 29, 2023 at 0:13

You must log in to answer this question.

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