Handshake failure while using the Recorder

Hi,

I’m using gatling v1.7. I am trying to record a scenario where I access a website using https. I am getting a handshake failure and the browser gets stuck at that point.

stack trace:
11:20:03.818 [ERROR] i.g.r.h.h.u.HttpsUserHandler - Handshake failure with xxxxx.xxxxxxxx.com/xxx.xxx.xxx.xxx:443
java.nio.channels.ClosedChannelException: null
at org.jboss.netty.handler.ssl.SslHandler.channelDisconnected(SslHandler.java:575) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:102) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.Channels.fireChannelDisconnected(Channels.java:396) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:360) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:93) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.4.Final.jar:na]
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.4.Final.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.8.0_77]

I assume it’s a certificate thing … right? But in that case, I’m not prompted to add any exception for this website while trying to access it using the proxy…

How to overcome this ?

Thanks,
Fadi

http://gatling.io/docs/2.2.0/http/recorder.html#https-mode

Hi Stéphane,

So I did the following:

  1. Went to Options-> Advanced → Certificates-> View Certificates (Firefox)
  2. Deleted the already existing entry from the servers certificates for the website that I was trying to visit.
  3. Tried to add an exception for the website while the Gatling recorder is running and Firefox is configured to use the gatling proxy.
  4. Still getting the same exception and the exception won’t be added since it’s kind of stuck.

Hi,

I’m currently stuck, I have tried everything and still I’m not able to load the website on https.

I have removed the certificate exception for the website from within the browser certificates, then tried accessing it while the proxy recorder was on. I got the handshake exception and the connection hangs there. The moment I turn off the recorder, and reload the page. the browser prompts me to add an exception for the website:
Auto Generated Inline Image 1.png

So it looks like the browser isn’t even getting to the point where a certificate or exception needs to be provided. Note that I have tried this with the self-signed certificate and the generated CA modes of the recorder and I am still getting the same results.

Thanks,
Fadi

Use the Certificate Authority mode: http://gatling.io/docs/2.2.0/http/recorder.html#https-mode

Auto Generated Inline Image 1.png

I’m currently using the Certificate authority mode and I am able to open google using https for example, but when I try to access my website I get stuck with the handshake failure exception. So is it a configuration thing on the server i am trying to access ? If that’s the case, why am I able to load it when I’m not using the proxy ?

Thanks,
Fadi

Check to see if you have an exception stored in your browser. If at some point you told your browser to trust the server, that could explain it.

There are no exceptions in my browser for the server I’m trying to access since I removed the one that existed manually, hoping that I would be prompted to add a new exception when trying to access the server through the proxy…but that’s not happening :confused:

I’ve just realized that I’m always getting this exception, before the Handshake Failure exception:

WARNING: EXCEPTION, please implement org.jboss.netty.handler.codec.http.HttpChunkAggregator.exceptionCaught() for proper handling.
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(Unknown Source)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
at sun.nio.ch.IOUtil.read(Unknown Source)
at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Could the “java.io.IOException: An existing connection was forcibly closed by the remote host” mean that the web server refused the connection to Gatling’s proxy server ?

Please provide a reproducer and we’ll be able to investigate.

Cheers,

Hi Stephane,

I’ve sniffed the network traffic to check at what point the handshake is failing. Directly after my Client Hello, the server responds with a RST flag forcing me to close the connection.

I’m not able to provide a reproducer since this is a remote server provided by our client and I do not have direct access to it.

Can’t really say without a reproducer.
Maybe your recorder uses SSLv2Hello which is disabled/rejected by your server.