Re: H2 compatible ciphers

[Reindl Harald]

Am 17.10.2015 um 11:18 schrieb Kaspar Brand:

Another - quite radical - approach would consist of using a whitelist,
which consists of a single cipher suite only: given that section 9.2 of
RFC 7540 states

"Implementations of HTTP/2 MUST use TLS version 1.2"

and section 9.2.2 further says

"deployments of HTTP/2 that use TLS 1.2 MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
elliptic curve [FIPS186]"

then "H2Compliance on" would only have to make sure that this exact
suite is negotiated. (What this MTI cipher suite also means, IINM, is
that you can't run an RFC 7540 h2 compliant server with an ECDSA key
only, actually... not sure if that was really an intended effect of this
requirement.)


terrible idea because it would lead to disable new, safer and 
recommended ciphers in the future until somebody adds them to the whitelist


so users (clientside) would have to wait for openssl *and* apache after 
their browser has already support and with the current release cycles of 
all major browsers it's likely to end that way




signature.asc
Description: OpenPGP digital signature

Re: H2 compatible ciphers

[Kaspar Brand]

On 16.10.2015 12:45, Stefan Eissing wrote:
> If the blacklist in RFC 7540 proves to be totally bogus, I'd favor
> ditching it in our server checks.

Sharing Yann's surprise about this huge blacklist... I'm also wondering
if this won't become a Sisyphean task, in the end (will the httpwg
regularly amend that list, BTW, or how do they intend to prevent
"unwanted" cipher suites from being used with HTTP/2?).

Another - quite radical - approach would consist of using a whitelist,
which consists of a single cipher suite only: given that section 9.2 of
RFC 7540 states

"Implementations of HTTP/2 MUST use TLS version 1.2"

and section 9.2.2 further says

"deployments of HTTP/2 that use TLS 1.2 MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
elliptic curve [FIPS186]"

then "H2Compliance on" would only have to make sure that this exact
suite is negotiated. (What this MTI cipher suite also means, IINM, is
that you can't run an RFC 7540 h2 compliant server with an ECDSA key
only, actually... not sure if that was really an intended effect of this
requirement.)

Kaspar

Re: H2 compatible ciphers

[Stefan Eissing]

Yes, I think whatever improvements we make, they need to be open for admin 
overrides. OTOH the majority of the deployments will want to have sth like 
modern/intermediate/old and get whatever that exactly means delivered by us as 
regular updates in releases (or via their distros).

Especially with more sites adding https for h2 and hopefully let's encrypt 
coming online soon. 

> Am 17.10.2015 um 11:50 schrieb Reindl Harald :
> 
> 
> 
>> Am 17.10.2015 um 11:18 schrieb Kaspar Brand:
>> Another - quite radical - approach would consist of using a whitelist,
>> which consists of a single cipher suite only: given that section 9.2 of
>> RFC 7540 states
>> 
>> "Implementations of HTTP/2 MUST use TLS version 1.2"
>> 
>> and section 9.2.2 further says
>> 
>> "deployments of HTTP/2 that use TLS 1.2 MUST support
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
>> elliptic curve [FIPS186]"
>> 
>> then "H2Compliance on" would only have to make sure that this exact
>> suite is negotiated. (What this MTI cipher suite also means, IINM, is
>> that you can't run an RFC 7540 h2 compliant server with an ECDSA key
>> only, actually... not sure if that was really an intended effect of this
>> requirement.)
> 
> terrible idea because it would lead to disable new, safer and recommended 
> ciphers in the future until somebody adds them to the whitelist
> 
> so users (clientside) would have to wait for openssl *and* apache after their 
> browser has already support and with the current release cycles of all major 
> browsers it's likely to end that way
> 

H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

On Wed, Oct 14, 2015 at 2:10 PM,   wrote:
> Author: icing
> Date: Wed Oct 14 12:10:11 2015
> New Revision: 1708593
>
> URL: http://svn.apache.org/viewvc?rev=1708593=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=1708592=1708593=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.

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Stefan Eissing]

I am not blacklisting ciphers for the whole server. I try to define
the security settings required for HTTP/2 as defined in the standard -
as a configurable directive.

There is no problem with denying HTTP/2 support for an IE8.

//Stefan

> Am 16.10.2015 um 12:53 schrieb Chris :
> 
> 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
>  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 :
>>> 
>>> On Wed, Oct 14, 2015 at 2:10 PM,   wrote:
 Author: icing
 Date: Wed Oct 14 12:10:11 2015
 New Revision: 1708593
 
 URL: http://svn.apache.org/viewvc?rev=1708593=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=1708592=1708593=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 

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

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
 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 :
>>
>> On Wed, Oct 14, 2015 at 2:10 PM,   wrote:
>>> Author: icing
>>> Date: Wed Oct 14 12:10:11 2015
>>> New Revision: 1708593
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1708593=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=1708592=1708593=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 

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Stefan Eissing]

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 :
> 
> On Wed, Oct 14, 2015 at 2:10 PM,   wrote:
>> Author: icing
>> Date: Wed Oct 14 12:10:11 2015
>> New Revision: 1708593
>> 
>> URL: http://svn.apache.org/viewvc?rev=1708593=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=1708592=1708593=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
> - 

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

On Fri, Oct 16, 2015 at 1:38 PM, Yann Ylavic  wrote:
>
> Actually I tried some brute bash script (attached) to show what
> remains compared to "openssl ciphers ALL", and the result is:
>
> * libressl/install/2.2.1/bin/openssl:
> - ECDHE-ECDSA-CHACHA20-POLY1305
> - ECDHE-RSA-CHACHA20-POLY1305
> - DHE-RSA-CHACHA20-POLY1305
> - ECDHE-RSA-AES256-GCM-SHA384
> - ECDHE-ECDSA-AES256-GCM-SHA384
> - DHE-DSS-AES256-GCM-SHA384
> - DHE-RSA-AES256-GCM-SHA384
> - GOST2012256-GOST89-GOST89
> - GOST2001-GOST89-GOST89
> - ECDHE-RSA-AES128-GCM-SHA256
> - ECDHE-ECDSA-AES128-GCM-SHA256
> - DHE-DSS-AES128-GCM-SHA256
> - DHE-RSA-AES128-GCM-SHA256
> - EDH-RSA-DES-CBC3-SHA
> - EDH-DSS-DES-CBC3-SHA
> - EDH-RSA-DES-CBC-SHA
> - EDH-DSS-DES-CBC-SHA
>
> * openssl/install/1.0.2d/bin/openssl:
> - ECDHE-RSA-AES256-GCM-SHA384
> - ECDHE-ECDSA-AES256-GCM-SHA384
> - DHE-DSS-AES256-GCM-SHA384
> - DHE-RSA-AES256-GCM-SHA384
> - ECDHE-RSA-AES128-GCM-SHA256
> - ECDHE-ECDSA-AES128-GCM-SHA256
> - DHE-DSS-AES128-GCM-SHA256
> - DHE-RSA-AES128-GCM-SHA256
> - EDH-RSA-DES-CBC3-SHA
> - EDH-DSS-DES-CBC3-SHA
> - EDH-RSA-DES-CBC-SHA
> - EDH-DSS-DES-CBC-SHA
> - EXP-EDH-RSA-DES-CBC-SHA
> - EXP-EDH-DSS-DES-CBC-SHA
>
> So 'TLSv1.2:!kRSA:!aECDH:!DH' is a bit too restrictive

Looks like 'ALL:!SSLv3:!kRSA:!ADH:!aECDH' matches pretty well
(excluding for the undesirable ones above).

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Graham Leggett]

On 16 Oct 2015, at 12:56 PM, Stefan Eissing  
wrote:

> I am not blacklisting ciphers for the whole server. I try to define
> the security settings required for HTTP/2 as defined in the standard -
> as a configurable directive.
> 
> There is no problem with denying HTTP/2 support for an IE8.

I am wondering whether the cipher blacklist shouldn’t be a configurable list 
with a default set of RFC compliant values in the default config file, perhaps 
with shortcuts like naming a blacklist after an RFC.

Fitting this in with the existing infrastructure this could be as simple as 
extending the SSLCipherSuite directive to support this:

SSLCipherSuite -RFC7540

Maybe this is actually an openssl problem rather than an httpd problem, it 
could be that openssl needs to be taught how to blacklist RFC7540 as a group.

Regards,
Graham
—

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Stefan Eissing]

Yes, I proposed something along those lines at the http workshop this summer. 
Needs some more pushing, it seems.

There is one thing that I understood to be implied by all this: that h2 is not 
negotiated when the security is too weak. Which, the more I think and 
implemented about it, does not make sense. But I asked for input from the wg, 
see what they say...

Back to our little world:

I find the definitions on the mozilla wiki helpful. They might not be perfect 
(yet), but it is better to start defining security parameter sets than staring 
at SSL configuration strings and figuring out if they all together do what you 
want.

As we have seen, security is highly in flux, thanks to some smart guys with 
unlimited funding, and placing recommended mod_ssl configurations on a web site 
will do nothing for the millions of servers out there.

I think can do better and offer a config file to users of httpd that defines 
security policies and
- gets updated every release
- is downloadable by itself, copy it into your installation and reload

So, admins would add
  
  SecurityPolicy modern

to their config files and every httpd update would bring that to the lastest 
and greatest specification.

Of course, there is potential for breakage here. But maybe one prefers that to 
being insecure with not updated clients...

//Stefan

> Am 16.10.2015 um 13:36 schrieb Graham Leggett :
> 
> On 16 Oct 2015, at 12:56 PM, Stefan Eissing  
> wrote:
> 
>> I am not blacklisting ciphers for the whole server. I try to define
>> the security settings required for HTTP/2 as defined in the standard -
>> as a configurable directive.
>> 
>> There is no problem with denying HTTP/2 support for an IE8.
> 
> I am wondering whether the cipher blacklist shouldn’t be a configurable list 
> with a default set of RFC compliant values in the default config file, 
> perhaps with shortcuts like naming a blacklist after an RFC.
> 
> Fitting this in with the existing infrastructure this could be as simple as 
> extending the SSLCipherSuite directive to support this:
> 
> SSLCipherSuite -RFC7540
> 
> Maybe this is actually an openssl problem rather than an httpd problem, it 
> could be that openssl needs to be taught how to blacklist RFC7540 as a group.
> 
> Regards,
> Graham
> —
> 

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

On Fri, Oct 16, 2015 at 12:21 PM, Yann Ylavic  wrote:
>
> And maybe more importantly, what remains currently?

Actually I tried some brute bash script (attached) to show what
remains compared to "openssl ciphers ALL", and the result is:

* libressl/install/2.2.1/bin/openssl:
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-CHACHA20-POLY1305
- DHE-RSA-CHACHA20-POLY1305
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES256-GCM-SHA384
- DHE-DSS-AES256-GCM-SHA384
- DHE-RSA-AES256-GCM-SHA384
- GOST2012256-GOST89-GOST89
- GOST2001-GOST89-GOST89
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-GCM-SHA256
- DHE-DSS-AES128-GCM-SHA256
- DHE-RSA-AES128-GCM-SHA256
- EDH-RSA-DES-CBC3-SHA
- EDH-DSS-DES-CBC3-SHA
- EDH-RSA-DES-CBC-SHA
- EDH-DSS-DES-CBC-SHA

* openssl/install/1.0.2d/bin/openssl:
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES256-GCM-SHA384
- DHE-DSS-AES256-GCM-SHA384
- DHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-GCM-SHA256
- DHE-DSS-AES128-GCM-SHA256
- DHE-RSA-AES128-GCM-SHA256
- EDH-RSA-DES-CBC3-SHA
- EDH-DSS-DES-CBC3-SHA
- EDH-RSA-DES-CBC-SHA
- EDH-DSS-DES-CBC-SHA
- EXP-EDH-RSA-DES-CBC-SHA
- EXP-EDH-DSS-DES-CBC-SHA

Some 'TLSv1.2:!kRSA:!aECDH:!DH' is a bit too restrictive, and their
blacklist a bit broken anymay (I wouldn't recommend the latters :)
I'll try a better one, but it would be nice if the httpwg could
express their blacklist in terms of authentication/key-exchange
methods and block-ciphers/stream-ciphers instead of this "out of the
hat" list.

By the way the SSLCompatibility idea is great, was not my point, but
maybe this can give you some bits for httpwg mailing list...

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

On Fri, Oct 16, 2015 at 1:38 PM, Yann Ylavic  wrote:
>
> Actually I tried some brute bash script (attached)

Really attached now...


http2_vs_openssl.sh
Description: Bourne shell script

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

On Fri, Oct 16, 2015 at 2:33 PM, Yann Ylavic  wrote:
> On Fri, Oct 16, 2015 at 1:38 PM, Yann Ylavic  wrote:
>>
>> Actually I tried some brute bash script (attached) to show what
>> remains compared to "openssl ciphers ALL", and the result is:
>>
>> * libressl/install/2.2.1/bin/openssl:
>> - ECDHE-ECDSA-CHACHA20-POLY1305
>> - ECDHE-RSA-CHACHA20-POLY1305
>> - DHE-RSA-CHACHA20-POLY1305
>> - ECDHE-RSA-AES256-GCM-SHA384
>> - ECDHE-ECDSA-AES256-GCM-SHA384
>> - DHE-DSS-AES256-GCM-SHA384
>> - DHE-RSA-AES256-GCM-SHA384
>> - GOST2012256-GOST89-GOST89
>> - GOST2001-GOST89-GOST89
>> - ECDHE-RSA-AES128-GCM-SHA256
>> - ECDHE-ECDSA-AES128-GCM-SHA256
>> - DHE-DSS-AES128-GCM-SHA256
>> - DHE-RSA-AES128-GCM-SHA256
>> - EDH-RSA-DES-CBC3-SHA
>> - EDH-DSS-DES-CBC3-SHA
>> - EDH-RSA-DES-CBC-SHA
>> - EDH-DSS-DES-CBC-SHA
>>
>> * openssl/install/1.0.2d/bin/openssl:
>> - ECDHE-RSA-AES256-GCM-SHA384
>> - ECDHE-ECDSA-AES256-GCM-SHA384
>> - DHE-DSS-AES256-GCM-SHA384
>> - DHE-RSA-AES256-GCM-SHA384
>> - ECDHE-RSA-AES128-GCM-SHA256
>> - ECDHE-ECDSA-AES128-GCM-SHA256
>> - DHE-DSS-AES128-GCM-SHA256
>> - DHE-RSA-AES128-GCM-SHA256
>> - EDH-RSA-DES-CBC3-SHA
>> - EDH-DSS-DES-CBC3-SHA
>> - EDH-RSA-DES-CBC-SHA
>> - EDH-DSS-DES-CBC-SHA
>> - EXP-EDH-RSA-DES-CBC-SHA
>> - EXP-EDH-DSS-DES-CBC-SHA
>>
>> So 'TLSv1.2:!kRSA:!aECDH:!DH' is a bit too restrictive
>
> Looks like 'ALL:!SSLv3:!kRSA:!ADH:!aECDH' matches pretty well
> (excluding for the undesirable ones above).

Actually there is a typo above (!ADH => !aDH), so the correct suite
would be: 'ALL:!SSLv3:!kRSA:!aDH:!aECDH'.
This assumes aNULL is added by default (which http does in its latest
versions, along with eNULL), otherwise the full openssl command would
be:

$ openssl ciphers -v 'ALL:!SSLv3:!kRSA:!aDH:!aECDH:!aNULL'

which gives,

* libressl/install/2.2.1/bin/openssl:
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=ChaCha20-Poly1305 Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
Enc=ChaCha20-Poly1305 Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH   Au=RSA
Enc=ChaCha20-Poly1305 Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH   Au=RSA
Enc=Camellia(256) Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH   Au=DSS
Enc=Camellia(256) Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH   Au=RSA
Enc=Camellia(128) Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH   Au=DSS
Enc=Camellia(128) Mac=SHA256

* openssl/install/1.0.2d/bin/openssl:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH   Au=DSS  

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

interesting that chrome is happily using h2 on my domain that I
activated for h2 earlier and I have a couple of banned ciphers in
mod_ssl.

On 16 October 2015 at 13:33, Yann Ylavic  wrote:
> On Fri, Oct 16, 2015 at 1:38 PM, Yann Ylavic  wrote:
>>
>> Actually I tried some brute bash script (attached) to show what
>> remains compared to "openssl ciphers ALL", and the result is:
>>
>> * libressl/install/2.2.1/bin/openssl:
>> - ECDHE-ECDSA-CHACHA20-POLY1305
>> - ECDHE-RSA-CHACHA20-POLY1305
>> - DHE-RSA-CHACHA20-POLY1305
>> - ECDHE-RSA-AES256-GCM-SHA384
>> - ECDHE-ECDSA-AES256-GCM-SHA384
>> - DHE-DSS-AES256-GCM-SHA384
>> - DHE-RSA-AES256-GCM-SHA384
>> - GOST2012256-GOST89-GOST89
>> - GOST2001-GOST89-GOST89
>> - ECDHE-RSA-AES128-GCM-SHA256
>> - ECDHE-ECDSA-AES128-GCM-SHA256
>> - DHE-DSS-AES128-GCM-SHA256
>> - DHE-RSA-AES128-GCM-SHA256
>> - EDH-RSA-DES-CBC3-SHA
>> - EDH-DSS-DES-CBC3-SHA
>> - EDH-RSA-DES-CBC-SHA
>> - EDH-DSS-DES-CBC-SHA
>>
>> * openssl/install/1.0.2d/bin/openssl:
>> - ECDHE-RSA-AES256-GCM-SHA384
>> - ECDHE-ECDSA-AES256-GCM-SHA384
>> - DHE-DSS-AES256-GCM-SHA384
>> - DHE-RSA-AES256-GCM-SHA384
>> - ECDHE-RSA-AES128-GCM-SHA256
>> - ECDHE-ECDSA-AES128-GCM-SHA256
>> - DHE-DSS-AES128-GCM-SHA256
>> - DHE-RSA-AES128-GCM-SHA256
>> - EDH-RSA-DES-CBC3-SHA
>> - EDH-DSS-DES-CBC3-SHA
>> - EDH-RSA-DES-CBC-SHA
>> - EDH-DSS-DES-CBC-SHA
>> - EXP-EDH-RSA-DES-CBC-SHA
>> - EXP-EDH-DSS-DES-CBC-SHA
>>
>> So 'TLSv1.2:!kRSA:!aECDH:!DH' is a bit too restrictive
>
> Looks like 'ALL:!SSLv3:!kRSA:!ADH:!aECDH' matches pretty well
> (excluding for the undesirable ones above).

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Eric Covener]

On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
> interesting that chrome is happily using h2 on my domain that I
> activated for h2 earlier and I have a couple of banned ciphers in
> mod_ssl.


unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

sslhonorcipherorder is definitely set.

I will check again to see if is in the unbanned ones.

On 16 October 2015 at 14:37, Eric Covener  wrote:
> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
>> interesting that chrome is happily using h2 on my domain that I
>> activated for h2 earlier and I have a couple of banned ciphers in
>> mod_ssl.
>
>
> unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

here is ciphers as listed by ssllabs scanning a site on the server.
(in the order set)

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH 256 bits (eq.
3072 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH 256 bits (eq.
3072 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH 256 bits (eq. 3072
bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH 256 bits (eq.
3072 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH 256 bits (eq.
3072 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH 256 bits (eq. 3072
bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH 256 bits (eq. 3072
bits RSA)   FS 112
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 2048 bits (p: 256, g: 1,
Ys: 256)   FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)

On 16 October 2015 at 14:37, Eric Covener  wrote:
> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
>> interesting that chrome is happily using h2 on my domain that I
>> activated for h2 earlier and I have a couple of banned ciphers in
>> mod_ssl.
>
>
> unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

here is my cipher list used in mod_ssl

SSLCipherSuite 
ECDHE-RSA-AES128-GCM-SHA256:ECDH+AES128:ECDHE-RSA-AES256-GCM-SHA384:ECDH+AES256:ECDH+3DES:CHACHA20+POLY1305:DHE-RSA-AES128-SHA:RSA+3DES:!aNULL:!MD5

note tho poly1305 doesnt work so ignore that one.

On 16 October 2015 at 14:37, Eric Covener  wrote:
> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
>> interesting that chrome is happily using h2 on my domain that I
>> activated for h2 earlier and I have a couple of banned ciphers in
>> mod_ssl.
>
>
> unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

Some of them are not banned, so I don't see why Chrome should complain.
Is the selected cipher a banned one?

On Fri, Oct 16, 2015 at 4:29 PM, Chris  wrote:
> here is my cipher list used in mod_ssl
>
> SSLCipherSuite 
> ECDHE-RSA-AES128-GCM-SHA256:ECDH+AES128:ECDHE-RSA-AES256-GCM-SHA384:ECDH+AES256:ECDH+3DES:CHACHA20+POLY1305:DHE-RSA-AES128-SHA:RSA+3DES:!aNULL:!MD5
>
> note tho poly1305 doesnt work so ignore that one.
>
> On 16 October 2015 at 14:37, Eric Covener  wrote:
>> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
>>> interesting that chrome is happily using h2 on my domain that I
>>> activated for h2 earlier and I have a couple of banned ciphers in
>>> mod_ssl.
>>
>>
>> unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Yann Ylavic]

Yes, the browser won't see the whole list, only the selected one.

On Fri, Oct 16, 2015 at 4:33 PM, Chris  wrote:
> ahh so only one needs to be unbanned for it to work?
>
> the selected cipher isnt banned no.
>
> On 16 October 2015 at 15:32, Yann Ylavic  wrote:
>> Some of them are not banned, so I don't see why Chrome should complain.
>> Is the selected cipher a banned one?
>>
>> On Fri, Oct 16, 2015 at 4:29 PM, Chris  wrote:
>>> here is my cipher list used in mod_ssl
>>>
>>> SSLCipherSuite 
>>> ECDHE-RSA-AES128-GCM-SHA256:ECDH+AES128:ECDHE-RSA-AES256-GCM-SHA384:ECDH+AES256:ECDH+3DES:CHACHA20+POLY1305:DHE-RSA-AES128-SHA:RSA+3DES:!aNULL:!MD5
>>>
>>> note tho poly1305 doesnt work so ignore that one.
>>>
>>> On 16 October 2015 at 14:37, Eric Covener  wrote:
 On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
> interesting that chrome is happily using h2 on my domain that I
> activated for h2 earlier and I have a couple of banned ciphers in
> mod_ssl.


 unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

ahh so only one needs to be unbanned for it to work?

the selected cipher isnt banned no.

On 16 October 2015 at 15:32, Yann Ylavic  wrote:
> Some of them are not banned, so I don't see why Chrome should complain.
> Is the selected cipher a banned one?
>
> On Fri, Oct 16, 2015 at 4:29 PM, Chris  wrote:
>> here is my cipher list used in mod_ssl
>>
>> SSLCipherSuite 
>> ECDHE-RSA-AES128-GCM-SHA256:ECDH+AES128:ECDHE-RSA-AES256-GCM-SHA384:ECDH+AES256:ECDH+3DES:CHACHA20+POLY1305:DHE-RSA-AES128-SHA:RSA+3DES:!aNULL:!MD5
>>
>> note tho poly1305 doesnt work so ignore that one.
>>
>> On 16 October 2015 at 14:37, Eric Covener  wrote:
>>> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
 interesting that chrome is happily using h2 on my domain that I
 activated for h2 earlier and I have a couple of banned ciphers in
 mod_ssl.
>>>
>>>
>>> unbanned ones listed earlier, or no SSLHonorCipherOrder?

Re: H2 compatible ciphers (was: svn commit: r1708593)

[Chris]

good to know thanks :)

Thats why I was told off for suggesting supporting ie8 and http2 at
the same time was not possible then :)

On 16 October 2015 at 15:35, Yann Ylavic  wrote:
> Yes, the browser won't see the whole list, only the selected one.
>
> On Fri, Oct 16, 2015 at 4:33 PM, Chris  wrote:
>> ahh so only one needs to be unbanned for it to work?
>>
>> the selected cipher isnt banned no.
>>
>> On 16 October 2015 at 15:32, Yann Ylavic  wrote:
>>> Some of them are not banned, so I don't see why Chrome should complain.
>>> Is the selected cipher a banned one?
>>>
>>> On Fri, Oct 16, 2015 at 4:29 PM, Chris  wrote:
 here is my cipher list used in mod_ssl

 SSLCipherSuite 
 ECDHE-RSA-AES128-GCM-SHA256:ECDH+AES128:ECDHE-RSA-AES256-GCM-SHA384:ECDH+AES256:ECDH+3DES:CHACHA20+POLY1305:DHE-RSA-AES128-SHA:RSA+3DES:!aNULL:!MD5

 note tho poly1305 doesnt work so ignore that one.

 On 16 October 2015 at 14:37, Eric Covener  wrote:
> On Fri, Oct 16, 2015 at 9:28 AM, Chris  wrote:
>> interesting that chrome is happily using h2 on my domain that I
>> activated for h2 earlier and I have a couple of banned ciphers in
>> mod_ssl.
>
>
> unbanned ones listed earlier, or no SSLHonorCipherOrder?