alpn + ciphers

Stefan Eissing <stefan.eissing@greenbytes.de> Fri, 16 October 2015 11:31 UTC

Resent-Date: Fri, 16 Oct 2015 11:29:01 +0000
Resent-Message-Id: <E1Zn3C1-0005sf-Hk@frink.w3.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <78A44AE4-168D-4129-AF94-38FB66286711@greenbytes.de>
Date: Fri, 16 Oct 2015 13:28:27 +0200
To: HTTP Working Group <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Received-SPF: pass client-ip=217.91.35.233; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
Subject: alpn + ciphers
Archived-At: <http://www.w3.org/mid/78A44AE4-168D-4129-AF94-38FB66286711@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

A question regarding interworking and ALPN + ciphers:

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 certain if this is depending on the order TLS extensions appear in the client hello or the particular openssl implementation. Potentially, I could try to change the cipher list during the ALPN callback, but if that will influence things, is probably also not well defined. This you get, when you mix layers, I assume.

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.

//Stefan

alpn + ciphers Stefan Eissing
Re: alpn + ciphers Ilari Liusvaara
Re: alpn + ciphers Stefan Eissing
Re: alpn + ciphers Martin Thomson