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

[Ilari Liusvaara <[e-mail]>]

On Thu, Sep 18, 2014 at 06:20:21PM +0200, Simone Bordet wrote:
> Hi,
> 
> >
> > The scenario as I understand it is:
> > 1] some new XYZ is in fact h2 appropriate by 9.2.2,
> > 2] a client handshake offers both XYZ and GCM along with h2 and h1
> > 3] the server selects XYZ+h2 (which meet the requirements of h2 - good job)
> > 4] The client's h2 stack, expecting GCM, is not aware that XYZ satisfies
> > 9.2.2 so it generates an h2 INADEQUATE_SECURITY
> >
> > I would say that's an implementation bug in the client.

Also, can happen the other way:

1) Client prefers XYZ (9.2.2 compliant, and client knows that) over GCM.
2) Client offers both ciphers (with XYZ first) and both h2 and h1.
3) Someone has added XYZ to server TLS stack, and it picks first one it
   supports (XYZ), or server even prefers XYZ.
4) There is version skew and server h2 stack doesn't probe TLS stack,
   so server h2 stack doesn't know about XYZ -> generates
   INADEQUATE_SECURITY.


> Any client that dynamically links the TLS implementation is subject to
> this scenario, and certainly it's not an implementation bug in the
> client if a deployer chooses to link that client to a newer TLS
> library, no ?

Furthermore, if using some general-purpose TLS stack, like GnuTLS,
OpenSSL, LibReSSL, PolarSSL and couple others, such dynamic linking
is best practice.


I have seen version skew disabling features with both app and library
from autoupdate. And also distributors patching applications and
libraries for dynamic linking.



-Ilari