Re: [NSE] HUGE ssl-enum-ciphers speed improvement

[David Fifield <david () bamsoftware com>]

On Thu, Jul 12, 2012 at 04:37:56PM -0500, Daniel Miller wrote:
> Previously, the script took this algorithm: For each of the 4
> protocol versions (SSLv3, TLSv1.0, TLSv1.1, TLSv1.2), start 213
> threads, one for each Cipher Suite. When all threads for one
> protocol have finished, process them. If the protocol was not
> supported, discard results. If at least one Cipher Suite was
> supported, do the same thing for the 3 compressors. Besides the
> primary improvement, this means 212 extra connections per
> unsupported protocol (since support for the protocol should be
> detectable in one connection).
>
> The SSL protocol allows clients to specify up to 2^16-1 cipher
> suites in one Client Hello, and the server must choose one that it
> supports. I chose to reimplement the script to remove the one suite
> chosen by the server and retry. If the server supports 7 cipher
> suites, then the 8th Client Hello will be rejected, and the script
> can stop trying. To retain some of the multithreading benefits, I
> chose to implement each protocol in a separate thread, retaining a
> linear execution within each protocol. This lets me evaluate after
> each Hello whether to keep trying or to finish.

You should check if this is the same change Mak Kolybabi tried in 2010:
http://seclists.org/nmap-dev/2010/q1/650
(Look for "...it starts by offering all ciphers at once...".)

There was some problem with this method, the details of which I don't
remember, but you should try some of the test cases in this thread:
http://seclists.org/nmap-dev/2010/q1/859

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/