Strange TCP RST with sslscan

Please use the following filter

tcp.port == 46639

Then select

Statistics -> Flow Graph

You will see what's going on in that conversation.

As you can see, the client sends a SYN and receives an ACK instead of a SYN-ACK. As a result, the client sends a RESET. Then the client tries again, unfortunately by using the same source port. That game repeats several times, until the server finally 'recovers' and sends a SYN-ACK.

There are two problems, that eventually lead to that long scan duration.

• the server does not answer with a SYN-ACK, but instead with an ACK. That's not good ;-) The reason for this is unknown
• the client reuses the same port for the retry (it does not close the socket), which leads to an unnecessary delay, as the wait time for the next retry gets increased (it doubles) by TCP for every retry.

Now, what can you do to speed things up?

• if you have access to the server (or the firewall/loadbalancer in front of it) you can try to figure out what's wrong with the server
• you can change the code of sslscan in a way that it uses a new connection after it detects that kind of problem, which will lead to a much shorter scan time, even if the problem on the server persists.
• you can write a wrapper for sslscan. As soon as the wrapper detects that specific problem, it will kill the sslscan process and restart it. However, it's probably not that easy to detect the problem.

Regards
Kurt