Subject: alpn + ciphers

From: Stefan Eissing <[email-masked]>
Date: Fri, 16 Oct 2015 13:28:27 +0200

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 16 Oct 2015 16:05:00 +0300

> 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

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 16 Oct 2015 15:23:44 +0200

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 <[email-masked]>:
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Oct 2015 12:31:18 -0700

The solution that NSS supports is similar to what we do for other
extensions that affect cipher suite selection.

For ECC the named_curves extension lists some curves.  If you don't
support any of the listed curves, you can't select an ECC-based cipher
suite (either ECDHE or ECDSA).  Thus, in the extension handler, the
stack checks for a good curve, and if it doesn't find one, it disables
all of the affected cipher suites.

Here, the callback can select a protocol as normal.  If it is h2, then
it can disable all the blacklisted ciphers.