Re: http/2 and TLS security

> On 3 Nov 2015, at 14:59, Francisco Moraes <francisco.moraes@gmail.com> wrote:
> 
> Hi,

Hi!

> I have a few questions from a server perspective when implementing http/2:
> 
> 1. if http/2 is selected to be supported, TLS 1.2 is required, but that doesn't mean that the server cannot negotiate TLS 1.x with clients that are not talking h2. It would be a client error to negotiate TLS 1.1 for example if it wants to talk h2. Should the server close the connection is for some reason TLS 1.1 or 1.0 was negotiated for http/2?

RFC 7540, section 9.2 says that "implementations MUST use TLS version 1.2 or higher for HTTP/2 over TLS". Thus, if you negotiate HTTP/2 over TLS but negotiate a TLS version lower than 1.2, you should tear the connection down. The graceful thing to do is to send a GOAWAY frame with the error code INADEQUATE_SECURITY.

> 2. Appendix A of RFC 7540 lists a lot of ciphers that are black listed but the wording says the server MAY treat the negotiation of the ciphers with TLS 1.2 as a connection error. This doesn't imply that I should disallow those ciphers in my server configuration, but I have seen some of those ciphers cause an error on the client side (browser). What's the best practice here? Print a warning if those ciphers are used? Fail? Failing every single one of those ciphers leaves a very limited list of ciphers to be used.

Again, it should be conditional on what is negotiated. For HTTP/1.1 those ciphers are allowed. For HTTP/2, they are technically forbidden. If you find that you’ve negotiated one of those ciphers, you should probably tear the connection down (again, using GOAWAY with INADEQUATE_SECURITY). You are free to continue to use them if you so choose, but it’s a bad idea: section 9.2.2 says that you MAY choose to generate that error, and again, many implementations do.

As to the limited list of ciphers: yes, that’s the goal. Generally speaking, AEAD ciphers are the strongest security available today. In TLS 1.2 there is only one standard cipher suite that offers AEAD: AES in GCM mode. It is also potentially possible to negotiate CHACHA20-POLY1305, which is also an AEAD cipher, but if you’re dependent on OpenSSL it’s not available to you yet.

Anything else is potentially at risk. All modern web browsers support AES_GCM, so if you can you should restrict yourself to AES_GCM. If you still need to support legacy browsers (and I urge you to strongly consider whether you actually do!), then you should respect your own cipher preference first and put AES_GCM at the top of your cipher list. That way, if you negotiate HTTP/2 you’ll *probably* negotiate AES_GCM, and you know that if you failed to it was because the client outright does not support that cipher suite (and so is not RFC 7540 compliant).

For my part, my example web servers for Hyper-H2 use the following OpenSSL cipher string: “ECDHE+AESGCM”. Simple, and effective.

Cory