Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

I've dug into this particular problem some more.

For the ALPN extension that we have done for OpenJDK 7, at the time we are
called back to select the protocol to use, the SslSession reports a cipher
of SSL_NULL_WITH_NULL_NULL.     Thus I don't have the information available
to exclude h2-14 from the protocol list on the basis of negotiated
cipher.   I then tried setting the acceptable cipher suites on the session
at that same point in the code, but unfortunately the OpenJDK library had
already picked the cipher (and just not told the session about it), so the
excluded cipher was used anyway.

So before we go hacking into the JDK code to see what we can change, it
would be good to know if we are meant to make the selected protocol a
function of the selected cipher, or if the selected cipher should be a
function of the selected protocol?

Reading RFC7301,  it makes no association between ciphers selection and
protocol selection.  But it does say :

   The ALPN extension does not impact the security of TLS session
   establishment or application data exchange.

Which kind of suggests that we should be selecting protocols as a function
of the cipher.  However I note that in a full handshake it looks like the
client selects the cipher, so it is unknown to the server until the next
round trip.   So maybe the server will have to advertise different lists of
available ciphers depending on the protocol selected.

So at the very least, we have a short term interoperability while we hack
our ALPN implementations to support some association between protocol and
cipher selection.     But somebody with more TLS smarts than me will have
to confirm if this is possible under RFC7301 or if we need to enhance ALPN
to support this kind of logic in a well defined manner.

Which brings me back to the question of why are we doing this again?   I
fully understand that there are unacceptable ciphers out there and we
should recommend that servers be updated and maintained with all the latest
knowledge to offer a secure set of ciphers.  But why is this set of
acceptable ciphers a function of protocol used (or vice versa)?     If a
cipher is unacceptable to carry HTTP/2 traffic, then why will falling back
to HTTP/1 be acceptable?   Can't we just recommend against poor ciphers but
still function if they are the only ciphers on offer?

regards










On 5 September 2014 11:05, Greg Wilkins <gregw@intalio.com> wrote:

>
> Section 9.2.2 puts some requirements on TLS ciphers and I'm just wondering
> how the fallback is meant to work.
>
> I'm testing a recent build of FF with latest jetty server.
>
> The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which
> would be acceptable if the protocol was https, but because it is h2,  FF
> fails the connection due to lack of AEAD.     This results in a connection
> failure on the client, when it would have worked fine if http/1.1 was
> accepted as the protocol instead.
>
> So I'm just trying to get my head around how the fallback is meant to
> happen?
>
> Is it that in the ALPN accept of the connection, the server needs to
> evaluate the offered protocols against the available ciphers and ignore the
> protocols that don't have acceptable ciphers?     So in this case, our ALPN
> code should have known that accepting h2-14 was not going to succeed
> because the cipher was not acceptable (or there is not acceptable cipher...
> I can't recall if the cipher is determined at that stage or not)?
> Alternately, are we meant to modify the TLS cipher negotiation to notice if
> ALPN h2 is being offered and thus not select an unacceptable cipher?
>
> If the server does select an unacceptable cipher,  should the client just
> fail? or should it retry either without h2 offered  or without unacceptable
> ciphers?   I think it is unacceptable that FF and Jetty were unable to
> communicate in this situation even though they had acceptable ciphers and
> protocols in common.   One or the other or both needs better fallback and I
> don't think section 9.2.2 gives enough guidance as to how that should be
> done.
>
> Also I'm a little bit concerned that many implementations might not have
> sufficient control over their TLS layers to fully implement some
> combinations.
>
> Finally, it would be really good to know why http2 puts restrictions on
> TLS above and beyond https?   Can that be described somewhere and has that
> been checked so that it is future proof?
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.