Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

[Timo Aaltonen]

On 09.03.2012 02:10, Simon Josefsson wrote:
> Timo Aaltonen <tjaalton at ubuntu.com> writes:
> 
>> On 09.03.2012 00:31, Simon Josefsson wrote:
>>> Timo Aaltonen <tjaalton at ubuntu.com> writes:
>> Spot on, that commit changed it. What exactly is broken on the server?
>> Upstream would like to know :)
> 
> If I recall and understand correctly: before, GnuTLS clients sent the
> latest TLS version it supported in the record layer version of the
> client hello.  This caused some problems with SSL3-only servers.  But
> after 2.12.0 it sent the SSL3 record version even when it supports
> higher versions.  This allows SSL3-only-and-TLS-intolerant servers to
> talk to GnuTLS but still allow TLS-conforming servers to upgrade to more
> recent TLS versions.  Sadly, it seems the server you hit rejects GnuTLS
> here, probably because it is confused by seeing a SSL3 record version
> when there is support for higher TLS versions.  This is more uncommon
> than SSL3-only-and-TLS-intolerant servers, that's why the default was
> changed.
> 
> This came up a long time ago and was discussed then, and I may be
> recalling things incorrectly.  RFC 5246 discuss this:
> 
>    Earlier versions of the TLS specification were not fully clear on
>    what the record layer version number (TLSPlaintext.version) should
>    contain when sending ClientHello (i.e., before it is known which
>    version of the protocol will be employed).  Thus, TLS servers
>    compliant with this specification MUST accept any value {03,XX} as
>    the record layer version number for ClientHello.
> 
>    TLS clients that wish to negotiate with older servers MAY send any
>    value {03,XX} as the record layer version number.  Typical values
>    would be {03,00}, the lowest version number supported by the client,
>    and the value of ClientHello.client_version.  No single value will
>    guarantee interoperability with all old servers, but this is a
>    complex topic beyond the scope of this document.

Excellent, thanks! Apparently this is a flaw in NSS, which 389 builds
against.. might just reassign this to that package.

In the meantime, forcing the ldap server to support SSL3 makes the
ipac-client-install work.


-- 
t