- From: Francisco Moraes <francisco.moraes@gmail.com>
- Date: Wed, 4 Nov 2015 09:18:16 -0500
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Patrick, On 11/3/2015 7:29 PM, Patrick McManus wrote: > The server makes the final choice of both application layer protocol > and tls version (subject to intersection with what the client offers). > If it cannot select >= 1.2 then it must not select h2. Doing so would > be a 7540 violation and some clients are likely to generate > INADEQUATE_SECURITY. (Firefox will.) Falling back to h1 would be fine > assuming some version of tls is negotiated. But during the ALPN callback, as far as I can tell, OpenSSL still has not selected a cipher nor protocol, so I cannot choose to ignore the upgrade request to h2, unless I missed something. I would have to accept the request and then after the initial handshake, tear it down with INADEQUATE_SECURITY if either a bad cipher was selected or a lower version of TLS was selected. > Restricting the cipher list to the set of best practices is definitely > the point. If you have a h2 only server then you can just disable them > - just making them lowest priority generally does the trick in a > server that needs backwards compat with older h1 clients. > Yes, I will make a check to at least make sure some cipher that's acceptable to h2 is available, otherwise I will flag it is a configuration error. At runtime, I will have to actually check which cipher was selected. Francisco
Received on Wednesday, 4 November 2015 14:18:47 UTC