Debian Bug report logs - #663127
gnutls26: Regression between 2.11.6 and 2.12.0

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Thu, 08 Mar 2012 20:06:17 +0200

Package: gnutls26
Version: 2.12.0 and newer
Severity: important

Hi!

I'm packaging FreeIPA for Debian, and noticed that the client install fails if the libgnutls26 version is newer than 2.11.6. The error message is:

--
root        : DEBUG    Init ldap with: ldap://f16.test:389
root        : ERROR    LDAP Error: Connect error: A TLS packet with unexpected length was received.
--

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.

I hope you have ideas what broke it.. 

t

Message #10 received at 663127@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: 663127@bugs.debian.org

Subject: Re: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Fri, 09 Mar 2012 00:13:11 +0200

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.

-- 
t

Message #15 received at 663127@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Timo Aaltonen <tjaalton@ubuntu.com>

Cc: 663127@bugs.debian.org

Subject: Re: Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Thu, 08 Mar 2012 23:31:51 +0100

Timo Aaltonen <tjaalton@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?
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.

/Simon

Message #20 received at 663127@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: Simon Josefsson <simon@josefsson.org>

Cc: 663127@bugs.debian.org

Subject: Re: Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Fri, 09 Mar 2012 01:47:38 +0200

On 09.03.2012 00:31, Simon Josefsson wrote:
> Timo Aaltonen <tjaalton@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 :)


-- 
t

Message #25 received at 663127@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Timo Aaltonen <tjaalton@ubuntu.com>

Cc: 663127@bugs.debian.org

Subject: Re: Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Fri, 09 Mar 2012 01:10:30 +0100

Timo Aaltonen <tjaalton@ubuntu.com> writes:

> On 09.03.2012 00:31, Simon Josefsson wrote:
>> Timo Aaltonen <tjaalton@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

Message #30 received at 663127@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: Simon Josefsson <simon@josefsson.org>

Cc: 663127@bugs.debian.org

Subject: Re: Bug#663127: gnutls26: Regression between 2.11.6 and 2.12.0

Date: Fri, 09 Mar 2012 02:47:47 +0200

On 09.03.2012 02:10, Simon Josefsson wrote:
> Timo Aaltonen <tjaalton@ubuntu.com> writes:
> 
>> On 09.03.2012 00:31, Simon Josefsson wrote:
>>> Timo Aaltonen <tjaalton@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

Message #35 received at 663127-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 447778-done@bugs.debian.org,464625-done@bugs.debian.org,476441-done@bugs.debian.org,481132-done@bugs.debian.org,492606-done@bugs.debian.org,525962-done@bugs.debian.org,532752-done@bugs.debian.org,557450-done@bugs.debian.org,560690-done@bugs.debian.org,573736-done@bugs.debian.org,588302-done@bugs.debian.org,607616-done@bugs.debian.org,610806-done@bugs.debian.org,620749-done@bugs.debian.org,637444-done@bugs.debian.org,663127-done@bugs.debian.org,683095-done@bugs.debian.org,707327-done@bugs.debian.org,708174-done@bugs.debian.org,710657-done@bugs.debian.org,728731-done@bugs.debian.org,731175-done@bugs.debian.org,737921-done@bugs.debian.org,747200-done@bugs.debian.org,760735-done@bugs.debian.org,768014-done@bugs.debian.org,

Cc: gnutls26@packages.debian.org, gnutls26@packages.qa.debian.org

Subject: Bug#767610: Removed package(s) from unstable

Date: Fri, 02 Jan 2015 12:40:16 +0000

Version: 2.12.23-17+rm

Dear submitter,

as the package gnutls26 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/767610

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.