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.
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.