Re: [NSE] modified ssl-enum-ciphers to indicate policy compliance

[David Fifield <david () bamsoftware com>]

On Wed, May 11, 2011 at 04:45:56PM -0700, Gabriel Lawrence wrote:
> David,
>
> Thanks. I decided to join the mail list so I'd see these things from now on.
> I finally got a chance to make the changes recommended below. Attached are
> the new files. Let me know if you think anything else should be tweaked or
> if these are good to go!
>
> PS: I don’t really consider my neckbeard to be awesome enough to make
> recommendations for the world on what reasonable ciphers should be on their
> default list. I took a wag at it anyway, so some review of that list
> wouldn’t be a bad idea. I don’t think I included anything bad, but I may
> have omitted something good.

I compared your list of strong ciphers against the independent list of
weak ciphers contributed in http://seclists.org/nmap-dev/2011/q3/258.

I made a file with all the ciphers called mak-all.txt, then
gabe-strong.txt with your list and ygn-weak with YGN's, then did
        sort mak-all.txt gabe-strong.txt | uniq -u > gabe-weak.txt
        sort mak-all.txt ygn-weak.txt | uniq -u > ygn-strong.txt
There are then four ciphers in both ygn-weak.txt and ygn-strong.txt that
are not in mak-all.txt:
        SSL_CK_RC4_64_WITH_MD5
        TLS_DES_64_CBC_WITH_MD5
        TLS_RC2_128_CBC_EXPORT40_WITH_MD5
        TLS_RC4_128_EXPORT40_WITH_MD5
I manually removed them from ygn-strong.txt.

$ wc -l mak-all.txt
199 mak-all.txt
$ wc -l gabe-*
  42 gabe-strong.txt
 157 gabe-weak.txt
 199 total
$ wc -l ygn-*
 142 ygn-strong.txt
  61 ygn-weak.txt
 203 total

The difference in sizes is quite big; what this tells me is that there
are probably members of Gabe's not-strong set that are strong, and
members of YGN's not-weak set that are weak. I'm attaching the files so
you can do for example
        diff -u gabe-strong.txt ygn-strong.txt

So what I'm thinking is that we don't want to handle this as an explicit
"strong" set (with implicit "weak" complement) or as an explicit "weak"
set (with implicit "strong" complement). What we should have, at least,
is an explicit "strong," and explicit "weak," and an implicit
"uncategorized."

So here's what I want:
1. A new data file nselib/data/ssl-ciphers, the same as your current
   samplegoodciphers, but with another column containing "strong":
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA      strong
TLS_RSA_WITH_3DES_EDE_CBC_SHA           strong
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        strong
   The idea, of course, is that we can add new lines with "weak", but
   don't do that now. Anything not in the file will be considered
   unknown strength.
2. Make ssl-enum-ciphers.nse use nselib/data/ssl-ciphers by default,
   without requiring a script argument. Naturally, it has to parse the
   "strong" column.
3. Make the output look like this:
|   SSLv3
|     Ciphers (7)
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - unknown strength
|_  Least strength = unknown strength
   That's from "ncat -l -k --ssl" by the way. Your check for "Compliant = true"
   will become one for "Least strength = strong". The ordering of
   strength levels should be "strong" > "unknown strength" > "weak".

Can you do all this? I think it is necessary to avoid the problems of
false positives/false negatives from ciphers not being listed in the
cipher file, and also to make the output easier to understand (it's not
obvious what the asterisks mean if you're not doing SSL cipher
auditing).

David Fifield

Attachment: mak-all.txt
Description:

Attachment: gabe-weak.txt
Description:

Attachment: gabe-strong.txt
Description:

Attachment: ygn-weak.txt
Description:

Attachment: ygn-strong.txt
Description:

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