Re: Order ciphers in preferred server order for ssl-enum-ciphers.nse

[Daniel Miller <bonsaiviking () gmail com>]

On 04/19/2013 05:23 AM, Richard van den Berg wrote:
> Did you get a change to test the patch yet? IMHO this would be a very
> useful feature to have in nmap.
Richard,

I tested your patch today, and I'm afraid that it's not working as 
expected. I am getting back different orderings from several hosts, both 
on my own LAN and on the Internet. Using Ndiff to compare from one run 
to the next shows that the orderings have changed. Here's an example 
diff from 2 runs on secwiki.org (Apache 2.2.15):

>  li594-254.members.linode.com, secwiki.org (192.81.131.254):
>  PORT    STATE SERVICE VERSION
>  443/tcp open  https
>  |  ssl-enum-ciphers:
>  |    SSLv3:
>  |      ciphers:
>  |        TLS_RSA_WITH_AES_128_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
>  |        TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> +|        TLS_RSA_WITH_AES_256_CBC_SHA - strong
> +|        TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
>  |        TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
> -|        TLS_RSA_WITH_RC4_128_SHA - strong
> -|        TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
>  |        TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
> -|        TLS_RSA_WITH_SEED_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
> -|        TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
>  |        TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
>  |      compressors:
>  |        NULL
>  |    TLSv1.0:
>  |      ciphers:
> +|        TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> +|        TLS_RSA_WITH_RC4_128_SHA - strong
> +|        TLS_RSA_WITH_AES_128_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
> +|        TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> +|        TLS_RSA_WITH_SEED_CBC_SHA - strong
>  |        TLS_RSA_WITH_AES_256_CBC_SHA - strong
> -|        TLS_RSA_WITH_AES_128_CBC_SHA - strong
> -|        TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> +|        TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
> +|        TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
>  |        TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
>  |        TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
> -|        TLS_RSA_WITH_SEED_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
> -|        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
> -|        TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
>  |        TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
>  |      compressors:
>  |        NULL
>  |_   least strength: strong

The LAN hosts that were different were XenServer hypervisors, and other 
hosts with problems were xkcd.com (lighttpd 1.4.28) and 
stackoverflow.com (nginx). I had no differences in 3 runs on github.com 
(unidentified "GitHub.com"), technet.microsoft.com (Microsoft IIS httpd 
8.0), or eos.apache.org (Apache httpd 2.4.4 OpenSSL/1.0.0g).

I'm not sure the best way to proceed. I think the best thing would be to 
keep the current behavior as a default, and have the script accept a 
script-arg to enable this type of sorting. That way nobody is surprised 
by differences in their scan results, and the ability to try to 
determine cipher-preference is made available if the user wants it.

Dan

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