Re: Disable SSLv3 and set cipher list for bozohttpd
Jean-Yves Migeon <[email protected]> Thu, 10 Dec 2015 12:22:55 +0100
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Organization | The NetBSD Foundation |
| Message-ID | <[email protected]> |
Le 2015-12-10 02:55, Thor Lancelot Simon a écrit : > On Wed, Dec 09, 2015 at 08:33:35PM -0500, [email protected] wrote: >> >> >Le 2015-12-08 21:58, [email protected] a ??crit??: >> >>Why not supply the ! list (the ones you want to remove)... It is shorter >> >>and easier to understand and maintain... >> >> I agree, much simpler! > > I don't. Opinions may differ, but I am not a fan of this particular > kind > of "algorithm agility". > > Pick a small set of ciphersuites, chosen for backwards compatibility > with peers > that do only the minimum the standards mandate as a first criterion, > and > the consensus of experts about the best current and future > alternatives, > and forget the rest. Often all they can buy you is confusion and > trouble. > > I would like to see, at most, four ciphersuites supported by default. Ouchie, to be widely accepted by most SSL stacks this is an achievement. This reduces the set of algos the clients might select, which could be arguably "better/faster/stronger". You at least have to support ECDSA and RSA given that ECDSA is far from being usable everywhere, so that leaves two ciphersuites left to chose. FWIW Apple enforces those for app transport security (not saying the same path should be taken, but still interesting); ECDHE requires TLS 1.2 if I am not mistaken, which rules out quite a few clients out there [1] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA And there are still DHE with 1024+ keys, poly1305/chacha20, and SHA3 which will probably end up as an alternative for the various HMACs that uses SHA1 or SHA2. [1] https://dev.ssllabs.com/ssltest/clients.html -- Jean-Yves Migeon