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

On 18 September 2014 14:53, Stuart Douglas <stuart.w.douglas@gmail.com>
wrote:

> I have been looking through the archives and I can't seem to find the
> discussion about how this requirement came about, and I am really
> struggling to understand why it is necessary.
>
> I can't really see how it provides any increased security, given that if a
> cypher that meets these requirements is not available the client is
> expected to fallback to HTTP/1.1 and communicate over the supposedly less
> secure cypher anyway



Stuart,

Martin hinted at the motivation earlier in this thread:

On 6 September 2014 15:03, Martin Thomson <martin.thomson@gmail.com> wrote:

> If clients don't send the "bad" ciphers, then large swathes of the web
> stop working.  No browser wants to do that because that's a trigger
> for a mass exodus of users.  So we end up stuck with ciphers that are
> sort-of-bad-but-not-broken-enough-to-pull.  Which sucks.
>

So he is saying that because browser vendor value market share more than
their users security it is apparently our job to withhold the h2 protocol
or just fail to connect in an  effort to push them towards being good web
citizens.

I don't actually agree with the premise that browser vendors are that
morally corrupt.  I think they have a difficult line to walk between
offering reasonable security and wide spread connectivity.       If they
are offering old ciphers then I am sure that there are significant origin
resources that can only be accessed with them.

But let's accept the premise that browser vendors are indeed morally
corrupt and will deploy insecure ciphers rather than lose market share.
Let's also assume that origin server deployers are also prepared to accept
those bad ciphers and make their content available over them...  I have
absolutely no idea how allowing those two to tango over http/1 rather than
h2 pushes them to any better security practises.   Perhaps the failing
abysmally to connect part might be a bit more persuasive, but I expect that
is more likely to make them remove the good ciphers.

If failure to connect is a driver to better cipher policy, then  we need
not hobble h2 to achieve that.  Instead the browser vendors and server
deployers can simply grow a pair and remove the bad ciphers.

regards



>
>
> Martin Thomson wrote:
>
>> On 17 September 2014 17:09, Greg Wilkins<gregw@intalio.com>  wrote:
>>
>>> Consider clients and servers written in java, so they inherit their
>>> ciphers
>>> from the JVM. At some stage in the future a GCM is replaced by XYZ and
>>> added
>>> to the JVM, so it is part of the acceptable TLS ciphers, but the h2
>>> clients
>>> and servers implementations have adopted your advice to "By default,
>>> assume
>>> that a cipher suite is not acceptable".   So everybody is assuming that
>>> XYZ
>>> is not h2 acceptable.
>>>
>>
>> You can't suddenly pull a cipher suite that people rely on.  We rely
>> on GCM.  We require that implementations support it.
>>
>> Yes, there will be implementations that pick up XYZ, but also don't
>> know that it's OK.  That's expected behaviour sadly.  Not all
>> implementations will be able to examine the properties of the
>> available cipher suites and use properties to determine if they are OK
>> to use.
>>
>>  This is not a theoretical problem.
>>>
>>
>> I disagree, it's a hypothetical problem.
>>
>>  It is a real problem that I have
>>> experienced as FF rolled out their AEAD restriction as rqeuired by 9.2.2
>>> before jetty had implemented the same restriction and while AEAD is not
>>> available on java-7.  I could implement the AEAD restriction in jetty
>>> now to
>>> get connectivity with FF, but would lose connectivity with h2 clients
>>> running java-7.
>>>
>>
>> I'm not sure that this is quite right.  Unless the Java 7 code is
>> singificantly different to the Java 8 code, you should have been able
>> to influence suite selection so that a good suite (i.e., an acceptable
>> one) was chosen.
>>
>>


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