1

According to the documentation on SSLSocket:

You may register to receive event notification of handshake completion.

Why would you not register for this? Does the fact that SSLSocket.startHandshake() succeeds without an SSLException occurring ensure that certificates are trusted? Or do you get some extra level of assurance by waiting for the handshake to complete?

user207421
  • 305,947
  • 44
  • 307
  • 483
Paul Reiners
  • 8,576
  • 33
  • 117
  • 202

1 Answers1

2

There are 3 conditions to start the handshake on an SSLSocket:

  • calling startHandshake which explicitly begins handshakes, or
  • any attempt to read or write application data on this socket causes an implicit handshake, or
  • a call to getSession tries to set up a session if there is no currently valid session, and an implicit handshake is done.

Any handshake failure will generate an exception (including when the certificate isn't trusted):

If handshaking fails for any reason, the SSLSocket is closed, and no futher communications can be done.

Often, calling startHandshake() explicitly when establishing the connection is unnecessary, since the handshake is initiated when you start reading from the inputstream (or writing to the outputstream). Any failure there would cause an exception and stop the normal control flow. You don't need to register explicitly to capture the completion of the handshake in those cases: if you can read/write from the streams, it's done.

The notification of handshake completion is mostly useful if you're a server asking for re-negotiation (by calling startHandshake() after some application data has been exchanged). In this case, you may want to wait for that handshake to have completed before proceeding. For example, if the server requests a client-certificate after receiving an HTTP request for a particular path, it may want to wait for the handshake to complete successfully to be able to authorise the client-certificate, before sending the response. This is because startHandshake() doesn't stop the flow of application data:

If data has already been sent on the connection, it continues to flow during this handshake.

Bruno
  • 119,590
  • 31
  • 270
  • 376
  • It seems that the server must cache the data that the client sends until the handshake is complete. This seems to cause issues because the default Apache web server cache is ~128K and an HTTP PUT of a file can be huge... – Ryan Jan 10 '13 at 21:34
  • @Ryan No. The server doesn't *get* the data data that the client sends until the handshake is complete. Until the handshake completes, there is no connection over which data can be sent. – user207421 Nov 19 '13 at 00:42
  • @EJP No. SSL Renegotiation occurs concurrently with data transfer. See http://stackoverflow.com/questions/14281628/ssl-renegotiation-with-client-certificate-causes-server-buffer-overflow and http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslrenegbuffersize and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20 and... – Ryan Nov 19 '13 at 15:34
  • @Ryan If and only if there has been a prior handshake. If there hasn't, the handshake must complete before any data is sent. I am referring to that case ('there is no connection'). – user207421 May 22 '16 at 23:38