Nmap Development mailing list archives
Re: Nmap ssl-enum-ciphers
From: Daniel Miller <bonsaiviking () gmail com>
Date: Sun, 2 Nov 2014 20:30:50 -0600
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/
Current thread:
- Re: Nmap ssl-enum-ciphers Daniel Miller (Nov 02)