[Ach] [ssllabs-discuss] Minimal recommended cipher suite list, pref. as an interactive SSL Labs page

[Hubert Kario]

----- Original Message -----
> From: "Aaron Zauner" <azet at azet.org>
> To: "Hubert Kario" <hkario at redhat.com>
> Cc: "ianG" <iang at iang.org>, ssllabs-discuss at lists.sourceforge.net, "ach at lists.cert.at List Mailing"
> <ach at lists.cert.at>
> Sent: Thursday, June 12, 2014 2:04:57 PM
> Subject: Re: [Ach] [ssllabs-discuss] Minimal recommended cipher suite list, pref. as an interactive SSL Labs page
> 
> Hi,
> 
> Hubert Kario wrote:
> > 
> > There's nothing wrong with DSS (when used correctly), current standard
> > allows for keys up to 3072 bit in size so they are basically as secure
> > as RSA. Also, if you don't have a DSS certificate, presence or absence
> > of DSS cipher suites has no impact on the supported cipher suites what
> > so ever (I'm assuming we're still talking about sever side).
> This is true for the current DSS spec. for example: OpenSSH still does
> not support it. I'm unsure of how that's going with Webserver daemons.

Tested it, mod_ssl 2.2.15 handles 2048 bit DSS keys without a slightest hitch.
mod_nss doesn't support DSS at all since NSS doesn't support server side DHE.

> >> Another issue is
> >> that these cipherstrings work differently on OpenSSL =< 0.9.8 and
> >> OpenSSL >= 1.0.0 - all do not include GnuTLS (we do not either). As well
> >> as other TLS libraries.
> > 
> > I assume that you mean the preference of RC4-SHA over AES128-SHA or
> > AES256-SHA with 0.9.8?
> 
> (OpenSSL 0.9.8 tree was excluding all ephemeral DH
> ciphersuites) and fixed that with a modification that now parses
> correctly in 0.9.8 and 1.0.0+. There has been a short discussion
> regarding this topic on the openssl-dev mailing list.

Hmm... The mozilla cipher suite does put DHE ciphers before ones
with RSA key exchange, so it behaves as expected. Maybe it was already
worked around...

> I've come to the conclusion that it is extremely difficult to provide
> sane and secure cipherstring recommendations even with proper peer
> review by security experts; given differences in SSL libraries (most
> only talk about OpenSSL), even differences in different versions of the
> same library, client and server software and protocol stacks. So far no
> project does a really good job at that, none include stuff like Apple
> Crypto Framework, SChannel, GnuTLS, PolarSSL, Botan [...].

Oh, sure, it's not easy. But if we have a large list that is a superset
of all the generally supported cipher suites (which openssl should be),
then removing cipher suites shouldn't have too severe impact on the
security, as long as the library itself supports at least one secure
cipher suite.

The admin just must not perform the cargo cult thing and actually check
if the resulting cipher suite set is sane for the version of crypto
library he or she uses.
 
> Because of these issues we've ran into I've recently written a set of
> shell scripts to do testing of cipherstring negotiation and preference
> for different versions of openssl. I'm still lacking a tool that does
> this for all popular TLS libraries and I'm probably not going to write
> something like that in the near future.

Well, if you're testing just server side, then
https://github.com/jvehent/cipherscan
should be enough. It requires just bash (you can use statically
compiled openssl, either the included one or one you compiled yourself).
-- 
Regards,
Hubert Kario