Subject: h2 ciphers

From: Stefan Eissing <[email-masked]>
Date: Fri, 16 Oct 2015 12:35:51 +0200

In the documentation at https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility the "modern" compatibility specification includes the following ciphers:

ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA256

ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA384

DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA256

but RFC 7540 includes TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ECDHE-RSA-AES128-SHA) and all those others as a MAY for INADEQUATE_SECURITY.

Now, assuming I got the cipher names correct, what am I to check for? Shall I be liberal in what I accept - again?

//Stefan

---

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

> Now, assuming I got the cipher names correct, what am I to check for? Shall I be liberal in what I accept - again?

AFAIK, that list is for HTTP/1.1. HTTP/2 has list of ciphers that
are not to be used.

And it is also unnecressarily wide. Just about everything that supports
"modern" in sense Mozilla TLS guide uses it supports:

- TLS 1.2
- ECDHE
- RSA and ECDSA
- At least one of AES-128-GCM, AES-256-GCM, AES-256-CBC.

(The AES-256-CBC cipher is for Apple products, as those only recently
gained GCM support).

Priorize AEAD ciphers over AES-256-CBC and ciphersuite selection for
h2 should go properly.

-Ilari

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 17 Oct 2015 02:08:17 +1300

> Now, assuming I got the cipher names correct, what am I to check for? Shall I be liberal in what I accept - again?

The RFC is the specification. If a browser does not follow it that is a
bug in their implementation (or maybe just their documentation), do not
make matters worse by adding a bug to your code.

HTTP/2 was designed to be implemented from a clean-slate situation.
Everybody is building new code based on the same spec, so there is no
legacy behaviours to be tolerant about. Methods of extending the
protocol are also explicitly defined and explicitly negotiated when used
to make feature support (or lack of it) a defined state within the
protool itself.

Amos

---

From: Julien Vehent <[email-masked]>
Date: Fri, 16 Oct 2015 09:23:57 -0400

On 2015-10-16 09:08, Amos Jeffries wrote:
> legacy behaviours to be tolerant about.

(I'm the author of the Mozilla guidelines).

This is correct: the recommendation is for HTTP/1.1 where a significant 
amount of backward compatibility is required. The modern guidelines 
guarantee strong crypto on somewhat recent clients, but we can certainly 
do better for http/2.

We'll probably revise the guidelines in the coming months. In the 
meantime, on a h2 endpoint, I would recommend limiting it to these 
ciphers:

$ openssl ciphers -V 
'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384'
0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    
Enc=AESGCM(128)  Mac=AEAD
0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  
Enc=AESGCM(128)  Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    
Enc=AESGCM(256)  Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  
Enc=AESGCM(256)  Mac=AEAD

Note: we don't recommend ECDHE-RSA-CHACHA20-POLY1305 because it's not 
yet a standard and our mozilla servers don't implement it, but feel free 
to use it :)

- Julien

---

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

> Am 16.10.2015 um 15:08 schrieb Amos Jeffries <[email-masked]>:
> 
>> [...]

> make matters worse by adding a bug to your code.

I do not want to, but see my other mail about ALPN+cipher timing that seems to make this difficult.

> HTTP/2 was designed to be implemented from a clean-slate situation.

Insert "on the client side", please.

> protocol itself.

The problem seems to be that during ALPN selection, the TLS connection is not in a defined state. I seem to be unable to verify all requirements before code gives an answer to the selected protocol. And that might have nothing to do with the specification but with the TLS APIs. And there certainly is no clean slate there.

If this cannot be solved in code, we can only address this in configuration documentation. Which sucks.

//Stefan

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 16 Oct 2015 16:04:52 +0200

> Am 16.10.2015 um 15:23 schrieb Julien Vehent <[email-masked]>:
> 

Thanks for that wiki!

> This is correct: the recommendation is for HTTP/1.1 where a significant amount of backward compatibility is required. The modern guidelines guarantee strong crypto on somewhat recent clients, but we can certainly do better for http/2.
> 
> We'll probably revise the guidelines in the coming months. In the meantime, on a h2 endpoint, I would recommend limiting it to these ciphers:
> 
> $ openssl ciphers -V 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384'
> 0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
> 0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
> 0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
> 0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
> 
> Note: we don't recommend ECDHE-RSA-CHACHA20-POLY1305 because it's not yet a standard and our mozilla servers don't implement it, but feel free to use it :)

Now, Apache httpd will most often not be a "clean slate" h2 endpoint, but having to serve old, intermediate and modern clients and, among those modern ones, some that announce 'h2' in ALPN. 

When this arrives in Apache, the code needs to decide if it answers h2 or http/1.1 in an ALPN callback from the TLS layer
- the TLS layer has not yet decided on a cipher
- the TLS layer has no concept of a h2 compatible cipher list, best case it is configured with a "modern" list and server-order preference.
- the client cipher list is, I believe, not visible (and even if it was, we could only guess what the TLS layer selects later)

*crickets*

Am I overlooking something?

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 17 Oct 2015 03:45:57 +1300

On 17/10/2015 2:36 a.m., Stefan Eissing wrote:
> 
>> Am 16.10.2015 um 15:08 schrieb Amos Jeffries:
>>

For us on the server side too. HTTP/2 syntax and behaviour simply did
not exist a few years ago.

If you have a legacy client, fall back to 1.1  - *as 1.1*. Not as h2
with 0.9 / 1.x syntax and security hacks.

It is actually easier for us as servers to do this failover quietly
since we get told up front by the client whether it wants h2 or only
talks 1.x.

> The problem seems to be that during ALPN selection, the TLS connection is not in a defined state. I seem to be unable to verify all requirements before code gives an answer to the selected protocol…

Good argument for not accepting h2 in the ALPN unless TLS/1.3 is being
negotiated. That was the ideal for the TLS situation anyway.

Illari already pointed out how to do the ordering so that h2 is
achievable within the TLS/1.2 restrictions.

The result is either h2 being used, or failover to 1.1. Any penalty paid
is on the less preferred protocol. Which just encourages its decline in
a polite and increasingly less painful way.

Amos