Is it normal to have Session ID in the first Client Hello, and then the server picks it up and accepts the same Session ID and uses it in all further TLS traffic. That is the "Client or Browser" tells what Session ID to use and "Server" accepts it. This is a behavior with my websites.

Why does it do so?

Is it normal?

Does it have any security risks?

  • Yes is normal, The mechanisms for having the session ID is basically for not repeat the TLS handshake. Right now, as far as I know, there is no any security risk about this type of mechanism. Take into account that this ID is generated for a given IP so if somebody is sniffing the network and take the ID for another connection is not going to work. – camp0 May 14 '18 at 15:04
  • I forgot to mention that for having the Session ID you should have at least one connection where this id is set, so later connections to the same place will use this id. – camp0 May 14 '18 at 15:21

Session ID in the first Client Hello, .... That is the "Client or Browser" tells what Session ID to use and "Server" accepts it.

It is not that the client just comes up with a new session id and the server accepts it. The TLS session id and also the TLS session ticket which serves a similar purpose are first send by the server to the client.

If later the client sends the previously received session id or session ticket within a new TLS handshake and the server still has or can derive the information for this existing session, then the session can be resumed and only an abbreviated handshake will be done.

If instead the clients sends a session id or session ticket which the server cannot handle (i.e. invalid, expired...) then it will be ignored by the server and a full TLS handshake will be done.

| improve this answer | |
  • I have tested this multiple times: I use a new PC, with newly created user (on Mac and Windows), open Incognitto Chrome and enter the specific website address; then I see "Client Hello"s with "Session ID"s and that followed by "Server Hello"s and other packets with the same Session ID...If the Server accepted the Session ID that the Client Hello provided, then this means that it is session resumption...How is it possible that this Session ID already existed, if the website is being accessed for the first time on that User and even the browser? – Shan Jose May 15 '18 at 16:47
  • @ShanJose: if the browser visits the site for the first time no session id will exist. But I'm not sure what you are really seeing, maybe make a packet capture, include it in your question (you can use cloudshark.org) and describe based on this packet capture what you are seeing. – Steffen Ullrich May 15 '18 at 20:23
  • I have uploaded the Packet capture in the below link : dropbox.com/sh/iiw21e20pqohwzz/AAAyvutAR3XH7KUhr1vXoq0aa?dl=0 – Shan Jose May 22 '18 at 8:54
  • The above capture is on a test server using Apache2 on Ubuntu 14. – Shan Jose May 22 '18 at 8:55
  • @ShanJose: Thanks for the pcap. I have no idea where this SessionId comes from in the first request (ie. tcp.stream eq 3) but the server is obviously not using it as you claim. Instead the server does a full TLS handshake (which means that it has no such session) and issues a new SessionTicket but no SessionId. The client is using this SessionTicket in the following requests but continues to add this strange SessionId. I've not seen this yet, i.e. I've only seen the client to add an empty SessionId. What kind of browser is this (my guess is Chrome based on the ciphers and extension order)? – Steffen Ullrich May 22 '18 at 9:16

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.