The blacklist does look too radical to me as well. My server was configured with some in that list.
Also it can place a server admin in a tough position e.g. what if they want to support IE8, or maybe android2 which doesn thave tls 1.2 stuff, but also support h2, they would be forced to choose one or the other. On 16 October 2015 at 11:45, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Hi Yann, > > I am not a cipher expert enough to know why the list in RFC 7540 was compiled > this way... :( > > But indeed, there is a good sized overlap. And that does not make sense. I > have sent a mail to the httpwg mailing list, asking for enlightment. > > If the blacklist in RFC 7540 proves to be totally bogus, I'd favor ditching > it in our server checks. > > However there are some value to be had in checking that user's do not > activate "unsafe" ciphers by accident. If an admin can configure our server > to have something like the categories described at > https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility that > could help. > > What I mean is an SSL config where I can say: > > SSLCompatibility modern|intermediate|old|custom > > (or something along the lines), it could be a safeguard against all other SSL > parameter configs. The defaults for ciphers and other params could change > according to this, or at least WARNINGS could be logged in case a negotiated > connection violates it. Maybe > > SSLCompatibilityPolicy warn|enforce|ignore > > ??? > >> Am 16.10.2015 um 12:21 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> On Wed, Oct 14, 2015 at 2:10 PM, <ic...@apache.org> wrote: >>> Author: icing >>> Date: Wed Oct 14 12:10:11 2015 >>> New Revision: 1708593 >>> >>> URL: http://svn.apache.org/viewvc?rev=1708593&view=rev >>> Log: >>> mod_http2: new directive H2Compliance on/off, checking TLS protocol and >>> cipher against RFC7540 >>> >> [] >>> >>> Modified: httpd/httpd/trunk/modules/http2/h2_h2.c >>> URL: >>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_h2.c?rev=1708593&r1=1708592&r2=1708593&view=diff >>> ============================================================================== >>> --- httpd/httpd/trunk/modules/http2/h2_h2.c (original) >>> +++ httpd/httpd/trunk/modules/http2/h2_h2.c Wed Oct 14 12:10:11 2015 >>> @@ -54,6 +54,354 @@ APR_DECLARE_OPTIONAL_FN(int, ssl_is_http >> [] >>> +/* >>> + * Black Listed Ciphers from RFC 7549 Appendix A >>> + * >>> + */ >>> +static const char *RFC7540_names[] = { >> >> Wow, that's a pretty long list, and rather disputable IMHO... >> >> [] >>> + >>> + /* blacklisted AES128 encrpytion ciphers */ >> [] >>> + "DHE-RSA-AES128-SHA256", /* >>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 */ >> [] >>> + "ECDHE-ECDSA-AES128-SHA256", /* >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 */ >> [] >>> + "ECDHE-RSA-AES128-SHA256", /* >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 */ >> [] >>> + "AES128-GCM-SHA256", /* TLS_RSA_WITH_AES_128_GCM_SHA256 >>> */ >> [] >>> + >>> + /* blacklisted AES256 encrpytion ciphers */ >> [] >>> + "DHE-RSA-AES256-SHA256", /* >>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 */ >> [] >>> + "ECDHE-ECDSA-AES256-SHA384", /* >>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 */ >> [] >>> + "ECDHE-RSA-AES256-SHA384", /* >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 */ >> [] >>> + "AES256-GCM-SHA384", /* TLS_RSA_WITH_AES_256_GCM_SHA384 >>> */ >> [] >>> + >>> + /* blacklisted CAMELLIA128 encrpytion ciphers */ >> [] >>> + "ECDHE-ECDSA-CAMELLIA128-SHA256", /* >>> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 */ >> [] >>> + "ECDHE-RSA-CAMELLIA128-SHA256", /* >>> TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 */ >> [] >>> + "CAMELLIA128-GCM-SHA256", /* >>> TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 */ >> [] >>> + "DHE-RSA-CAMELLIA128-SHA256", /* >>> TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 */ >> [] >>> + >>> + /* blacklisted CAMELLIA256 encrpytion ciphers */ >> [] >>> + "ECDHE-ECDSA-CAMELLIA256-SHA384", /* >>> TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 */ >> [] >>> + "ECDHE-RSA-CAMELLIA256-SHA384", /* >>> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 */ >> [] >>> + "DHE-RSA-CAMELLIA256-SHA256", /* >>> TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 */ >> [] >>> + "CAMELLIA256-GCM-SHA384", /* >>> TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 */ >> [] >>> +}; >> >> Any idea why those above are blacklisted? >> Looks like they decided to blacklist all non-ECDHe or CBC based cipher >> suites, that's quite radical! >> AFAICT, they are all (still) safe ciphers, maybe CBC ones are >> "vulnerable" to timing attacks with SSL/TLS (lucky13 like, which >> should have been addressed/countermeasured in most TLS libs though), >> and DHE ones have lower performances due to network overhead with >> big(ger) RSA keys, but what about RSA+GCM ones (which is still the >> reference in AEAD cryptography!) with a reference block cipher (AES, >> CAMELLIA, ...)? >> >> And maybe more importantly, what remains currently? >> >> I tried: >> $ openssl ciphers -v 'TLSv1.2:!kRSA:!aECDH:!DH' >> >> With openssl-1.0.2, this let us: >> - ECDHE-RSA-AES256-GCM-SHA384 >> - ECDHE-ECDSA-AES256-GCM-SHA384 >> - ECDHE-RSA-AES256-SHA384 >> - ECDHE-ECDSA-AES256-SHA384 >> - ECDHE-RSA-AES128-GCM-SHA256 >> - ECDHE-ECDSA-AES128-GCM-SHA256 >> - ECDHE-RSA-AES128-SHA256 >> - ECDHE-ECDSA-AES128-SHA256 >> >> Whereas libressl-2.2.1 also adds: >> - ECDHE-RSA-CHACHA20-POLY1305 >> - ECDHE-ECDSA-CHACHA20-POLY1305 >> >> Quite restrictive (even though those are obviously solid ciphers, >> maybe IMHO modulo the complicated ECDSA mode which is disputed)... >> >> BTW, if I am correct, maybe the SSLCipherSuite >> 'TLSv1.2:!kRSA:!aECDH:!DH' could be used/documented to avoid >> whitelisting in httpd configurations (missing new/compatible ciphers >> added to the TLS libs over time)... >> >> PS: note that the SSLCipherSuite given in >> https://icing.github.io/mod_h2/howto.html#https includes some in the >> above blacklist. >
