On 6 November 2014 16:26, Jason Greene <jason.greene@redhat.com> wrote: > > > Hi Greg, can you take a look at the small proposal I sent a few days ago. I think its closer to what you are looking for: > https://github.com/http2/http2-spec/pull/639/files Jason, your proposal says: + latency imposed by using a separate connection for fallback. Prohibited cipher suites + MUST be advertised at a lower preference than permitted cipher suites. I don't think ordering helps as there may be no ciphers in intersection of client/server h2 acceptable cipher sets (as was the case when I ran jetty on java 7). Without a robust handshake, it is impossible for a server to know at what point in the list of offered ciphers the weak fallback ciphers begin. Many servers will never even see the list and will just see the negotiated cipher. + </t> + <t> + Servers MAY allow unknown ciphers that are negotiated by a TLS 1.2 implementation. + This prevents potential interoperability issues involving future ciphers supported + by the underlying TLS 1.2 implementation, but are not yet understood by the server. + Due to the restrictions on clients above, prohibited cipher suites are still + prevented from use with HTTP/2. If the server allows an unknown cipher for h2, and the client rejects it with inadequate security, then the connection will have failed - EVEN if there are acceptable ciphers if h1 was chosen. Also note that a server might not get to choose h1 over h2 as the ALPN may be offloaded with TLS. So the fundamental problem is that the current handshake even with your amendments allows a client to offer a cipher which it later rejects with inadequate security. That is a broken handshake. cheers -- Greg Wilkins <gregw@intalio.com> @ Webtide - an Intalio subsidiary http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Thursday, 6 November 2014 07:53:11 UTC