Re: [NSE] Extended ssl-enum-ciphers script

["Bojan Zdrnja (SANS ISC)" <bojan.isc () gmail com>]

Hi Daniel,

On Sun, Aug 10, 2014 at 11:18 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> Bojan,
>
> This is a feature we've been wanting for a while. Unfortunately, it's not
> always that easy, since some servers (IIS) set limits on the number of
> ciphers that will be considered at a time. Here's an (admittedly contrived)
> example edge case where I believe your code will fail:
>
> 1. The target server has 65 cipher suites supported.
> 2. After the initial discovery run, the 65 suites are collected into one
> table and passed to find_ciphers
> 3. find_ciphers takes the first 64 (unordered) cipher suites and processes
> them, storing the sorted list.
> 4. Then it takes the 65th cipher and processes it, resulting in 1 cipher,
> which is then appended to the end of the sorted list, regardless of server
> preference.

Mmm, good point - I didn't think about servers that support more than 64
ciphers :) (must say I haven't seen those in the wild, but that does not
mean that they don't exist :).
Regarding the 64 cipher limit, I think that most Microsoft products that
rely on Schannel have this limitation. From some testing I did, it appears
that also any service published through TMG will have that limitations.

In reality, something like a quicksort could be a better approach. I'll try
> to sketch out a quick recursive algorithm here so that someone can
> implement it later:
>
> 1. Base case: If we have less than 64 ciphers, let find_ciphers order them
> 2. Pick a "pivot" cipher from the middle of the list.
> 3. Chunk the rest of the ciphers in 63-cipher chunks, adding the pivot and
> passing to find_ciphers.
> 4. Find the pivot in the result of step 3, and put elements that come
> before it into high_table and those that come after into low_table
> 5. Repeat steps 4 and 5 until all ciphers are in high_table or low_table
> 6. Recurse. Return quicksort(high_table) + pivot + quicksort(low_table)
>
> This algorithm should work correctly, though there is likely a more
> efficient one. One potential source of optimization is the fact that as
> find_ciphers is called for the discovery phase, it finds sorted results for
> each initial 64-cipher chunk. In many cases, these sorted chunks may be
> small (1 or 2 ciphers), but there are likely larger sections that may be in
> already-sorted order.

Yep, this looks as it should work.

On the other hand, this may be efficient enough, given that very few
> servers will support more than 64 ciphers. Even OpenSSL with
> ALL:COMPLEMENTOFALL should return after one level of recursion (111 ciphers
> on my Ubuntu system = 111*2 = 222 requests). A system that claimed to
> support all 359 ciphers we detect would require approximately 359*4 = 1436
> additional requests, assuming we picked a good partition in each case.

Yeah, the current script should probably work in most cases. According to
this:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930%28v=vs.85%29.aspx,
the list of cipher suites on Windows is limited to 1023 characters.
Since most cipher names are 20+ characters, this could mean that you can't
really have more than ~50 ciphers active on a Windows machine - I haven't
tested this though.

Cheers,

Bojan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/