ReadyAPI - "Remote host terminated the handshake" on server with SNI enabled

[LoneWanderer04]

Hello everybody,

We are setting up a test suite using ReadyAPI 3.3.0.  It's making HTTPS Rest calls, using NTLM authentication which I set up and seems to succeed.  The issue I'm running into is that every other call fails due to the following error:

Error getting response; javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake.

I've dug into a lot of solutions at this point, and I'm running out of ideas. I tried editing the ReadyAPI vmoptions in the bin folder to add:
-Dsoapui.https.protocols=SSLv3,TLSv1.2
-Dsoapui.https.ciphers=TLS_RSA_WITH_AES_256_CBC_SHA256

I've tried adding the following to the ready-api.bat file:
set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.https.protocols="TLSv1.2"
set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.debug=all
set JAVA_OPTS=%JAVA_OPTS% -Djdk.tls.client.protocols="TLSv1.2"
set JAVA_OPTS=%JAVA_OPTS% -Dhttps.protocols="TLSv1.2"

But none of these solutions have worked so far.  Is there anybody else that has run into this issue, and how you got around it to fix it?

[richie]

Hey @LoneWanderer04 

Sorry - I read this as though you have a project and there are some REST requests configured to use NTLM auth and there are other executable test steps (what ones?) that when you execute these, you get the handshake reset -  is that correct?

Do you mean that once you'd configured the REST steps to use NTLM - all other steps got a handshake reset?

Can you please clarify?

Cheers,

rich

[LoneWanderer04]

I'll try to clarify as much as I can.

We have a test suite where all the REST calls are done via NTLM.  

The current issue I'm encountering is if I execute an API call, every other run gives me the error I listed.  Nothing changes between attempts, other then I'll get a success, then  "Remote host terminated the handshake" then success, then "Remote host terminated the handshake".  

The two scenarios I've tried is running each call individually which does the above behavior, and running all the calls together in a full suite of tests, at which point the first API call in the suite gets that error. 

Example:

1st run: POST *endpoint 1* - Success, I get a JSON package returned.
2nd run: POST *endpoint 1* - failure Error getting response; javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
3rd run: POST *endpoint 1* - Success, json package from 1st run returned
4th run: POST *endpoint 1* - failure Error getting response; javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake

[richie]

Hi @LoneWanderer04 

I don't think this is anything to do with ReadyAPI!/SoapUI at all.

To prove this - check the contents of the RAW request - one that is successful and one that fails - I'm betting they are identical.

Considering it fails on every other request, it sounds like the endpoint you're hitting has some rate limiting/SLA that doesn't allow a certain number of requests within a specific timeframe or something like that.

Have you tried inserting a Delay in between steps?

The answer (depending on the level of logging) will probably be reflected in the logs of the app server endpoint you are hitting.

ta

rich

[LoneWanderer04]

Its a good thought, but that was one of the first things I checked, the Raws of the calls are the same, but it has nothing to do with delays from what I've seen. I've waited upwards of multiple minutes between calls, as long as the last call was a failure due to handshakes, the next call will succeed. 

The more odd detail is if I run all the API calls together in a suite, only the first call in the suite will get the handshake error, the rest will all succeed even though a lot of them of being called one after the other in quick succession, further putting the timer idea as not being the main problem. I'll reach out to the server guys to see if there is anything on the logs, but they were telling me that they think it's on ReadyAPI's side since they weren't seeing anything the other day.

From what I can tell, the response just doesn't even go out when that happens, since the handshake fails right away, so it makes sense the server didn't have anything in depth.

[richie]

Hey @LoneWanderer04 

Typically whenever the session is terminated more often than not it's something to do with the server/endpoint - not ReadyAPI!/SoapUI.  The people responsible for the endpoint are always going to default to "it's your problem, not mine" cos that's standard software dev

The way to prove this one way or another is to use Fiddler.

submit 2 requests from ReadyAPI! using Fiddler to proxy the requests/responses to capture the details.

Do a straight comparison of a successful request and an unsuccessful one in which the session is terminated.

If the RAW details for the requests are identical (i.e. same headers and payload), then the issue isn't ReadyAPI!, it's your endpoint.  If there are differences you need to identify what the differences are and fix them, but at this point I'm betting on identical and if that's the case, logic dictates it's your endpoint.

nice one

rich

[LoneWanderer04]

So been continuing to look at this.  The server configuration is going through a Load Balancer on the specific server I run the tests against.

We shut off one of the nodes completely and that seems to make it pass, so later today we are going to look into the Load Balancer configuration, since it appears that something is up with having calls go through multiple nodes.

UPDATE:
It appears to be due to the fact that the two main servers we use are configured with SNI.  According to https://stackoverflow.com/questions/31245378/ssl-request-fails-from-soap-ui-works-with-fiddler-proxy, this seems to be due to ReadyAPI's Apache HttpClient 4.1.1 still not supporting that behavior (at least according to everything we've checked).

My question evolves to the following:
Does anybody know a way of overwriting Java in ReadyAPI so I manually overwrite the SNI to what I need?

SNIHostName

[TanyaYatskovska]

Hi @LoneWanderer04,

Thanks for your investigation. The Stackoverlow thread is dated 5 years ago and it's referring to SoapUI OS (not ReadyAPI). I would recommend that you update to the latest ReadyAPI version - v. 3.4.5 - and check if you see this issue.

[LoneWanderer04]

Do you have a link where I can download that specific version? I checked the downloads page and it only has 3.5.0 of ReadyAPI.

Also does that version work with Protection! 4.9.4 version of the Floating License manager? That and 3.3.0 were all we were given when we purchased the product a few weeks ago.

[TanyaYatskovska]

Hi,

3.5 version was released several hours right after my previous post.

So, this is the latest version now 🙂