TLS v1: How does the SSL Session ID mechanism work?

Problem:

• Product Name: VisiBroker Enterprise (TLS, security protocol)
• Product Version: 5.x
• Product Component: Borland Security Service
• Platform/OS Version: all supported versions
• JDK/Compiler Version: n/a/

TLS v1: How does the SSL Session ID mechanism work?

Resolution:

According to TLS/SSL specification, when a SSL client first negotiates a SSL connection with its peer (the server,in the language of TLS specification), the server may choose to return an assigned session ID to the client. This indicates that the server is willing to resume this SSL session using the same SSL parameters and cipher suites negotiated in the first hand-shake.

However, if the server is not willing to resume this SSL session at a later time, it should return an empty session id to the client.

Once the session id is used and is allowed by the server to resume, the server should return a server hello message with the same session id. If the server does not want to resume the session, or if the session id sent by the client is not found in the server"s cache, the server should return a new session id to
force a new SSL handshake with the client.

However, Server should NOT disconnect client using a session id.

An scenario in which a non-compliant ORB (to this SSL specification of session ID) may cause problem would be that if the process (call it the Server) using the non-compliant ORB issues the original session ID, and later on restart, thus nullifying the original session ID. Visibroker process that previously were
given the session ID will try to reuse the ID to talk to the Server, the right behavior in this case would be for the Server to reissue a new session ID, thus force a new SSL handshake. But if the Server outright rejects the connection because of the stale session ID, the behavior is non-compliant and can throw Visibroker into an infinitely loop trying to connect.

Author: Henry Hwang
Support Case: 565471