0

We are running a JMeter script which posts json data to an internal https endpoint. But we get javax.net.ssl.SSLHandshakeException intermittently (around 3 times out of 100 calls) while running the script.

This issue is very similar to following SO question but all of the solutions discussed there don't work for me: javax.net.ssl.SSLHandshakeException: handshake_failure when using JMeter with SSL (JDK8)

I am using JDK8 and latest JMeter version 4.0. I turned on ssl debugging and from ClientHello and ServerHello messages, it looks like the server supports TLS 1.2 and TLS_RSA_WITH_AES_128_CBC_SHA cipher suite which is supported by JMeter as well.

But I see following in SSL logs for failed JMeter requests:

WRITE: TLSv1.2 Handshake, length = 64
READ: TLSv1.2 Alert, length = 2
RECV TLSv1.2 ALERT: fatal, handshake_failure
%% Invalidated: [Session-17, TLS_RSA_WITH_AES_128_CBC_SHA]

I have tried following solutions:
1. Added server cert to jre cacerts
2. Downloaded local policy jars for unsupported ciphers and copied them to jre lib security folder
3. Update httpclient jar (4.5) for JMeter
4. Explicitly enabled TLS 1.2 in JMeter configuration

I used TestSSLServer to test SSL capability of our server and this is what it returns:
SSLv3:
server selection: enforce server preferences
3-- (key: RSA) RSA_WITH_RC4_128_SHA
3-- (key: RSA) RSA_WITH_AES_128_CBC_SHA
3-- (key: RSA) RSA_WITH_AES_256_CBC_SHA
3-- (key: RSA) RSA_WITH_3DES_EDE_CBC_SHA
TLSv1.0: idem
TLSv1.2:
server selection: enforce server preferences
3-- (key: RSA) RSA_WITH_RC4_128_SHA
3-- (key: RSA) RSA_WITH_AES_128_CBC_SHA
3-- (key: RSA) RSA_WITH_AES_256_CBC_SHA
3-- (key: RSA) RSA_WITH_3DES_EDE_CBC_SHA
3-- (key: RSA) RSA_WITH_AES_128_CBC_SHA256
3-- (key: RSA) RSA_WITH_AES_256_CBC_SHA256

Any ideas as to what could be going wrong?

Ketan
  • 373
  • 1
  • 6
  • 18
  • 1
    Best choice by far, look at the server log(s) to see what it says is the problem, then investigate and fix that. Otherwise set sysprop `javax.net.debug=ssl` and save the output which will be huge (you may need to buy some more disks) and spend days or weeks grovelling through it. Your 1 and 4 can never cause this alert and your 2 can't when the server accepts AES128. (Note accepting is not the same as requiring; your 'expecting' is ambiguous.) – dave_thompson_085 Jul 08 '18 at 03:02
  • Thanks for the reply. I edited the question with results from TestSSLServer and it looks like RSA_WITH_AES_128_CBC_SHA is one of the server's preferences. Actually, I don't have much control on the server side to debug things. And I am wondering where the fault lies, on the client or the server side. – Ketan Jul 08 '18 at 05:35

2 Answers2

1

I couldn't really figure out the exact cause but now have an idea what might be going wrong. As suggested by Dave, I turned on the SSL debugging and went through all logs and compared the failed requests with successful ones.

For failed requests this is what I saw in logs:

  1. Client sent Hello & Server sent Hello
  2. Server sent cert & Server Hello Done
  3. Client Key exchange & Change Cipher Spec
  4. Finished
  5. Fails here and No Change Cipher message from Server, handshake_failure error

As you can see, the server for some reason fails to respond. After some googling, I stumbled on to the following forum on f5 SSL issues. Our service too goes through f5. I can't confirm as I don't have much control over our server side but below issue looks similar:

https://devcentral.f5.com/questions/big-ip-proxy-ssl-121-handshake-failure-47464

Ketan
  • 373
  • 1
  • 6
  • 18
  • 1
    We had the very similar issue on F5 ProxySSL breaking the extended master secret extension. Disabling on the server was our solution. Besides, you didn't mention in your question this proxy element (f5). – Eugène Adell Jul 08 '18 at 22:59
  • Yeah didn't think earlier it could be f5 related but after looking at SSL logs and some searching, this makes sense. I guess I should mark this as the answer. – Ketan Jul 09 '18 at 00:29
  • 1
    Very recent versions of Java (8u161 and 9.0.4) do support ExtendedMasterSecret, but they (would) use it on every handshake, it wouldn't be intermittent. And FYI similarly recent versions of Java no longer need the unlimited-policy jars _ever_; they finally removed that decades-old misfeature. Good luck. – dave_thompson_085 Jul 09 '18 at 09:55
  • An update. Our server team informed us that they have figured out the issue with f5 SSL set up and said that this is an edge case when the same IP hits the service continuously. I don't have much details now but will post here once I do. Thanks for you help Dave and Eugène. – Ketan Jul 10 '18 at 00:02
  • Another update. This issue has been fixed. Our Server team did some changes in how the f5 was set up (I still don’t have specifics) and we ran the JMeter automation and we don’t see the SSL handshake exception anymore :) – Ketan Jul 11 '18 at 00:47
0

This is a known issue documented in bug id 563488 for BIG-IP versions earlier than 13.0 as described in K34019109.

Jason Rahm
  • 670
  • 3
  • 14