2

when reading about the TLS handshake protocol, I understood that the first response message from the server to the client is the server hello, which includes the session ID, and the latter will serve to identify the user for the next connections. I had read that the session ID information should be secret to avoid the danger of the session hijack, so is the server hello message encrypted? if so, how come knowing that the symmetric key which will be used for the encryption is not prepared yet?

I searched through the forums and viewed tutorials to clearly understood the TLS handshake protocol, but I didn't find a response to my question.

Marouen Badrani
  • 23
  • 4
  • 1
    You should better read TLS 1.2 RFC https://www.rfc-editor.org/rfc/rfc5246 Are you asking specifically for 1.2 version? Because there are a lot of changes in 1.3 related to handshake protocol. – Zergatul Dec 31 '22 at 00:00
  • @Zergatul, I am asking in general for the 1.2 or 1.3 versions. I had read in detail about the 1.2 protocol versions, and I had viewed also many topics and videos which state that the session ID should remain secret. What I understood is that the server message which contain the session ID is not encrypted – Marouen Badrani Dec 31 '22 at 13:16
  • You didn't read in details, because TLS 1.2 RFC says a lot of informations about session IDs. – Zergatul Dec 31 '22 at 13:43
  • RFC says that session ID, the randoms generated by the client or servers are transmitted without encryption. My point here, is other tutorials or courses state that the session id should remain secret to avoid the danger of session hijacking. – Marouen Badrani Dec 31 '22 at 13:56
  • 1
    RFC is primary source of information about protocols. – Zergatul Dec 31 '22 at 13:59
  • 2
    Certain session _parameters_, primarily the master secret, must be kept secret in 1.2 and below; the session-id is not. Resumption in 1.3 is very different than earlier versions; there is no 'general' answer that covers both 1.2 and below and 1.3. (In 1.3 the session-id _fields_ are dummy values that are not related to resumption at all, while the 'ticket' may either be a real ticket or just an id, and the ticket message is (super)encrypted in either case.) – dave_thompson_085 Jan 01 '23 at 01:21

1 Answers1

1

From RFC 5246:

When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows:

The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value.

ClientHello and ServerHello are not encrypted in TLS 1.2.

Warning: Because the SessionID is transmitted without encryption or immediate MAC protection, servers MUST NOT place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security. (Note that the content of the handshake as a whole, including the SessionID, is protected by the Finished messages exchanged at the end of the handshake.)

SessionID by itself is just random bytes. Client and server store somewhere negotiated keys for each session ID. You cannot do anything specific from attacker side if you know session ID.

Zergatul
  • 1,957
  • 1
  • 18
  • 28
  • thank you, other tutorials that I checked said that accessing the session ID by an attacker is dangerous, so I thought that I misunderstood the protocol, and the it should a kind of encryption for the client and server hello, which contain also the randoms used for creating the master and the session keys – Marouen Badrani Dec 31 '22 at 14:05
  • In contrast if you (implement and) use the rfc4507/5077 ticket option in 1.2 and below, it contains (at least) the master secret and is encrypted, and session-id is NOT used. – dave_thompson_085 Jan 01 '23 at 01:35