search

rbsec / sslscan

sslscan tests SSL/TLS enabled services to discover supported cipher suites
GNU General Public License v3.0
2.33k stars 383 forks source link

sslscan hangs #14

Closed corny closed 9 years ago

corny commented 10 years ago

There are some hosts that cause sslscan and s_client to hang. It is reproducable with:

strace ./sslscan --failed --verbose 70.244.71.1

or

openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -connect 70.244.71.1:443

sslscan stops at the call of SSL_connect(): https://github.com/rbsec/sslscan/blob/239e01f489393f3777bddcd424072957e9ba00a5/sslscan.c#L1176

rbsec commented 10 years ago

I had a look with Wireshark at the traffic from s_client, and the server just doesn't respond to the Client Hello. Not quite sure why, could be a bug in their SSL stack.

As a workaround I've added a --timeout option in 4c109edb894eca1ae0fb8ba320e2ee1b258b7187 (defaults to 3s), so sslscan will timeout quicker and continue scanning when the server stops responding like that. You can set it lower to speed things up, but if you're testing slow servers (or servers on the other side of the world) then you might need to raise it.

corny commented 10 years ago

Thanks a lot for your quick reaction. I tested it and the new --timeout options solves my problem.

dmke commented 10 years ago

I'd like to add non-blocking sockets, which would also allow to check multiple cipher in parallel (say 5-10 at once) and speed-up the whole scan. This would require some major refactorings, though.

Any comments on that?

corny commented 10 years ago

That would be great, but it would require multithreading and locking of shared resources like the file pointers for writing the results.

rbsec commented 10 years ago

In theory I like the idea of sslscan being threaded (although you have to be careful about not being too aggressive - see issue #16, or the thc-ssl-dos tool). This shouldn't be too much of a problem on modern servers though. To be honest though, I've usually found sslscan will complete in ~10s, which is quick enough for me.

Frankly, I'm not a C developer, and I have almost no experience with socket programming or threading in C. I started making small changes/fixes to sslscan a while back because it's a tool I used that had some annoying default settings I wanted to change, and have been making incremental improvements since, but I never really considered doing a major design change/refactor. If I was going to do that I'd probably look at doing a complete re-write in something like Python - or more likely just working on one of the existing python tools (like the one by portcullis which already has threading support).

This is similar to a request I had a while back about making a Windows port. It'd be nice if it existing, but I don't have the skillset to create it, I don't really have the desire to learn how to do so, and I'm not going to be in a position to support it and fix any obscure bugs that occur in the process.

If someone else (such as yourself) wants to rewrite it to use threads then great - but it's not something that I plan to do, and I won't be able to offer much help in doing so.

dmke commented 10 years ago

Yeah, same here. I've got some experience with POSIX threading, but I wouldn't feel confident programming in C either... Also, #16 is quite a blocker for this proposal.

Regarding the time for completion: Running against 2795 hosts, I found an average duration of ~162 seconds on a 100MBit line (min 7s, max 1642s, median 78s, 286s in 75% quartile).

rbsec commented 10 years ago

Those timings seem to be very high compared to what I'm used to. I just did a test against a box in Taiwan from my home connection that than finished in ~140s, which is still below your average. I dropped the (default) timeout down to 3s in 4c109edb894eca1ae0fb8ba320e2ee1b258b7187, so that should get rid of the really high times, but even so your median seems on the high side.

You're clearly using this on a much larger scale than I am, so I'd be interested to know the profile of the systems you're testing (how many are starttls, are they very slow systems or a long way away, etc). I'd also be interested to know exactly what information you're using from the sslscan output, as you can save a fair bit of time by disabling checks/protocols you don't care about.

dmke commented 10 years ago

I could try to prepare a more detailled analysis from our production system (the one yesterday was just performed from my workstation which may or may not have introduced some latency issues ;-)).

I will need some feedback from @corny though, since he invited me to work on this project.

rbsec commented 10 years ago

If you can provide any more information that'd be great. Feel free to drop me an email if you're rather not discuss it in public.

dmke commented 10 years ago

I haven't found time today to prepare a more detailed analysis, but I'll try to setup a small Sinatra demonstrator to gather some data over the weekend.