- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 16 Oct 2015 15:23:44 +0200
- To: Ilari Liusvaara <ilariliusvaara@welho.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
It seems you say: "There is a way to configure this.", which I totally believe you.
But I am not setting up new servers. I add HTTP/2 functionality to a server that is around for 20 years. That upgrade will arrive in existing configurations and my code, ideally, should act sanely in as many of them as it can.
This seems a problem in implementation the way things are right now, because the requirements of RFC 7540 cannot be verified at ALPN time. Which maybe is what it is.
I am just trying to find out if I overlooked something here.
//Stefan
> Am 16.10.2015 um 15:05 schrieb Ilari Liusvaara <ilariliusvaara@welho.com>:
>
> On Fri, Oct 16, 2015 at 01:28:27PM +0200, Stefan Eissing wrote:
>>
>> During ALPN callbacks by popular SSL libs such as openssl, the cipher has/may not have been selected. This is a potential interworking problem when h2 is proposed, only to have the connection shutdown with INADEQUATE_SECURITY afterwards.
>>
>> I am not sure what is the best way to address this. Limiting the cipher list to only highest grade is often not an option for a server. Any advice appreciated.
>
> If you don't want to limit ciphers (but if you need to be PCI DSS
> compliant, you can limit it a lot, the only non-h2 ciphers you
> need is ECDHE-{RSA,ECDSA}-AES256-CBC (for Apple products).
>
> And you can also priorize the H2 ciphers over the rest, which
> should make the handshake go properly.
>
>
> -Ilari
>
Received on Friday, 16 October 2015 13:24:09 UTC