I develope a small client and server which establish a mutual-authenticated TLS connection using JSSE. Now, lets assume the client wants to initiate a connection but there is a legit reason for the server to reject the connection. For instance, this could be due to a revoked client certificate.
The server creates an SSLSocket and now wants to establish the session by calling getSession from the SSLSocket object. According to JavaDoc the method blocks until the TLS handshake is completed. So after returning from this method the server already knows that the TLS handshake has failed due to the revoked client certificate. At this point, an SSLHandshakeException is created, but somehow kept hidden inside the implementation (you can see this in the exception trace later on).
So at some later point, the server starts to listen for incoming client requests. Only after there is somehow some incoming data from the client, the server remembers the SSLHandshakeException that already has been created and wraps it as a causing Throwable into a new SSLHandshakeException.
So my question is: Why does the server has to wait until the client transmits some data although the server already knows that the handshake has failed and even hides an already created SSLHandshakeException object? Is there any possiblity to examine the SSLHandshakeException right away after the handshake has failed in the getSession-method ?
Maybe, do you also have recommendations of literature covering these kind of details regarding TCP and TLS in detail?
Thank you!
Edit: The internal hiding of the SSLHandshakeException seems to differ depending on the JDK. OpenJDK 8 eats any IOException in getSession an only creates a stdout output if a debug flag is set. However, my initial observation is based on IBM JSSE2 which indeed saves the exception internally so that it can be thrown later.