Re: Default SSL/TLS ciphers lists for Nsock

[Jacek Wielemborek <d33tah () gmail com>]

W dniu 24.09.2015 o 05:51, Daniel Miller pisze:
> List,
>
> We have a small conundrum that I'd like to hear some feedback on. Recently,
> a couple of users noticed that Nmap is failing to connect to a TLS service
> during the version detection phase [1]. This turns out to be because of the
> ciphers selected in Nsock. These ciphers are selected from one of two
> options:
>
> /* Disallow anonymous ciphers (Diffie-Hellman key agreement), low
> > bit-strength
> >  * ciphers, export-crippled ciphers, and MD5. Prefer ciphers in decreasing
> > order
> >  * of key size. The cipher list is taken from the book Network Security
> > with
> >  *  OpenSSL. To see exactly what ciphers are enabled, use the command
> >  *   openssl ciphers -v '...'
> >  * where ... is the string below. */
> > #define CIPHERS_SECURE "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
> >
> > /* This list of ciphers is for speed and compatibility, not security. Any
> > cipher
> >  *  is accepted, and the list is sorted by speed based on Brian Hatch's
> >  *  (bri () ifokr org) tests on an Pentium 686 against the ciphers listed. */
> > #define CIPHERS_FAST
> > "RC4-SHA:RC4-MD5:NULL-SHA:EXP-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-RC4-MD5:NULL-MD5:EDH-RSA-DES-CBC-SHA:EXP-RC2-CBC-MD5:EDH-RSA-DES-CBC3-SHA:EXP-ADH-RC4-MD5:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:EXP-ADH-DES-CBC-SHA:ADH-AES256-SHA:ADH-DES-CBC-SHA:ADH-RC4-MD5:AES256-SHA:DES-CBC-SHA:DES-CBC3-SHA:ADH-DES-CBC3-SHA:AES128-SHA:ADH-AES128-SHA:eNULL:ALL"
>
> CIPHERS_SECURE is the default, but both service scan and NSE pass the
> NSOCK_SSL_MAX_SPEED flag to use CIPHERS_FAST.
>
> The cipher list here does not actually affect speed in many (if not most)
> cases, since the server will choose based on its own preference. In some
> cases, the client's cipher order is preferred, so there may be a small
> speed concern, but most computers should not have any problem keeping up
> with the load in any case.
>
> The primary concern, therefore, should be compatibility. We want to be able
> to connect to the widest range of possible server configurations. Here are
> my thoughts:


Sounds like a difficult choice, perhaps because it depends on the
scenario. Perhaps it's justified to add a command-line switch that
regulates the behavior?

> 1. Simplest option would be "DEFAULT:ALL" since that puts the most-likely
> modern options first, and follows with everything else.

I'd say that perhaps #1 is a simple solution that might be good enough -
depending on whether we get any bug reports after this change.

> 2. Some servers don't look at all suites offered. This is why we cap the
> list at 64 in ssl-enum-ciphers. Microsoft IIS is one example (Schannel).
> Putting ALL in at the end doesn't help if we list 64 or more poor choices
> first.

Could the list be ordered randomly? Perhaps another try with a different
order would help determine the algorithm.

> 3. A few very rare services will not respond if the ClientHello record
> exceeds 255 bytes. This is nearly impossible to work around given our
> constraints (want to offer lots of ciphers, OpenSSL has no interface to
> specify handshake byte length), so probably can't avoid it.

Are those services important?

> 4. We already have a system in place to reconnect if the server doesn't
> like our SSLv2-compatible handshake (though I don't think we send this with
> newer OpenSSL versions?) in nsock_core.c. Perhaps this system could be
> extended to modify the ciphersuite list, too?
>
> I appreciate your thoughts.
>
> Dan
>
> [1] http://seclists.org/nmap-dev/2015/q3/313

Attachment: signature.asc
Description: OpenPGP digital signature

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