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

On Thu, Sep 4, 2014 at 7:12 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> 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.
>

In TLS, server selects both the ALPN protocol and the cipher suite. I'm not
sure
what lead you to believe that the client selected the cipher suite, but
that's not
correct and if you can point me to the section in the TLS spec that made you
think that, I'll try to fix it.

This is a distinct question from what RFC 7301 says, just a technical
statement
about what servers can and can't do. With that said, I read the statement
you
quote above (from the security considerations section) as saying that this
doesn't make the handshake less secure. I don't think it's inconsistent
with 7301
to condition cipher suites on the ALPN negotatiation.

-Ekr





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.
>