https://bz.apache.org/bugzilla/show_bug.cgi?id=62734

            Bug ID: 62734
           Summary: Jmeter HTTPS tests with tlsv1.2 and 256 bit AES
                    ciphers only lead to 5-10% SSLHandShakeErrors
           Product: JMeter
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: HTTP
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

We have been using Jmeter every year for the last 7 years to help us prepare
our key systems before the holidays.  This year one of our standard tests we
failing out of the box and after a full day of troubleshooting it and trying
different things yesterday, here is what I am able to report.

Bug:
Even with a single process running multiple iterations hitting our API we see
anywhere from 1 to 10% of requests taking a long time to respond and resulting
in a java SSLHandShakeErrors (I'll paste the stack below my explanation).  As
the number of requests is 100 and over, that number ends up being more like 10%
of the requests that will eventually fail this way.

Versions tried:
I have tested this with latest versions of Jmeter 4, then Jmeter 3 and again
with the Jmeter 2 version we used in prior years.  Additionally I swapped out
and tried latest sun oracle versions of java 8, java 9 and java 10 (As of Sept
17th 2018).  I even modified my jmeter configs trying different things such as
changing the http client from HttpClient4 to Java to no avail.  Additionally
after reading all relevant user group and bug report discussions related to
similar things in the past, we found nothing was able to eliminate this issue. 
For example, setting JVM_ARGS="-Djsse.enableSNIExtension=false" seemed to make
it perform slightly better, but on average there were a similar number of
SSLHandShakeErrors with or without that setting.  Additionally found from
reading and diffing them that for a while in newer versions of java the Java
Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files have
been included and so that is not related to the issue.

Hypothesis:
Jmeter HTTPS tests with tlsv1.2 and 256 bit AES ciphers only lead to 5-10%
SSLHandShakeErrors.  Our similar SSL cert with 128 bit AES ciphers does not
fail in this manner.  Using another tool such as locust.io which uses python
requests to do something similar does not run into such SSLHandShakeErrors.

Stacktrace:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during
handshake
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1002)
        at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
        at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
        at
org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:539)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)
        at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)
        at
org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:490)
        at
org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:416)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:250)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
        at sun.security.ssl.InputRecord.read(InputRecord.java:505)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
        ... 14 more

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to