Re: Nmap ssl-enum-ciphers

[Daniel Miller <bonsaiviking () gmail com>]

Chris,

Thanks for the feedback. The ssl-enum-ciphers script has undergone a
lot of work this year. Let me address your comments inline as I CC the
development mailing list (the best way to get Nmap's developers
engaged on a question like this):

On Sun, Nov 2, 2014 at 7:08 PM, Chris McNab <chris () cloudsoc net> wrote:
> Looping Dan in also.
>
> Another thing I noticed was that Nmap doesn't perform this testing over
> STARTTLS. I have to manually use openssl s_client --starttls or similar to
> enumerate the TLS protocols and supported cipher suites there. Again, in the
> book, I note that Nmap doesn't support this and indicate a manual approach.

STARTTLS support was added to ssl-enum-ciphers in r32806 (Apr 9),
which was just over a week before the 6.46 release. At that time, only
FTP, SMTP, and XMPP were supported. In our development branch, we have
added support for IMAP, POP3, and LDAP, which will be available in the
next release (6.47 was a bugfix-only release).

> Anyway, I appreciate the fact that you all put effort into the project in
> your spare time, and thank you for it. If you do have plans to fix up the
> script, please let me know so I can keep the book material in-line with
> whatever's current.
>
> Thanks again,
>
> Chris
>
> On Mon, Nov 3, 2014 at 1:00 AM, Chris McNab <chris () cloudsoc net> wrote:
> > Hey guys,
> >
> > I trust you are both well. I'm updating my book for O'Reilly (Network
> > Security Assessment) and referring to your NSE script a lot with regard to
> > enumerating TLS ciphers. From checking Wikipedia and the current state of
> > affairs with regard to SSL 3.0 and TLS 1.0 in particular, the script could
> > do with a bit of an update.
> >
> > Three particular issues with the current script are as follows:
> >
> > CBC mode ciphers within SSL 3.0 and TLS 1.0 aren't strong
> > RC4 is no longer strong as a bulk symmetric cipher
> > 3DES is also not strong (.. according to Wikipedia)
> >
> > The Wikipedia page for TLS summarizes the state of affairs at
> > http://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher.

Ciphersuite strength scores are complicated and can change quickly.
The scores are based on a datafile that can be specified on the
command-line, if users want to provide their own list of ciphersuite
strengths. The file (nselib/data/ssl-ciphers) contains a comment
regarding our calculations:

#!comment: Scoring based on ssllabs.com (Qualys) rating system
#!comment: https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf
#!comment: Anonymous key exchange or NULL encryption are automatic failures
#!comment: Encryption cipher strength weighted 60% and based on key size
#!comment: Key exchange cipher strength weighted 40%. Only penalty is
for EXPORT-grade
#!comment: (truncated key) algorithm. Actual key strength is based on
server's certificate
#!comment: or DH primes, which we don't calculate currently.
#!comment: Score of A is ranked "strong", D and E are "weak", and F is "broken"

The actual scores were last calculated in July 2012 using the Perl
script here: https://gist.github.com/bonsaiviking/3130353
Notably, this script does not consider cipher mode. We have plans to
add DH and DHE parameter measurements in the future, as well as
possibly an on-the-fly strength calculation that would be easier to
update than the current large table.

> > Finally, there is a patch at https://github.com/bojanisc/nmap-scripts
> > which lists the preferred order of ciphers from the server. This
> > functionality is also really useful, and if you could roll it into the
> > official script, that would be awesome.

This was added in r33476, part of a series of empirical improvements
on Aug 12, 2014, based on some Internet-scale scanning. Additionally,
we have made several bugfixes for edge cases that turned up during the
increased use of the script for POODLE detection (we have a much
lighter-weight script called ssl-poodle for that particular
vulnerability now).

> > Anyway, please let me know your thoughts? At the current time, I have
> > notes within my TLS chapter to take the ssl-enum-ciphers strength ratings
> > with a pinch of salt, and manually cross-reference them against Wikipedia
> > and other sources.

It's always a good idea to do your own checking on vulnerability
severities (to which SSL ciphersuite choice is somewhat congruent).

> > Many thanks!

Thank you!
Dan

> > Chris
> >
> >
> > --
> > Chris McNab
> > CloudSOC LLC
> > www.cloudsoc.com
>
>
>
>
> --
> Chris McNab
> CloudSOC LLC
> www.cloudsoc.com
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/