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

[Daniel Miller <bonsaiviking () gmail com>]

Bojan and List,

ssl-enum-ciphers now fully supports ordering of ciphersuites by server
preference: http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html

David sent me some previous work he had done on this problem, and I was
able to integrate it into the current version of the script. SVN revisions
r33474 - r33483 contain the relevant changes. Some salient points:

* Detects and reports whether the server uses the client's ordering or the
server's ordering preference for cipher suites
* Works around a couple bugs in SSL servers which previously caused some
cipher suites to be missed (r33477, r33482)
* Sets timeouts based on portscan-phase results (as discussed here:
http://seclists.org/nmap-dev/2014/q3/188)
* Uses merge sort (not quicksort as I had suggested) to properly sort
ciphers by server preference. Worst-case performance ought to be similar to
my best-case guesstimates.

Dan


On Sun, Aug 10, 2014 at 4:56 PM, Bojan Zdrnja (SANS ISC) <
bojan.isc () gmail com> wrote:

> 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/