Nmap Development mailing list archives
Re: [NSE] Extended ssl-enum-ciphers script
From: Daniel Miller <bonsaiviking () gmail com>
Date: Mon, 11 Aug 2014 21:50:49 -0500
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'lltry 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 fewservers 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/
Current thread:
- [NSE] Extended ssl-enum-ciphers script Bojan Zdrnja (SANS ISC) (Aug 10)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 10)
- Re: [NSE] Extended ssl-enum-ciphers script Bojan Zdrnja (SANS ISC) (Aug 10)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 11)
- Re: [NSE] Extended ssl-enum-ciphers script Royce Williams (Aug 11)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script Royce Williams (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script Bojan Zdrnja (SANS ISC) (Aug 10)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 10)
- Re: [NSE] Extended ssl-enum-ciphers script Bojan Zdrnja (SANS ISC) (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script David Fifield (Aug 12)
- Re: [NSE] Extended ssl-enum-ciphers script Daniel Miller (Aug 12)