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

[Daniel Miller <bonsaiviking () gmail com>]

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.

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.

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.

Dan


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

> Hi all,
>
> The ssl-enum-ciphers script is very useful in detecting supported ciphers.
> However, it does not retrieve a list of preferred ciphers by the server.
> This is important because administrators can often enable desired ciphers
> (such as PFS ciphers), but they incorrectly set the preferred cipher suite
> order on the server. This can result in non-PFS cipher suites selected,
> although both the server and the client support PFS.
> This happens because the client sends the list of the supported ciphers and
> the server picks "the strongest one" according to its preferred list - so
> if there is any other cipher common between the client and the server, and
> it has higher priority than the PFS cipher, it will be selected.
>
> SSL Labs' shows this when testing reference browsers, but I wanted to be
> able to check this myself, from command line, especially when I'm testing
> servers that are not reachable to SSL Labs (or I don't want them
> to see the results).
>
> So I modified the Nmap's ssl-enum-ciphers.nse script to list preferred
> ciphers in addition to just enumerating ciphers.
>
> The script's output now looks like this (the preferred ciphers order is
> new):
>
> Host is up (0.037s latency).
> PORT    STATE SERVICE
> 443/tcp open  https
> | ssl-enum-ciphers:
> |   SSLv3:
> |     ciphers:
> |       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
> |       TLS_RSA_WITH_RC4_128_MD5 - strong
> |       TLS_RSA_WITH_RC4_128_SHA - strong
> |     preferred ciphers order:
> |       TLS_RSA_WITH_RC4_128_SHA
> |       TLS_RSA_WITH_3DES_EDE_CBC_SHA
> |       TLS_RSA_WITH_RC4_128_MD5
> |     compressors:
> |       NULL
> |   TLSv1.0:
> |     ciphers:
> |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
> |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
> |       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
> |       TLS_RSA_WITH_AES_128_CBC_SHA - strong
> |       TLS_RSA_WITH_AES_256_CBC_SHA - strong
> |       TLS_RSA_WITH_RC4_128_MD5 - strong
> |       TLS_RSA_WITH_RC4_128_SHA - strong
> |     preferred ciphers order:
> |       TLS_RSA_WITH_AES_128_CBC_SHA
> |       TLS_RSA_WITH_AES_256_CBC_SHA
> |       TLS_RSA_WITH_RC4_128_SHA
> |       TLS_RSA_WITH_3DES_EDE_CBC_SHA
> |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> |       TLS_RSA_WITH_RC4_128_MD5
> |     compressors:
> |       NULL
> |_  least strength: strong
>
>
> You can see that this particular server (for TLSv1.0) does support PFS
> ciphers (the ECDHE ones), but its preferred order results in the client's
> probably picking the non-PFS ciphers.
>
> The script is available at https://github.com/bojanisc/nmap-scripts - I
> tested it quite a bit and it works OK so I think it might be a good
> addition to the set of scripts included with Nmap.
>
> I will also post a SANS ISC (https://isc.sans.edu) diary about this
> tomorrow.
>
> Cheers,
>
> Bojan
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/