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: http2 tests

[Kaspar Brand]

On 14.10.2015 14:55, Eric Covener wrote:
> On Wed, Oct 14, 2015 at 8:37 AM, Stefan Eissing
>  wrote:
>> Any advice on how to add a test host (e.g. real port) to our test suite in 
>> the most compatible way?
> 
> 1426878 added an SSL vhost. It seems like there is a magic port
> assignment the config-generator and client share info about .

Not sure if I'm too late with this, but just add something like the
below - this will add the required Listen and VirtualHost directives to
the generated config files (with an auto-assigned port number).

Kaspar

--- t/conf/ssl/ssl.conf.in  (revision 1709127)
+++ t/conf/ssl/ssl.conf.in  (working copy)
@@ -252,4 +252,10 @@
  SSLCipherSuite AES256-SHA
 

+
+SSLEngine On
+
+# ...
+
+
 

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: http2 tests

[Stefan Eissing]

Thanks! Yes, I have sth like this in the works in order to test more specific 
http2 edge cases. You'll probably see it sometime next week. 

> Am 17.10.2015 um 10:58 schrieb Kaspar Brand :
> 
>> On 14.10.2015 14:55, Eric Covener wrote:
>> On Wed, Oct 14, 2015 at 8:37 AM, Stefan Eissing
>>  wrote:
>>> Any advice on how to add a test host (e.g. real port) to our test suite in 
>>> the most compatible way?
>> 
>> 1426878 added an SSL vhost. It seems like there is a magic port
>> assignment the config-generator and client share info about .
> 
> Not sure if I'm too late with this, but just add something like the
> below - this will add the required Listen and VirtualHost directives to
> the generated config files (with an auto-assigned port number).
> 
> Kaspar
> 
> --- t/conf/ssl/ssl.conf.in  (revision 1709127)
> +++ t/conf/ssl/ssl.conf.in  (working copy)
> @@ -252,4 +252,10 @@
>  SSLCipherSuite AES256-SHA
> 
> 
> +
> +SSLEngine On
> +
> +# ...
> +
> +
> 
> 
> 

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
>