Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

[Simon Josefsson]

Timo Aaltonen <tjaalton at ubuntu.com> writes:

> On 09.03.2012 00:31, Simon Josefsson wrote:
>> Timo Aaltonen <tjaalton at ubuntu.com> writes:
>> 
>>> On 08.03.2012 20:06, Timo Aaltonen wrote:
>>>> which doesn't say much. I couldn't test 2.11.7 since snapshot.d.o
>>>> doesn't have packages for amd64 (FTBFS?), and bisecting without
>>>> packages is rather hard I guess... Can't test 3.0.x either, since
>>>> openldap doesn't build against libgnutls28.
>>>
>>> Ok I was able to build 2.11.7 after all (disabled tests), and I can
>>> confirm that it's a working version as well, so this broke some time
>>> between that and 2.12.0.. trying to bisect more.
>> 
>> Thanks.  What do you know about the server you are testing against?
>
> It's 389 Directory Server on Fedora.
>
>> Many LDAP servers seems to have non-standards conforming SSL support.
>> There is one change between 2.11.7 and 2.12.0 ("Corrected default
>> behavior in record version of Client Hellos.") that I suspect.  Try
>> adding the "SSL3_RECORD_VERSION" or "LATEST_RECORD_VERSION" priority
>> string to your client and see if it makes a difference.  If this makes a
>> difference, the problem is with the server.
>
> 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.

/Simon