Forum Discussion

fhartojo's avatar
fhartojo
15 years ago

SSL Handshake Exception Error

I've been running into a problem very similar, if not identical, to the ones documented in these threads:

http://www.eviware.com/forum/viewtopic.php?f=5&t=2533&hilit=ssl+handshake+error
http://www.eviware.com/forum/viewtopic.php?f=5&t=5058&hilit=ssl+handshake+error

It happens with SoapUI (community version) version 3.0 and higher with JRE 6 up to update 22 (i.e., the latest one to date). It does *not* happen with SoapUI v2.5.1 regardless of the JRE version. The web service app. runs on Websphere 6.1 with IBM HTTP Server 6.1 and the packaged mod_ibm_ssl using a self-signed SSL cert. No settings of allowLegacyHelloMessages and allowUnsafeRenegotiation help, and neither does adding the self-signed SSL cert. to the JRE's cacerts keystore nor forcing an HTTP close after every request.

A couple of other things to notice: the SSL handshake error happens only when a cached SSL session is used. Moreover, it doesn't *appear* to occur when the server uses a CA-signed cert. (i.e., as opposed to a self-signed cert.). However, I haven't done an extensive enough testing to be absolutely certain of this.

In any case, digging into the code a little I see that the error happens whenever a cached session is used and the setEnabledCipherSuites() method is called on the reused socket in SoapUIEasySSLProtocolSocketFactory.java. That bit of code doesn't exist in 2.5.1. As a proof, if I use the older version class in the 3.6.1 code base and recompile, the problem disappears. So, as a crude fix/workaround I just inserted this line at the beginning of the enableSocket() method to invalidate the SSL session:


*** SoapUIEasySSLProtocolSocketFactory.java.orig 2010-12-01 14:08:10.902483086 -0700
--- SoapUIEasySSLProtocolSocketFactory.java 2010-12-01 23:56:20.190773760 -0700
***************
*** 75,80 ****
--- 75,82 ----
  
   private Socket enableSocket( SSLSocket socket )
   {
+   socket.getSession().invalidate();
+ 
    String protocols = System.getProperty( "soapui.https.protocols" );
    String ciphers = System.getProperty( "soapui.https.ciphers" );


I'm sure that's not the best fix for this problem. May be only do that as a retry in case of an SSL handshake error or only set the enabled cipher suites if it's not using a cached session. But, hopefully it's still of help to someone facing a similar problem in the meantime.

FWIW. Thanks.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    15 years ago
    Hi!

    Thanks for this, I've added your fix to the nightly build, we'll just have to see if any related issues show up..

    regards!

    /Ole
    eviware.com
  • ronnieandsandyd's avatar
    ronnieandsandyd
    New Contributor
    14 years ago
    With this change to the code and a user configuration of "Close Connections between each request" for a load test, SSL sessions are cached but never reused because they are invalidated.

    I think it would be best to follow one of fhartojo's suggestions (enumerated below)

    "I'm sure that's not the best fix for this problem. 1) May be only do that (invalidate session) as a retry in case of an SSL handshake error or only 2) set the enabled cipher suites if it's not using a cached session."

    OR a third one: 3) have an "invalidate SSL session between each request" configuration option.

    We've commented out the "socket.getSession().invalidate();" to get the behavior we desire.

    Thanks!
  • ronnieandsandyd's avatar
    ronnieandsandyd
    New Contributor
    14 years ago
    TomaasBark,

    I'm not quite sure what you mean by requoting what fhartojo said in the original post.

    His invalidate session code made it into the nightly build and, subsequently, the next release (4.0).

    The invalidate session has the side-effect I outlined in my first post.

    To be more clear, I was suggesting one of fhartojo's more elaborate suggestions (than invalidate the cached ssl session before each attemp to reuse) or a 3rd option be implemented. Here they are, in order, below:

    1. invalidate the SSL session if the handshake fails when reusing the session
    2. set the enabled cipher suites if it's not using a cached session (I'll be honest. I don't really know what that means)
    3. have an "invalidate SSL session between each request" configuration option
  • ronnieandsandyd's avatar
    ronnieandsandyd
    New Contributor
    14 years ago
    Our team has discovered that the real bottleneck is the application of the synchronized keyword on SoapUIEasySSLProtocolSocketFactory.enableSocket, applied by Ole (see attachments). When removing the synchronized keyword, we were able to stress the server we were testing using SOAPUI w/o any ill-effects to SOAPUI. We have since noticed that SOAPUI developers (vladimir) have begun using Apache HttpClient 4.1 and replaced SoapUIEasySSLProtocolSocketFactory with SOAPUISSLSocketFactory (see attachments). Unfortunately, the synchronized keyword has been carried forward.

    Our request is that the synchronized keyword be eliminated from the SOAPUISSLSocketFactory.enableSocket method, or an explanation be given as to why it is necessary. We have applied for the privs to write SOAPUI JIRA tickets to this end, but have not yet been given permission by SmartBear JIRA admins.

    Thanks!