Re: [NSE] SSLv3/TLSv1 cipher and compression algorithm enumeration script

[David Fifield <david () bamsoftware com>]

On Mon, Feb 22, 2010 at 10:00:14PM -0600, Mak Kolybabi wrote:
> On 2010-02-19 13:58, David Fifield wrote:
> > I agree that the name should be changed. Maybe ssl-enum-ciphers.
>
> I dislike that name on the basis that it also enumerates compression
> algorithms. Perhaps ssl-enum-algorithms?

I like this script a lot. I committed it in r16847.

I understand your objection about the name of the script. I can't think
of a name that's wholly satisfactory to me. I committed it with the name
ssl-enum-ciphers, even though the script does more than that. Your
original name was sslv3-enum. Now that I'm thinking about it, maybe
ssl-enum is better. People understand "SSL" to encompass both SSL and
TLS. The only problem is that the script doesn't work with SSLv2 or
earlier, but we have sslv2.nse for that.

I like the new default behavior of printing results in the order they
are accepted by the remote server. I changed the name of the "sort"
script argument to "ssl-enum-ciphers.sort".

The new changes look great. I'm getting different results than before
against Ncat, though:

| ssl-enum-algorithms:
|   SSLv3
|     Ciphers (5)
|       TLS_RSA_WITH_AES_128_CBC_SHA
|       TLS_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_IDEA_CBC_SHA
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_RSA_WITH_RC4_128_SHA
|     Compressors (1)
|       uncompressed
|   TLSv1.0
|     Ciphers (5)
|       TLS_RSA_WITH_AES_128_CBC_SHA
|       TLS_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_IDEA_CBC_SHA
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_RSA_WITH_RC4_128_SHA
|     Compressors (1)
|_      uncompressed

Before, it was giving me results from TLSv1.1 and TLSv1.2 also. Do you
have an idea what might have caused the change, and which results are
correct? The previous results are at
http://seclists.org/nmap-dev/2010/q1/601.

> > You should switch the order of the first two paragraphs in the
> > description. The first paragraph is shown as the summary in NSEDoc, and
> > what you have now as the second paragraph is more descriptive of what
> > the script does.
>
> I've rewritten the description to reflect that I now use a better
> algorithm that was suggested to me, which is *way* faster.

The new algorithm is a great idea! For everyone else, the way it worked
at first was that the script would initiate a connection using each one
of its known ciphers individually, and keep track of which ones worked
and which didn't. Now, it starts by offering all ciphers at once, and
removes them one at a time as the server accepts them (one per
connection) until the server rejects them all.

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