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

On 6 September 2014 01:03, Patrick McManus <mcmanus@ducksong.com> wrote:

>
> On Thu, Sep 4, 2014 at 9:05 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>>
>> 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.
>>
>
> right. h2-14 requires aead and the server selected h2 via alpn without
> also using aead - so that's a h2 level protocol error on the server's part
> and that connection can't proceed.
>

Agreed.  The FF client is following 9.2.2 correctly here.
The problem I have is that OpenJDK is following RFC5246 correctly and
Jetty's ALPN is following RFC7301 correctly - yet we ended up with no
communication.

I don't think it is acceptable for specifications to aggregate
unsuccessfully like that.   Sure I can try to influence the development of
ALPN in the JVM to support selection of cipher and protocol rather than
just protocol - but that is not captured by an RFC.

The expected thing would have been for the server not to select h2.
>

So 9.2.2 is not discouraging the use of old ciphers.   It is discouraging
the use of h2!



> The question of what to do next in the client is tricky and fun to talk
> about, but I think the standard does the right thing by steering clear of
> it. As you note, firefox right now declares game over - hard fail. No doubt
> the error page for it is in dire need of improvement :)
>
>
There is no error screen.  It leaves the page exactly as it was with the
previous contents.  Most confusing, but I'll hold you to account for that
once Jetty's own h2 failures are elegant and well logged.

I'm not sure we should go for any retries because the information is there
in the original handshake to establish communication, either h1 or h2,
using less desirable cipher.



> The other part of that is just design experience that favors being
> intolerant of errors - especially at early stages. These workarounds tend
> to get added over time for bugwards compatibility,, but at this stage we
> shouldn't feel that kind of pressure - its much more important to build an
> ecosystem where things operate correctly when its full of those kinds of
> written and unwritten rules. A lot of folks believe we're in an era where
> "be liberal in what you receive" is no longer in the best interest of the
> Internet.
>
> I'm happy to be intolerant of insecure ciphers.  If they are no good,
let's just make them unacceptable.  Let's not discourage the use of h2.

If we are not being liberal, then why are we letting client and server talk
over a poor cipher just because they are using a 20 year old protocol that
had  less consideration in its design to things like header injection etc.



> I do agree this is tricky to get right (but worthwhile!). We had a bug
> where we would occasionally send a TLS 1.0 client hello (due to some tls
> intolerance logic) with h2 in the offer list. If h2 was selected, we
> generated an error. We shouldn't do that - they aren't compatible.
>

Indeed.   But it is hard enough to explain cipher issues to users anyway,
so involving the protocol is going to make it harder for them to understand
and upgrade to new ciphers.      I would think we just need the end points
to exclude bad ciphers, warn for poor ciphers and prefer good ciphers
regardless of protocol.      Adding protocol to the mix is just mixing
orthogonal concerns

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.