From nmav at gnutls.org  Sat May  5 19:33:51 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 05 May 2012 19:33:51 +0200
Subject: gnutls 2.12.19
Message-ID: <4FA5647F.6000405@gnutls.org>

Hello,
 I've just released gnutls 2.12.19. It includes several
bug fixes.

Version 2.12.19 (released 2012-05-05)

** libgnutls: When decoding a PKCS #11 URL the pin-source field
is assumed to be a file that stores the pin. Based on patch
by David Smith.

** libgnutls: Added strict tests in Diffie-Hellman and
SRP key exchange public keys.

** minitasn1: Upgraded to libtasn1 version 2.13 (pre-release).

** API and ABI modifications:
No changes since last version.



Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From dkg at fifthhorseman.net  Mon May  7 02:31:21 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 06 May 2012 20:31:21 -0400
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA3B6DD.1070503@suse.de>
References: <4FA3B6DD.1070503@suse.de>
Message-ID: <4FA717D9.2000104@fifthhorseman.net>

Hi GnuTLS folks--

The attached message came through oss-security recently [0], and i just
wanted to bring it to the attention of the users and developers of GnuTLS.

In particular, i wanted to take Ludwig's concern seriously here:

> Openssl in all it's
> ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
> doesn't have an equivalent. It's utterly stupid to require each and
> every application to hard code the path to a certificate bundle.
> Defaulting to not doing any checks at all if the application programmer
> forgot to set the magic option isn't exactly clever either.

Is there a way that GnuTLS can help facilitate proper peer verification
by application (or library) developers who depend on the project?

As a baseline, are there documentation improvements we could offer, or
best practice guidelines we should be encouraging?  More aggressively,
is there some way we could consider offering a simple best-practice
certification config in the priority string, or as default behavior if
no other verification mechanism is specified?

Any thoughts?  Is there already a helpful and useful response that we
can offer to Ludwig's complaint?

All the best,

	--dkg

[0] http://www.openwall.com/lists/oss-security/2012/05/04/6
-------------- next part --------------
An embedded message was scrubbed...
From: Ludwig Nussel <ludwig.nussel at suse.de>
Subject: Re: [oss-security] CVE Request: evolution-data-server lacks SSL checking
 in its libsoup users
Date: Fri, 04 May 2012 13:00:45 +0200
Size: 4133
URL: </pipermail/attachments/20120506/f4887f1d/attachment.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120506/f4887f1d/attachment.pgp>

From nmav at gnutls.org  Mon May  7 07:25:45 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 May 2012 07:25:45 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA717D9.2000104@fifthhorseman.net>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
Message-ID: <4FA75CD9.6090904@gnutls.org>

On 05/07/2012 02:31 AM, Daniel Kahn Gillmor wrote:

> In particular, i wanted to take Ludwig's concern seriously here:
>> Openssl in all it's
>> ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
>> doesn't have an equivalent. It's utterly stupid to require each and
>> every application to hard code the path to a certificate bundle.
>> Defaulting to not doing any checks at all if the application programmer
>> forgot to set the magic option isn't exactly clever either.
> Is there a way that GnuTLS can help facilitate proper peer verification
> by application (or library) developers who depend on the project?


It is a nice point. Ludwig contacted us with a patch lately. I'm for
such a patch, but there is no notion such as a system certificate
bundle standardized (even for linux systems only), and openssl only
points to a random CA list they ship. I don't consider it better
practice than what we do.

Moreover, a standard certificate bundle is not helpful at all, if it
doesn't mention for which purpose those certificates are trusted. Are
they trusted to certify stmp servers? incoming e-mail? web?

The only system that provides it is windows, which is not our primary
platform. The closest thing we have in gnome-based systems, is
gnome-keyring which may not be widely available to depend on.

> As a baseline, are there documentation improvements we could offer, or
> best practice guidelines we should be encouraging?  More aggressively,
> is there some way we could consider offering a simple best-practice
> certification config in the priority string, or as default behavior if

> no other verification mechanism is specified?

The initial idea was that applications know which certificates to
trust, or which CAs to trust. For example I might trust verisign for
web browsing but only my local CA for smtp.

I still believe in the above, but for several applications it seems
it may not make sense. Currently I like the part of the patch of Ludwig
that introduces a gnutls_certificate_set_x509_system_trust(), but it
doesn't set any defaults (because there don't exist in all systems).
For that I'd like more input from the library users here. Are there
standard practices in Linux distributions and other POSIX systems that
would allow to deduce that there is a common trusted certificate bundle?

Are there ways to identify the trust purpose of those certificates?
Is there any intention to standardize something like that, so we don't
end up with our own trust?

regards,
Nikos




From rich at kde.org  Mon May  7 12:35:16 2012
From: rich at kde.org (Richard Moore)
Date: Mon, 7 May 2012 11:35:16 +0100
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA75CD9.6090904@gnutls.org>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
Message-ID: <CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>

On 7 May 2012 06:25, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 05/07/2012 02:31 AM, Daniel Kahn Gillmor wrote:
>
>> In particular, i wanted to take Ludwig's concern seriously here:
>>> Openssl in all it's
>>> ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
>>> doesn't have an equivalent. It's utterly stupid to require each and
>>> every application to hard code the path to a certificate bundle.
>>> Defaulting to not doing any checks at all if the application programmer
>>> forgot to set the magic option isn't exactly clever either.
>> Is there a way that GnuTLS can help facilitate proper peer verification
>> by application (or library) developers who depend on the project?
>
>
> It is a nice point. Ludwig contacted us with a patch lately. I'm for
> such a patch, but there is no notion such as a system certificate
> bundle standardized (even for linux systems only), and openssl only
> points to a random CA list they ship. I don't consider it better
> practice than what we do.

All the linux distros configure openssl to use their own CA bundle,
and don't use the one openssl ships. The CA bundle they ship is
maintained like any other package.

>
> Moreover, a standard certificate bundle is not helpful at all, if it
> doesn't mention for which purpose those certificates are trusted. Are
> they trusted to certify stmp servers? incoming e-mail? web?

This limitation is true. Openssl doesn't really have support for that concept.

>
> The only system that provides it is windows, which is not our primary
> platform. The closest thing we have in gnome-based systems, is
> gnome-keyring which may not be widely available to depend on.
>
>> As a baseline, are there documentation improvements we could offer, or
>> best practice guidelines we should be encouraging? ?More aggressively,
>> is there some way we could consider offering a simple best-practice
>> certification config in the priority string, or as default behavior if
>
>> no other verification mechanism is specified?
>
> The initial idea was that applications know which certificates to
> trust, or which CAs to trust. For example I might trust verisign for
> web browsing but only my local CA for smtp.
>
> I still believe in the above, but for several applications it seems
> it may not make sense. Currently I like the part of the patch of Ludwig
> that introduces a gnutls_certificate_set_x509_system_trust(), but it
> doesn't set any defaults (because there don't exist in all systems).
> For that I'd like more input from the library users here. Are there
> standard practices in Linux distributions and other POSIX systems that
> would allow to deduce that there is a common trusted certificate bundle?

In Qt, we search the following directories (see
https://qt.gitorious.org/qt/qtbase/blobs/master/src/network/ssl/qsslsocket.cpp#line2389):

<<  "/etc/ssl/certs/" // (K)ubuntu, OpenSUSE, Mandriva, MeeGo ...
<< "/usr/lib/ssl/certs/" // Gentoo, Mandrake
<< "/usr/share/ssl/" // Centos, Redhat, SuSE
<< "/usr/local/ssl/" // Normal OpenSSL Tarball
<< "/var/ssl/certs/" // AIX
<< "/usr/local/ssl/certs/" // Solaris
<< "/opt/openssl/certs/"; // HP-UX

In addition where possible we use the directory version of the bundle
rather than the combined file (the directories are hashed allowing for
much faster access).

>
> Are there ways to identify the trust purpose of those certificates?
> Is there any intention to standardize something like that, so we don't
> end up with our own trust?

All the certs are trusted for all purposes in this scheme (subject to
the keyusage flags they contain).

Regards

Rich.

>
> regards,
> Nikos
>
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnutls



From mrsam at courier-mta.com  Mon May  7 13:06:52 2012
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 07 May 2012 07:06:52 -0400
Subject: [oss-security] CVE Request: evolution-data-server lacks SSL
	checking in its libsoup users
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
Message-ID: <cone.1336388812.158245.23314.1000@monster.email-scan.com>

Nikos Mavrogiannopoulos writes:

> The initial idea was that applications know which certificates to
> trust, or which CAs to trust. For example I might trust verisign for
> web browsing but only my local CA for smtp.
>
> I still believe in the above, but for several applications it seems
> it may not make sense. Currently I like the part of the patch of Ludwig
> that introduces a gnutls_certificate_set_x509_system_trust(), but it
> doesn't set any defaults (because there don't exist in all systems).
> For that I'd like more input from the library users here. Are there
> standard practices in Linux distributions and other POSIX systems that
> would allow to deduce that there is a common trusted certificate bundle?

Debian installs /etc/ssl/certs/ca-certificates.crt. Fedora, and its  
derivations, (Red Hat, Cent-OS) have /etc/pki/tls/cert.pem installed.
FreeBSD has /usr/local/share/certs/ca-root-nss.crt

The standard practice on Fedora is to have applications configured or  
patched to use its default /etc/pki/tls/cert.pem certificate bundle.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20120507/7b6a1697/attachment.pgp>

From ludwig.nussel at suse.de  Mon May  7 10:08:46 2012
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Mon, 07 May 2012 10:08:46 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA75CD9.6090904@gnutls.org>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
Message-ID: <4FA7830E.5070400@suse.de>

Nikos Mavrogiannopoulos wrote:
> On 05/07/2012 02:31 AM, Daniel Kahn Gillmor wrote:
> 
>> In particular, i wanted to take Ludwig's concern seriously here:
>>> Openssl in all it's
>>> ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
>>> doesn't have an equivalent. It's utterly stupid to require each and
>>> every application to hard code the path to a certificate bundle.
>>> Defaulting to not doing any checks at all if the application programmer
>>> forgot to set the magic option isn't exactly clever either.
>> Is there a way that GnuTLS can help facilitate proper peer verification
>> by application (or library) developers who depend on the project?
> 
> 
> It is a nice point. Ludwig contacted us with a patch lately. I'm for
> such a patch, but there is no notion such as a system certificate
> bundle standardized (even for linux systems only), and openssl only
> points to a random CA list they ship. I don't consider it better
> practice than what we do.

openssl doesn't ship certificates anymore since quite some time. So
we're using the root certs from mozilla. The update-ca-certificates
script? converts the file into the formats needed by various libraries.
Fedora, Debian, Ubuntu do something similar.

> Moreover, a standard certificate bundle is not helpful at all, if it
> doesn't mention for which purpose those certificates are trusted. Are
> they trusted to certify stmp servers? incoming e-mail? web?

Mozilla does store such trust bits. Openssl also supports a special pem
format that carries this information. Since only openssl supports that
format we couldn't use it in /etc/ssl/certs so far though. Since email
and code signing don't really matter for us in practice /etc/ssl/certs
only contains certificates trusted for server auth. 

> The only system that provides it is windows, which is not our primary
> platform. The closest thing we have in gnome-based systems, is
> gnome-keyring which may not be widely available to depend on.

Well, anything gnome based would be too high level.

>> As a baseline, are there documentation improvements we could offer, or
>> best practice guidelines we should be encouraging?  More aggressively,
>> is there some way we could consider offering a simple best-practice
>> certification config in the priority string, or as default behavior if
> 
>> no other verification mechanism is specified?
> 
> The initial idea was that applications know which certificates to
> trust, or which CAs to trust. For example I might trust verisign for
> web browsing but only my local CA for smtp.

That's a rather specific feature for advanced users though. In general
people don't care at that detail level. It would be nice to have for
sure though. The feature needs to be handled transparently by the
library too IMO.

> I still believe in the above, but for several applications it seems
> it may not make sense. Currently I like the part of the patch of Ludwig
> that introduces a gnutls_certificate_set_x509_system_trust(), but it
> doesn't set any defaults (because there don't exist in all systems).
> For that I'd like more input from the library users here. Are there
> standard practices in Linux distributions and other POSIX systems that
> would allow to deduce that there is a common trusted certificate bundle?
> 
> Are there ways to identify the trust purpose of those certificates?
> Is there any intention to standardize something like that, so we don't
> end up with our own trust?

It would be nice if there was something common. In Fedora and openSUSE
we at least add a textual header to the pem files that has the alias and
trust information from NSS.
Wrt a completely different trust store concept there's this draft which
describes what gnome-keyring does I think:
http://people.collabora.com/~stefw/trust-assertions.html

[1] http://gitorious.org/opensuse/ca-certificates/trees/master

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) 



From nmav at gnutls.org  Mon May  7 18:15:54 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 May 2012 18:15:54 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
Message-ID: <4FA7F53A.2090109@gnutls.org>

On 05/07/2012 12:35 PM, Richard Moore wrote:


>> Are there ways to identify the trust purpose of those certificates?
>> Is there any intention to standardize something like that, so we don't
>> end up with our own trust?
> 
> All the certs are trusted for all purposes in this scheme (subject to
> the keyusage flags they contain).


The problem is that there is no particular scheme and the keyusage
flags are set by the CA, not by the one who trusts the certificate.
Because verisign has a certificate that says it is appropriate for
signing e-mail, it doesn't mean that I want to trust it.

regards,
Nikos




From rich at kde.org  Mon May  7 21:30:10 2012
From: rich at kde.org (Richard Moore)
Date: Mon, 7 May 2012 20:30:10 +0100
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA7F53A.2090109@gnutls.org>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
	<4FA7F53A.2090109@gnutls.org>
Message-ID: <CAMp7mVuOt8GHs6dP=_5zq-H19nBt-K_z47e1WTOC7FOtB6_jKQ@mail.gmail.com>

On 7 May 2012 17:15, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 05/07/2012 12:35 PM, Richard Moore wrote:
>
>
>>> Are there ways to identify the trust purpose of those certificates?
>>> Is there any intention to standardize something like that, so we don't
>>> end up with our own trust?
>>
>> All the certs are trusted for all purposes in this scheme (subject to
>> the keyusage flags they contain).
>
>
> The problem is that there is no particular scheme and the keyusage
> flags are set by the CA, not by the one who trusts the certificate.
> Because verisign has a certificate that says it is appropriate for
> signing e-mail, it doesn't mean that I want to trust it.

Yes, I understand what you're asking for and that's not something
that's supported. NSS has a more complete facility for this sort of
thing using a Berkeley db of certs, but iirc that's only used by
firefox and isn't actually supported by tools like thunderbird. I
think this is basically an area where there's no real support at all
under linux (and to be honest isn't something most users need or have
the ability to configure).

Cheers

Rich.



From ludwig.nussel at suse.de  Tue May  8 14:46:27 2012
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Tue, 08 May 2012 14:46:27 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
Message-ID: <4FA915A3.4030202@suse.de>

Richard Moore wrote:
> On 7 May 2012 06:25, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> [...]
>> Moreover, a standard certificate bundle is not helpful at all, if it
>> doesn't mention for which purpose those certificates are trusted. Are
>> they trusted to certify stmp servers? incoming e-mail? web?
> 
> This limitation is true. Openssl doesn't really have support for that concept.

It supports similar trust settings like NSS though. Check the -addtrust
parameter of "openssl x509".

> [...]
> In Qt, we search the following directories (see
> https://qt.gitorious.org/qt/qtbase/blobs/master/src/network/ssl/qsslsocket.cpp#line2389):
> 
> <<  "/etc/ssl/certs/" // (K)ubuntu, OpenSUSE, Mandriva, MeeGo ...
> << "/usr/lib/ssl/certs/" // Gentoo, Mandrake
> << "/usr/share/ssl/" // Centos, Redhat, SuSE
> << "/usr/local/ssl/" // Normal OpenSSL Tarball
> << "/var/ssl/certs/" // AIX
> << "/usr/local/ssl/certs/" // Solaris
> << "/opt/openssl/certs/"; // HP-UX

What's the reason why you hardcode that list yourself instead of calling
SSL_CTX_set_default_verify_paths()?

>> Are there ways to identify the trust purpose of those certificates?
>> Is there any intention to standardize something like that, so we don't
>> end up with our own trust?
> 
> All the certs are trusted for all purposes in this scheme (subject to
> the keyusage flags they contain).

$ openssl x509 -in /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem -out t.pem
$ openssl s_client -connect build.opensuse.org:443 -CAfile t.pem < /dev/null
[...]
    Verify return code: 0 (ok)

$ openssl x509 -in /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem -out t.pem -addtrust emailProtection
$ openssl s_client -connect build.opensuse.org:443 -CAfile t.pem < /dev/null
[...]
    Verify return code: 2 (unable to get issuer certificate)

$ openssl x509 -in /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem -out t.pem -addtrust serverAuth
$ openssl s_client -connect build.opensuse.org:443 -CAfile t.pem < /dev/null
[...]
    Verify return code: 0 (ok)

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) 



From nmav at gnutls.org  Tue May  8 15:47:49 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 8 May 2012 15:47:49 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <4FA915A3.4030202@suse.de>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
	<4FA915A3.4030202@suse.de>
Message-ID: <CAJU7zaLK6Z0RKM_Y4iiWjOSRPx7Ps4XXOBnGbD6eOj5hD1-diw@mail.gmail.com>

On Tue, May 8, 2012 at 2:46 PM, Ludwig Nussel <ludwig.nussel at suse.de> wrote:

[...]
> It supports similar trust settings like NSS though. Check the -addtrust
> parameter of "openssl x509".

Are you sure that addtrust doesn't just consult the object identifiers
present in the certificate?



From ludwig.nussel at suse.de  Tue May  8 15:57:45 2012
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Tue, 08 May 2012 15:57:45 +0200
Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks
	SSL checking in its libsoup users
In-Reply-To: <CAJU7zaLK6Z0RKM_Y4iiWjOSRPx7Ps4XXOBnGbD6eOj5hD1-diw@mail.gmail.com>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<CAMp7mVs9KQ9P3J53U--mWVotXw67S+mzh3gOvypm-TTyw-W2Hg@mail.gmail.com>
	<4FA915A3.4030202@suse.de>
	<CAJU7zaLK6Z0RKM_Y4iiWjOSRPx7Ps4XXOBnGbD6eOj5hD1-diw@mail.gmail.com>
Message-ID: <4FA92659.9070704@suse.de>

Nikos Mavrogiannopoulos wrote:
> On Tue, May 8, 2012 at 2:46 PM, Ludwig Nussel <ludwig.nussel at suse.de> wrote:
> 
> [...]
>> It supports similar trust settings like NSS though. Check the -addtrust
>> parameter of "openssl x509".
> 
> Are you sure that addtrust doesn't just consult the object identifiers
> present in the certificate?

-addtrust (and -setalias) are independent of the information in the certificate.

crypto/asn1/x_x509a.c:

/* X509_CERT_AUX routines. These are used to encode additional
 * user modifiable data about a certificate. This data is
 * appended to the X509 encoding when the *_X509_AUX routines
 * are used. This means that the "traditional" X509 routines
 * will simply ignore the extra data. 
 */

static X509_CERT_AUX *aux_get(X509 *x);

ASN1_SEQUENCE(X509_CERT_AUX) = {
	ASN1_SEQUENCE_OF_OPT(X509_CERT_AUX, trust, ASN1_OBJECT),
	ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, reject, ASN1_OBJECT, 0),
	ASN1_OPT(X509_CERT_AUX, alias, ASN1_UTF8STRING),
	ASN1_OPT(X509_CERT_AUX, keyid, ASN1_OCTET_STRING),
	ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, other, X509_ALGOR, 1)
} ASN1_SEQUENCE_END(X509_CERT_AUX)

IMPLEMENT_ASN1_FUNCTIONS(X509_CERT_AUX)


cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) 



From t.glaser at tarent.de  Thu May 10 13:59:29 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 10 May 2012 13:59:29 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
Message-ID: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>

Hi,

we?ve got a range of systems in existence, from Debian etch
(formerly sarge) to sid, and Kubuntu hardy (formerly dapper)
to precise.

Now, their latest release, prolonged pain precisely, fails to
connect to our LDAP server (Univention Corporate Server 2.4),
whereas it works with OpenSSL. I?ve had similar issues in hardy
where a ?security? update broke things due to GnuTLS, but this
is new, and somehow gnutls-cli lacks the usual debugging output.

root at foo-test:~ # openssl s_client -CAfile /etc/ssl/certs/ca-c* -connect dc.lan.tarent.de:636
CONNECTED(00000003)
depth=1 C = DE, ST = NRW, L = Bonn, O = tarent GmbH, OU = IT, CN = Univention Corporate Server Root CA, emailAddress = admins at tarent.de
verify return:1
depth=0 C = DE, ST = NRW, L = Bonn, O = tarent GmbH, OU = IT, CN = dc.lan.tarent.de, emailAddress = admins at tarent.de
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=dc.lan.tarent.de/emailAddress=admins at tarent.de
   i:/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=Univention Corporate Server Root CA/emailAddress=admins at tarent.de
 1 s:/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=Univention Corporate Server Root CA/emailAddress=admins at tarent.de
   i:/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=Univention Corporate Server Root CA/emailAddress=admins at tarent.de
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEITCCAwmgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnDELMAkGA1UEBhMCREUx
DDAKBgNVBAgTA05SVzENMAsGA1UEBxMEQm9ubjEUMBIGA1UEChMLdGFyZW50IEdt
YkgxCzAJBgNVBAsTAklUMSwwKgYDVQQDEyNVbml2ZW50aW9uIENvcnBvcmF0ZSBT
ZXJ2ZXIgUm9vdCBDQTEfMB0GCSqGSIb3DQEJARYQYWRtaW5zQHRhcmVudC5kZTAe
Fw0xMTAyMDcxMDI0MjlaFw0xNjAyMDYxMDI0MjlaMIGJMQswCQYDVQQGEwJERTEM
MAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0YXJlbnQgR21i
SDELMAkGA1UECxMCSVQxGTAXBgNVBAMTEGRjLmxhbi50YXJlbnQuZGUxHzAdBgkq
hkiG9w0BCQEWEGFkbWluc0B0YXJlbnQuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALec1kjx6ebHDWjNZ47DFCk91oMR0JU7dWKdDcJnX4NpIClXfYmfT5lU
1nIdEVkaG9vqAEgv1tXGVh78y5HENvjMoqndNK0vZuuJ+huoV5oLdfHaDKfQ9HM9
zyQedZVvu3/BZRI2ZOustxQrbZk/BbY2zEGZ+vtSiUaUgy2sNBPvAgMBAAGjggEB
MIH+MAkGA1UdEwQCMAAwHQYDVR0OBBYEFIX4Fy+mIvJiFcXakJKmS6d+AH+mMIHR
BgNVHSMEgckwgcaAFGGbZa17dyVam6QIMlB3SSrW3R12oYGipIGfMIGcMQswCQYD
VQQGEwJERTEMMAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0
YXJlbnQgR21iSDELMAkGA1UECxMCSVQxLDAqBgNVBAMTI1VuaXZlbnRpb24gQ29y
cG9yYXRlIFNlcnZlciBSb290IENBMR8wHQYJKoZIhvcNAQkBFhBhZG1pbnNAdGFy
ZW50LmRlggkAnXueqx7HokkwDQYJKoZIhvcNAQEFBQADggEBACM2aAg5fCBucTeX
RLy7tq8wb33nkPs9Ai2IyUSkdk5lIarNapKApYZKnX7cWrpNiGejG6lLyYXwS9oo
QQs94SnLt3583sL+VTxST3Xj4sQicbkZW+I/QX+Y3sACvhibDEawXHZPCzMQxNgk
LvBsaM7uAo7HhzoPVQlM32rg3mXX7Nsunv31hw/WjKHI0MW8YfBIPf3o40GGnDcn
QRFhzYQY3u+bYKz0qzy1YfQxjvqFBnrJJFC1m9wfZs9dfAjkDb5TDVTKR1y1sEaU
g2SrN46OVYEygNqlSTJdcgxcFWSrS1W3yrtBoduP8xqyWePasO3TTHWkNIwfKnPm
0HJAFlU=
-----END CERTIFICATE-----
subject=/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=dc.lan.tarent.de/emailAddress=admins at tarent.de
issuer=/C=DE/ST=NRW/L=Bonn/O=tarent GmbH/OU=IT/CN=Univention Corporate Server Root CA/emailAddress=admins at tarent.de
---
No client certificate CA names sent
---
SSL handshake has read 2755 bytes and written 424 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 8C490472FCC8CC171EC84BF3DE01F1350331F3B07609F84A140C60DBEA18ECDD
    Session-ID-ctx:
    Master-Key: 97C718741EDBC258C73313979B1992F4FCDC400948A143B6BC68D0C2465CF6CE948BEB22E4013E05595986326BF3657D
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 30 2c d0 40 e2 10 8a f3-01 23 47 48 d8 f8 0c 68   0,. at .....#GH...h
    0010 - 7e e8 47 02 9a 25 b3 17-2f c9 ca 04 1c 4c fa 6c   ~.G..%../....L.l
    0020 - 95 32 82 57 c6 4c b4 0e-bd 0a 64 fa 06 ab 1f 8b   .2.W.L....d.....
    0030 - f1 aa f1 43 03 ba 70 67-4d de e6 56 fc 9e 9b ce   ...C..pgM..V....
    0040 - c9 90 f5 f3 a5 33 d5 a6-99 a0 e9 8a 3f 12 8e 9d   .....3......?...
    0050 - 32 86 2f a0 89 a5 a0 30-2f 4b 85 4e d2 ec b4 0a   2./....0/K.N....
    0060 - 92 35 2b ba 12 6f 5c aa-a2 6d e4 b0 c7 5e d8 27   .5+..o\..m...^.'
    0070 - 95 cf 22 8d 9a f5 1d 25-f5 a8 7d 22 62 4b b2 70   .."....%..}"bK.p
    0080 - c9 e8 7d 86 d3 5b 0b f1-24 34 1c e8 2e 8f f9 ca   ..}..[..$4......
    0090 - 70 70 d8 a1 99 49 0b b0-63 5e 13 e6 4a 41 87 70   pp...I..c^..JA.p

    Compression: 1 (zlib compression)
    Start Time: 1336645861
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
QUIT
DONE
root at foo-test:~ # gnutls-cli -V -d 4711 -p 636 --x509cafile /etc/ssl/certs/ca-c* dc.lan.tarent.de
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
|<4>| REC[0x11d0210]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:695
|<4>| REC[0x11d0210]: Allocating epoch #1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x11d0210]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<2>| EXT[0x11d0210]: Sending extension SERVER NAME (21 bytes)
|<2>| EXT[0x11d0210]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0x11d0210]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0x11d0210]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x11d0210]: CLIENT HELLO was sent [141 bytes]
|<6>| BUF[HSK]: Inserted 141 bytes of Data
|<7>| HWRITE: enqueued 141. Total 141 bytes.
|<7>| HWRITE FLUSH: 141 bytes in buffer.
|<4>| REC[0x11d0210]: Sending Packet[0] Handshake(22) with length: 141
|<7>| WRITE: enqueued 146 bytes for 0x4. Total 146 bytes.
|<4>| REC[0x11d0210]: Sent Packet[1] Handshake(22) with length: 146
|<7>| HWRITE: wrote 141 bytes, 0 bytes left.
|<7>| WRITE FLUSH: 146 bytes in buffer.
|<7>| WRITE: wrote 146 bytes, 0 bytes left.
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x11d0210]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x11d0210]: Received Packet[0] Handshake(22) with length: 53
|<7>| READ: Got 53 bytes from 0x4
|<7>| READ: read 53 bytes from 0x4
|<7>| RB: Have 5 bytes into buffer. Adding 53 bytes.
|<7>| RB: Requested 58 bytes
|<4>| REC[0x11d0210]: Decrypted Packet[0] Handshake(22) with length: 53
|<6>| BUF[HSK]: Inserted 53 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[0x11d0210]: SERVER HELLO was received [53 bytes]
|<6>| BUF[REC][HD]: Read 49 bytes of Data(22)
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 49 bytes of Data
|<3>| HSK[0x11d0210]: Server's version: 3.1
|<3>| HSK[0x11d0210]: SessionID length: 0
|<3>| HSK[0x11d0210]: SessionID: 00
|<3>| HSK[0x11d0210]: Selected cipher suite: RSA_AES_128_CBC_SHA1
|<2>| EXT[0x11d0210]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<2>| EXT[0x11d0210]: Parsing extension 'SESSION TICKET/35' (0 bytes)
|<3>| HSK[0x11d0210]: Safe renegotiation succeeded
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x11d0210]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x11d0210]: Received Packet[1] Handshake(22) with length: 2449
|<7>| READ: Got 2449 bytes from 0x4
|<7>| READ: read 2449 bytes from 0x4
|<7>| RB: Have 5 bytes into buffer. Adding 2449 bytes.
|<7>| RB: Requested 2454 bytes
|<4>| REC[0x11d0210]: Decrypted Packet[1] Handshake(22) with length: 2449
|<6>| BUF[HSK]: Inserted 2449 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[0x11d0210]: CERTIFICATE was received [2449 bytes]
|<6>| BUF[REC][HD]: Read 2445 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 194 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 2445 bytes of Data
|<2>| ASSERT: ext_signature.c:388
|<2>| ASSERT: ext_signature.c:388
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: mpi.c:609
|<2>| ASSERT: gnutls_pk.c:266
|<2>| ASSERT: verify.c:730
|<2>| ASSERT: verify.c:857
|<2>| ASSERT: verify.c:1011
|<2>| ASSERT: verify.c:373
|<2>| ASSERT: dn.c:1209
|<2>| ASSERT: verify.c:552
*** Verifying server certificate failed...
|<2>| ASSERT: gnutls_kx.c:705
|<2>| ASSERT: gnutls_handshake.c:2777
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: Error in the certificate.
|<4>| REC: Sending Alert[2|42] - Certificate is bad
|<4>| REC[0x11d0210]: Sending Packet[1] Alert(21) with length: 2
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0x11d0210]: Sent Packet[2] Alert(21) with length: 7
*** Handshake has failed
GnuTLS error: Error in the certificate.
|<6>| BUF[HSK]: Cleared Data from buffer
|<4>| REC[0x11d0210]: Epoch #0 freed
|<4>| REC[0x11d0210]: Epoch #1 freed

Versions:

# dpkg-query -W gnutls-bin libgnutls2{6,8}
gnutls-bin      3.0.11+really2.12.14-5ubuntu3
libgnutls26     2.12.14-5ubuntu3
No packages found matching libgnutls28.


Debian sid for comparison has:

root at tglase-amd64:~ # dpkg-query -W gnutls-bin libgnutls2{6,8}
gnutls-bin      3.0.19-2
libgnutls26:amd64       2.12.19-1
libgnutls28:amd64       3.0.19-2
root at tglase-amd64:~ # gnutls-cli -V -p 636 --x509cafile /etc/ssl/certs/ca-c* dc.lan.tarent.de
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
- Peer's certificate is trusted
- The hostname in the certificate matches 'dc.lan.tarent.de'.
- Session ID: 4F:07:04:93:B6:2A:AB:BA:CF:3A:6F:D0:78:DB:17:91:CF:4F:09:3F:58:98:19:DA:89:A0:CB:C6:93:E9:FC:36
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 01
        Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Validity:
                Not Before: Mon Feb 07 10:24:29 UTC 2011
                Not After: Sat Feb 06 10:24:29 UTC 2016
        Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=dc.lan.tarent.de,EMAIL=admins at tarent.de
        Subject Public Key Algorithm: RSA
        Certificate Security Level: Low (1024 bits)
                Modulus (bits 1024):
                        00:b7:9c:d6:48:f1:e9:e6:c7:0d:68:cd:67:8e:c3:14
                        29:3d:d6:83:11:d0:95:3b:75:62:9d:0d:c2:67:5f:83
                        69:20:29:57:7d:89:9f:4f:99:54:d6:72:1d:11:59:1a
                        1b:db:ea:00:48:2f:d6:d5:c6:56:1e:fc:cb:91:c4:36
                        f8:cc:a2:a9:dd:34:ad:2f:66:eb:89:fa:1b:a8:57:9a
                        0b:75:f1:da:0c:a7:d0:f4:73:3d:cf:24:1e:75:95:6f
                        bb:7f:c1:65:12:36:64:eb:ac:b7:14:2b:6d:99:3f:05
                        b6:36:cc:41:99:fa:fb:52:89:46:94:83:2d:ac:34:13
                        ef
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (not critical):
                        Certificate Authority (CA): FALSE
                Subject Key Identifier (not critical):
                        85f8172fa622f26215c5da9092a64ba77e007fa6
                Authority Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
        Signature Algorithm: RSA-SHA1
        Signature:
                23:36:68:08:39:7c:20:6e:71:37:97:44:bc:bb:b6:af
                30:6f:7d:e7:90:fb:3d:02:2d:88:c9:44:a4:76:4e:65
                21:aa:cd:6a:92:80:a5:86:4a:9d:7e:dc:5a:ba:4d:88
                67:a3:1b:a9:4b:c9:85:f0:4b:da:28:41:0b:3d:e1:29
                cb:b7:7e:7c:de:c2:fe:55:3c:52:4f:75:e3:e2:c4:22
                71:b9:19:5b:e2:3f:41:7f:98:de:c0:02:be:18:9b:0c
                46:b0:5c:76:4f:0b:33:10:c4:d8:24:2e:f0:6c:68:ce
                ee:02:8e:c7:87:3a:0f:55:09:4c:df:6a:e0:de:65:d7
                ec:db:2e:9e:fd:f5:87:0f:d6:8c:a1:c8:d0:c5:bc:61
                f0:48:3d:fd:e8:e3:41:86:9c:37:27:41:11:61:cd:84
                18:de:ef:9b:60:ac:f4:ab:3c:b5:61:f4:31:8e:fa:85
                06:7a:c9:24:50:b5:9b:dc:1f:66:cf:5d:7c:08:e4:0d
                be:53:0d:54:ca:47:5c:b5:b0:46:94:83:64:ab:37:8e
                8e:55:81:32:80:da:a5:49:32:5d:72:0c:5c:15:64:ab
                4b:55:b7:ca:bb:41:a1:db:8f:f3:1a:b2:59:e3:da:b0
                ed:d3:4c:75:a4:34:8c:1f:2a:73:e6:d0:72:40:16:55
Other Information:
        SHA-1 fingerprint:
                c11f5038e915c4cdf36743bc39b62ff60be8fdbf
        Public Key Id:
                d7b3d676cb339e976809b438a12e7bf0f30c5ba5
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                |                 |
                |                 |
                |         . o     |
                |        S =.+    |
                |     . . +oo +   |
                |      +. E. + = o|
                |     . ==  . =.=+|
                |     .+.oo  . .=+|
                +-----------------+


-----BEGIN CERTIFICATE-----
MIIEITCCAwmgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnDELMAkGA1UEBhMCREUx
DDAKBgNVBAgTA05SVzENMAsGA1UEBxMEQm9ubjEUMBIGA1UEChMLdGFyZW50IEdt
YkgxCzAJBgNVBAsTAklUMSwwKgYDVQQDEyNVbml2ZW50aW9uIENvcnBvcmF0ZSBT
ZXJ2ZXIgUm9vdCBDQTEfMB0GCSqGSIb3DQEJARYQYWRtaW5zQHRhcmVudC5kZTAe
Fw0xMTAyMDcxMDI0MjlaFw0xNjAyMDYxMDI0MjlaMIGJMQswCQYDVQQGEwJERTEM
MAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0YXJlbnQgR21i
SDELMAkGA1UECxMCSVQxGTAXBgNVBAMTEGRjLmxhbi50YXJlbnQuZGUxHzAdBgkq
hkiG9w0BCQEWEGFkbWluc0B0YXJlbnQuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALec1kjx6ebHDWjNZ47DFCk91oMR0JU7dWKdDcJnX4NpIClXfYmfT5lU
1nIdEVkaG9vqAEgv1tXGVh78y5HENvjMoqndNK0vZuuJ+huoV5oLdfHaDKfQ9HM9
zyQedZVvu3/BZRI2ZOustxQrbZk/BbY2zEGZ+vtSiUaUgy2sNBPvAgMBAAGjggEB
MIH+MAkGA1UdEwQCMAAwHQYDVR0OBBYEFIX4Fy+mIvJiFcXakJKmS6d+AH+mMIHR
BgNVHSMEgckwgcaAFGGbZa17dyVam6QIMlB3SSrW3R12oYGipIGfMIGcMQswCQYD
VQQGEwJERTEMMAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0
YXJlbnQgR21iSDELMAkGA1UECxMCSVQxLDAqBgNVBAMTI1VuaXZlbnRpb24gQ29y
cG9yYXRlIFNlcnZlciBSb290IENBMR8wHQYJKoZIhvcNAQkBFhBhZG1pbnNAdGFy
ZW50LmRlggkAnXueqx7HokkwDQYJKoZIhvcNAQEFBQADggEBACM2aAg5fCBucTeX
RLy7tq8wb33nkPs9Ai2IyUSkdk5lIarNapKApYZKnX7cWrpNiGejG6lLyYXwS9oo
QQs94SnLt3583sL+VTxST3Xj4sQicbkZW+I/QX+Y3sACvhibDEawXHZPCzMQxNgk
LvBsaM7uAo7HhzoPVQlM32rg3mXX7Nsunv31hw/WjKHI0MW8YfBIPf3o40GGnDcn
QRFhzYQY3u+bYKz0qzy1YfQxjvqFBnrJJFC1m9wfZs9dfAjkDb5TDVTKR1y1sEaU
g2SrN46OVYEygNqlSTJdcgxcFWSrS1W3yrtBoduP8xqyWePasO3TTHWkNIwfKnPm
0HJAFlU=
-----END CERTIFICATE-----

- Certificate[1] info:
 - X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 009d7b9eab1ec7a249
        Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Validity:
                Not Before: Mon Feb 07 10:24:29 UTC 2011
                Not After: Wed Feb 06 10:24:29 UTC 2013
        Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Subject Public Key Algorithm: RSA
        Certificate Security Level: Legacy (2048 bits)
                Modulus (bits 2048):
                        00:b1:86:75:49:51:8c:0d:19:f4:f5:1d:9e:63:c1:0b
                        01:04:df:ba:dc:05:bc:49:4e:6c:21:de:7b:2c:a5:dd
                        bf:89:bd:2f:8e:a6:e1:6a:61:aa:4c:e0:1e:c4:48:5e
                        04:45:33:b9:d8:1f:99:ab:46:72:f4:42:f7:5a:4a:0d
                        ec:a6:78:2d:1c:64:63:97:8a:16:90:80:36:9e:30:ac
                        a0:c1:91:56:e4:6e:ea:38:9d:dd:de:30:a7:e5:6f:40
                        71:91:90:38:6d:4e:c8:1a:f7:ed:59:6a:b8:96:bf:54
                        3b:0e:6f:98:61:94:ab:1b:58:4d:db:78:a8:19:38:ea
                        4e:b6:1c:0b:6d:b3:76:1a:4e:80:c7:68:9b:0b:e3:81
                        5a:14:5d:ea:61:b5:a1:9d:b1:ec:d8:b7:37:f7:a4:01
                        d3:13:b7:88:3f:08:9a:43:de:2d:30:f3:ad:60:d3:09
                        36:b7:08:7e:d6:cf:04:9b:bd:45:ac:55:8f:0b:bc:49
                        ca:3f:e7:c8:2a:42:3a:05:d5:dd:07:77:10:c2:07:ca
                        a2:2a:2e:84:a9:6b:b3:b0:f8:79:25:8e:bc:b5:c1:d7
                        c2:1c:d7:0a:41:b0:55:4f:d0:44:50:d2:15:75:5b:21
                        dd:a5:24:82:a9:99:63:8b:8d:d5:7d:71:19:31:62:e4
                        f7
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Subject Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
                Authority Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
                Key Usage (not critical):
                        Certificate signing.
                        CRL signing.
                Unknown extension 2.16.840.1.113730.1.1 (not critical):
                        ASCII: ....
                        Hexdump: 03020007
                Subject Alternative Name (not critical):
                        RFC822name: admins at tarent.de
                Issuer Alternative Name (not critical):
                        RFC822name: admins at tarent.de
                Unknown extension 2.16.840.1.113730.1.13 (not critical):
                        ASCII: .)This certificate is a Root CA Certificate
                        Hexdump: 162954686973206365727469666963617465206973206120526f6f74204341204365727469666963617465
        Signature Algorithm: RSA-SHA1
        Signature:
                5b:a1:a8:ec:95:0a:95:40:ed:da:55:79:bb:75:9e:0d
                1c:73:dd:dc:e7:79:17:00:57:d7:08:a7:1b:7b:45:f3
                e3:7d:41:80:e1:49:4b:34:a1:cc:91:e1:e3:db:20:d9
                1f:01:8a:bc:74:10:40:6a:2a:c4:9c:05:d6:1a:27:c0
                da:83:81:0e:34:f7:f4:04:c5:68:38:c1:67:74:44:ab
                28:ee:a7:54:32:d7:1c:95:eb:90:a6:b9:46:d1:96:05
                99:8b:f0:d2:a3:05:43:82:3c:a1:e3:9d:52:b5:94:65
                df:df:9d:88:b5:d7:7b:1e:71:28:1e:a1:b2:80:2b:80
                57:59:57:e9:3f:10:78:01:45:54:cf:11:3c:6d:3e:ab
                50:59:3b:11:82:9a:a8:ad:ca:5a:8f:4a:e2:0c:40:da
                84:9f:bc:14:41:31:f7:ec:13:4d:48:b5:1e:96:65:3b
                1d:58:49:70:cf:04:f8:57:d3:7e:a3:3a:45:4f:05:78
                12:20:a5:b8:3a:5e:d8:17:b1:4c:37:fc:16:4e:d0:3e
                b8:ef:18:7d:ed:b2:17:c5:a6:d8:c1:34:84:34:b1:bf
                a9:67:f9:fc:82:20:96:6f:39:86:3b:bd:bd:98:52:a1
                e8:3d:6f:cb:1d:ff:f0:36:a6:c2:bf:72:3c:9b:65:21
Other Information:
        SHA-1 fingerprint:
                6da9e3f7bcea0df189a7f599599bc253517a57fc
        Public Key Id:
                2c1c29def291b0232e96889b4404cdc2cafb5997
        Public key's random art:
                +--[ RSA 2048]----+
                |oo               |
                |o.o    .         |
                |oo  o o          |
                |o. . * +         |
                | .o = * S        |
                |+o.. = E         |
                |++o o o          |
                |o+ o             |
                |o                |
                +-----------------+


-----BEGIN CERTIFICATE-----
MIIFWzCCBEOgAwIBAgIJAJ17nqsex6JJMA0GCSqGSIb3DQEBBQUAMIGcMQswCQYD
VQQGEwJERTEMMAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0
YXJlbnQgR21iSDELMAkGA1UECxMCSVQxLDAqBgNVBAMTI1VuaXZlbnRpb24gQ29y
cG9yYXRlIFNlcnZlciBSb290IENBMR8wHQYJKoZIhvcNAQkBFhBhZG1pbnNAdGFy
ZW50LmRlMB4XDTExMDIwNzEwMjQyOVoXDTEzMDIwNjEwMjQyOVowgZwxCzAJBgNV
BAYTAkRFMQwwCgYDVQQIEwNOUlcxDTALBgNVBAcTBEJvbm4xFDASBgNVBAoTC3Rh
cmVudCBHbWJIMQswCQYDVQQLEwJJVDEsMCoGA1UEAxMjVW5pdmVudGlvbiBDb3Jw
b3JhdGUgU2VydmVyIFJvb3QgQ0ExHzAdBgkqhkiG9w0BCQEWEGFkbWluc0B0YXJl
bnQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxhnVJUYwNGfT1
HZ5jwQsBBN+63AW8SU5sId57LKXdv4m9L46m4WphqkzgHsRIXgRFM7nYH5mrRnL0
QvdaSg3spngtHGRjl4oWkIA2njCsoMGRVuRu6jid3d4wp+VvQHGRkDhtTsga9+1Z
ariWv1Q7Dm+YYZSrG1hN23ioGTjqTrYcC22zdhpOgMdomwvjgVoUXephtaGdsezY
tzf3pAHTE7eIPwiaQ94tMPOtYNMJNrcIftbPBJu9RaxVjwu8Sco/58gqQjoF1d0H
dxDCB8qiKi6EqWuzsPh5JY68tcHXwhzXCkGwVU/QRFDSFXVbId2lJIKpmWOLjdV9
cRkxYuT3AgMBAAGjggGcMIIBmDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRh
m2Wte3clWpukCDJQd0kq1t0ddjCB0QYDVR0jBIHJMIHGgBRhm2Wte3clWpukCDJQ
d0kq1t0ddqGBoqSBnzCBnDELMAkGA1UEBhMCREUxDDAKBgNVBAgTA05SVzENMAsG
A1UEBxMEQm9ubjEUMBIGA1UEChMLdGFyZW50IEdtYkgxCzAJBgNVBAsTAklUMSww
KgYDVQQDEyNVbml2ZW50aW9uIENvcnBvcmF0ZSBTZXJ2ZXIgUm9vdCBDQTEfMB0G
CSqGSIb3DQEJARYQYWRtaW5zQHRhcmVudC5kZYIJAJ17nqsex6JJMAsGA1UdDwQE
AwIBBjARBglghkgBhvhCAQEEBAMCAAcwGwYDVR0RBBQwEoEQYWRtaW5zQHRhcmVu
dC5kZTAbBgNVHRIEFDASgRBhZG1pbnNAdGFyZW50LmRlMDgGCWCGSAGG+EIBDQQr
FilUaGlzIGNlcnRpZmljYXRlIGlzIGEgUm9vdCBDQSBDZXJ0aWZpY2F0ZTANBgkq
hkiG9w0BAQUFAAOCAQEAW6Go7JUKlUDt2lV5u3WeDRxz3dzneRcAV9cIpxt7RfPj
fUGA4UlLNKHMkeHj2yDZHwGKvHQQQGoqxJwF1honwNqDgQ409/QExWg4wWd0RKso
7qdUMtccleuQprlG0ZYFmYvw0qMFQ4I8oeOdUrWUZd/fnYi113secSgeobKAK4BX
WVfpPxB4AUVUzxE8bT6rUFk7EYKaqK3KWo9K4gxA2oSfvBRBMffsE01ItR6WZTsd
WElwzwT4V9N+ozpFTwV4EiCluDpe2BexTDf8Fk7QPrjvGH3tshfFptjBNIQ0sb+p
Z/n8giCWbzmGO729mFKh6D1vyx3/8Damwr9yPJtlIQ==
-----END CERTIFICATE-----

- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Channel binding 'tls-unique': a22ef1b76eb9f8b5cd08e865
- Handshake was completed

- Simple Client Mode:

[ cursor here ]


Any ideas welcome. The certificates (CA and LDAP server) are
autogenerated by some Univention scripts, in case someone needs
to know.

Thanks in advance,
//mirabilos (also tg at debian.org)
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From nmav at gnutls.org  Thu May 10 20:27:30 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 May 2012 20:27:30 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
Message-ID: <4FAC0892.3040600@gnutls.org>

On 05/10/2012 01:59 PM, Thorsten Glaser wrote:

> Hi,

> we?ve got a range of systems in existence, from Debian etch
> (formerly sarge) to sid, and Kubuntu hardy (formerly dapper)
> to precise.
> 
> Now, their latest release, prolonged pain precisely, fails to
> connect to our LDAP server (Univention Corporate Server 2.4),
> whereas it works with OpenSSL. I?ve had similar issues in hardy
> where a ?security? update broke things due to GnuTLS, but this
> is new, and somehow gnutls-cli lacks the usual debugging output.


Hello,
 What do you mean by the usual debugging output?

> root at foo-test:~ # gnutls-cli -V -d 4711 -p 636 --x509cafile
/etc/ssl/certs/ca-c* dc.lan.tarent.de

The option `x509cafile' accepts a single file. If you use the * to
import more than one files it shouldn't work.

> Any ideas welcome. The certificates (CA and LDAP server) are
> autogenerated by some Univention scripts, in case someone needs
> to know.


So if I understand your issue is that gnutls 3.0.11 doesn't work
for you in  ubuntu but gnutls 3.0.19 works for you in a debian
system? I don't know what to suggest. Do these releases work for
you if you install them from our released tarballs?

regards,
Nikos



From nmav at gnutls.org  Fri May 11 13:55:50 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 11 May 2012 13:55:50 +0200
Subject: [oss-security] CVE Request: evolution-data-server lacks SSL
	checking in its libsoup users
In-Reply-To: <cone.1336388812.158245.23314.1000@monster.email-scan.com>
References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net>
	<4FA75CD9.6090904@gnutls.org>
	<cone.1336388812.158245.23314.1000@monster.email-scan.com>
Message-ID: <CAJU7zaL+Wk-BmyWvMVDC_ik6-_eQmMR4iG=R+S51VVd7tYyyAA@mail.gmail.com>

On Mon, May 7, 2012 at 1:06 PM, Sam Varshavchik <mrsam at courier-mta.com> wrote:

> Debian installs /etc/ssl/certs/ca-certificates.crt. Fedora, and its
> derivations, (Red Hat, Cent-OS) have /etc/pki/tls/cert.pem installed.
> FreeBSD has /usr/local/share/certs/ca-root-nss.crt
> The standard practice on Fedora is to have applications configured or
> patched to use its default /etc/pki/tls/cert.pem certificate bundle.

Thanks to Ludwig the next releases of gnutls would include a new function,
gnutls_certificate_set_x509_system_trust(), which will use the system's
trusted certificates, which are determined at configure time. Are there any
comments or suggestions on this functionality?

regards,
Nikos



From t.glaser at tarent.de  Fri May 11 13:14:27 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 11 May 2012 13:14:27 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FAC0892.3040600@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>

On Thu, 10 May 2012, Nikos Mavrogiannopoulos wrote:

>  What do you mean by the usual debugging output?

These lines from the gnutls output on Debian:

- Certificate[1] info:

For example.

> > root at foo-test:~ # gnutls-cli -V -d 4711 -p 636 --x509cafile
> /etc/ssl/certs/ca-c* dc.lan.tarent.de
> 
> The option `x509cafile' accepts a single file. If you use the * to
> import more than one files it shouldn't work.

No, that?s one file, I just shortened it with a ?*? to get the
command on a single line.

> So if I understand your issue is that gnutls 3.0.11 doesn't work
> for you in  ubuntu

Or rather, whatever version they ship and link OpenLDAP (and
gnutls-cli) with. From the dpkg output, this looks like 2.12.14
to me (but then, with older versions, we never had trouble like
this either).

> but gnutls 3.0.19 works for you in a debian
> system? I don't know what to suggest. Do these releases work for
> you if you install them from our released tarballs?

Urgh. I don?t know when I can answer that question.
I will try to fit that experimentation in somewhen
next week.

Thanks anyway!

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From vitali at schauermann.org  Fri May 11 15:26:58 2012
From: vitali at schauermann.org (Vitali Schauermann)
Date: Fri, 11 May 2012 15:26:58 +0200 (CEST)
Subject: Receiving forst message after succcessfull TLS negotiation failed
Message-ID: <1858476268.72338.1336742818355.JavaMail.open-xchange@com4.strato.de>

Hello,


i am using a XMPP library (iksemel) with GnuTLS support for communication with a
XMPP server (GoogleTalk or Openfire).

The TLS negotiation (handshake) is performed without errors, but the firs read
request fails with following error code:

GNUTLS_E_UNEXPECTED_PACKET_LENGTH /* GNUTLS_A_RECORD_OVERFLOW */


Obviously, this as some kind of error, which is not ambiguous and points to some
deeper problem,
the question is, it is possible to "enable" some debuging information for gather
the really problem ?


Hare is the source code used for TLS negotiation:


static int
tls_handshake (struct ikstls_data **datap, ikstransport *trans, void *sock)
{
    const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, 0 };
    const int kx_priority[] = { GNUTLS_KX_RSA, 0 };
    const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC,
GNUTLS_CIPHER_ARCFOUR, 0};
    const int comp_priority[] = { GNUTLS_COMP_ZLIB, GNUTLS_COMP_NULL, 0 };
    const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0 };
    struct ikstls_data *data;
    int ret;

    *datap = NULL;

    data = iks_malloc (sizeof(*data));
    if (!data) return IKS_NOMEM;
    memset (data, 0, sizeof(*data));
    data->trans = trans;
    data->sock = sock;
    data->timeout = -1;

    if (gnutls_global_init () != 0) {
        iks_free (data);
        return IKS_NOMEM;
    }

    if (gnutls_certificate_allocate_credentials (&data->cred) < 0) {
        iks_free (data);
        return IKS_NOMEM;
    }

    if (gnutls_init (&data->sess, GNUTLS_CLIENT) != 0) {
        gnutls_certificate_free_credentials (data->cred);
        iks_free (data);
        return IKS_NOMEM;
    }



    gnutls_protocol_set_priority (data->sess, protocol_priority);
    gnutls_cipher_set_priority(data->sess, cipher_priority);
    gnutls_compression_set_priority(data->sess, comp_priority);
    gnutls_kx_set_priority(data->sess, kx_priority);
    gnutls_mac_set_priority(data->sess, mac_priority);
    gnutls_credentials_set (data->sess, GNUTLS_CRD_CERTIFICATE, data->cred);

    gnutls_transport_set_push_function (data->sess, (gnutls_push_func)
tls_push);
    gnutls_transport_set_pull_function (data->sess, (gnutls_pull_func)
tls_pull);
    gnutls_transport_set_ptr (data->sess, data);

    ret = gnutls_handshake (data->sess);
    if (ret != 0) {
        gnutls_deinit (data->sess);
        gnutls_certificate_free_credentials (data->cred);
        iks_free (data);
        return IKS_NET_TLSFAIL;
    }

    *datap = data;
    return IKS_OK;
}



Additionally is the session data flow:


SEND[<?xml version='1.0'?><stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'
to='10.90.6.140' version='1.0'>]
RECV[<?xml version='1.0' encoding='UTF-8'?><stream:stream
xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"
from="10.90.6.140" id="2cb01145" xml:lang="en"
version="1.0"><stream:features><starttls
xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms></stream:features>]
SEND[<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>]
RECV[<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>]

===> start TLS handshake

TLS GNUTLS: tls_handshake
TLS GNUTLS: tls_push: 55 bytes

16 03 01 00 32 01 00 00 2e 03 01 4f ad 00 10 ab
f2 66 d9 3f e2 d2 60 15 95 ef f5 c2 c7 c7 19 14
91 dd c2 f3 5f 38 93 4f 71 ef a5 00 00 06 00 0a
00 05 00 04 02 01 00

TLS GNUTLS: tls_pull

16 03 01 03 34


TLS GNUTLS: tls_pull

02 00 00 46 03 01 4f ad 00 10 c3 80 19 37 6a 4c
97 a3 19 a4 e6 a4 f9 f6 6d e9 37 c0 a5 53 e8 f7
f3 ee dd 9e 1f b1 20 4f ad 00 10 96 31 0b 0f e8
82 4a 50 c7 7f f1 42 36 45 98 81 ef 05 f5 8e 10
9b e1 7a ab be 58 f5 00 0a 00 0b 00 02 e2 00 02
df 00 02 dc 30 82 02 d8 30 82 01 c0 a0 03 02 01
02 02 08 67 bd 0d b9 b4 2c 66 23 30 0d 06 09 2a
86 48 86 f7 0d 01 01 05 05 00 30 16 31 14 30 12
06 03 55 04 03 0c 0b 31 30 2e 39 30 2e 36 2e 31
34 30 30 1e 17 0d 31 32 30 32 31 30 31 31 30 30
35 38 5a 17 0d 31 37 30 31 31 34 31 31 30 30 35
38 5a 30 16 31 14 30 12 06 03 55 04 03 0c 0b 31
30 2e 39 30 2e 36 2e 31 34 30 30 82 01 22 30 0d
06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01
0f 00 30 82 01 0a 02 82 01 01 00 c7 da cc cf 72
8c 85 75 03 ee 1b 90 90 8f cd f2 db a0 14 fc bc
ed 74 28 a5 21 e0 52 7f f6 41 45 fa 17 95 f9 16
02 6b c4 e7 93 f2 3c be a8 34 ab b5 79 12 28 ba
39 43 18 44 4a bf a1 ac 43 7a 94 7b 9f c9 4d 00
bb 93 c0 dd 70 e3 b4 75 b4 3e 33 b5 a0 24 67 d0
a3 52 43 60 89 5c 4b ce b3 be fa 4c 80 6e fa 87
5d bf c9 d6 e7 35 44 36 88 aa ef f8 50 a3 3d 16
bd 12 28 59 8d 0d fa 1d f8 64 03 b4 96 2e ff 56
41 17 93 44 cf 7a 75 42 f9 c8 2d b2 4c 1b 12 35
fb 1d 45 e0 62 5b 1a d1 4b d3 4b 91 94 49 74 4a
24 1e 58 06 d5 06 f2 87 ab eb 44 06 6f 4d 6d d8
6d eb b3 22 68 37 7b 8b cc f5 18 5b 39 1b 8d 07
da 7f 53 a6 99 7e 78 56 64 ad 5c c4 94 a7 d3 3e
a4 c9 d2 37 c6 3c 73 49 60 54 ea 40 ef 41 ff 32
d7 77 6b ab b9 0b bd f7 72 50 fc ca 7a 26 34 43
99 79 60 5f ec 32 3c 0b 51 64 cb 02 03 01 00 01
a3 2a 30 28 30 26 06 03 55 1d 11 04 1f 30 1d a0
1b 06 08 2b 06 01 05 05 07 08 05 a0 0f 0c 0d 2a
2e 31 30 2e 39 30 2e 36 2e 31 34 30 30 0d 06 09
2a 86 48 86 f7 0d 01 01 05 05 00 03 82 01 01 00
70 fe fb a5 9e 0c 6f 51 4c 4e b9 e9 fa 4f 75 b6
ec da 25 c7 e5 c0 13 6e 99 0a 08 67 f9 e1 48 dd
19 62 7d 94 eb 86 bd 41 6d c8 ae e6 06 1b 98 44
77 b6 8c 1a d8 6d bc b0 ee e8 2b bf a8 99 10 2a
ce cc e3 81 ee 0f 7a 41 f6 27 3c c8 9a b9 32 0c
48 7d 33 09 ce af b2 5a 13 01 d0 a7 b4 f9 80 96
20 8b 87 95 cc 67 78 b6 e5 68 6a e5 27 7c 15 39
15 54 b3 82 9e b0 27 c4 fe 72 9e 6b e2 c7 54 5e
41 b3 f6 dc 00 ff 7d 1a 3d 82 cd 8c fc b3 96 8f
f1 f3 46 5e 8d 62 33 3f c2 ab 78 66 b9 00 51 88
ee 0a 2b 99 95 46 9d 4b e8 94 fe f8 e2 39 88 0e
57 30 b0 31 93 89 ed c8 08 05 2e 76 08 92 99 3a
10 40 79 70 b3 e7 70 a3 c6 c4 af 06 60 81 60 64
2f 5b 09 99 f0 d2 fa c0 17 5f ac 85 d5 04 38 e1
6f 8b 7f 97 1f 0d 90 57 e5 df bd 2d 31 f3 55 85
86 d2 6b b0 3a 29 4e 18 e5 b6 a4 b8 3d 5a 0c 7b
0e 00 00 00


TLS GNUTLS: tls_push: 267 bytes

16 03 01 01 06 10 00 01 02 01 00 53 c6 71 b0 a9
e9 9d 5e 73 e6 0a bd 45 e2 88 5b 8b 52 38 d4 4e
6c d4 ef 49 db dd e1 3c 33 65 1b 03 5d 51 36 74
bc d3 7e a8 d2 7b 82 95 4a a4 b8 a3 18 88 4a 5a
68 ac 47 87 3f cd 50 c3 24 c2 43 26 d3 08 06 d1
cd bc 34 c8 bc 67 7d 68 e3 95 b0 51 4c 6e cf 8c
81 6d 48 54 2c 2e 8d 74 1f ac 29 69 c4 8f e7 c6
80 98 7a bb 7b fd 0b 38 10 87 5c 84 23 75 e6 19
0d e2 74 02 17 ff aa b6 81 a8 e7 55 ea e5 b6 ea
87 74 f6 bf 8b 12 4b e4 99 06 3b 06 27 12 e3 16
9a 8b d9 c4 01 ca d2 b3 2f eb 74 11 72 5a 71 9a
a9 80 81 53 bc 12 26 70 17 22 00 da 79 1f 85 f2
16 cf 80 d8 2b d9 8a ba 06 a4 e0 6e f1 9e 93 6f
06 85 65 88 2d 3b 81 e3 3c f2 b4 e5 49 27 9d 67
85 de 89 c4 53 d3 a8 78 b8 15 0d 5f 8f a5 37 c8
92 c2 98 48 17 32 e5 b5 07 25 69 21 6a e8 5a d5
13 9b 26 75 59 a3 33 3e e3 e7 b2

TLS GNUTLS: tls_push: 6 bytes

14 03 01 00 01 01

TLS GNUTLS: tls_push: 45 bytes

16 03 01 00 28 f5 75 44 9f b3 df 21 cf 2f e2 9d
4e 61 b3 b6 4d 0b ca bf 00 42 8d af 0c 37 62 fa
97 58 25 d4 9e e3 e8 a5 cb 12 1d 7d f7

TLS GNUTLS: tls_pull

14 03 01 00 01

TLS GNUTLS: tls_pull

01

TLS GNUTLS: tls_pull

16 03 01 00 28

TLS GNUTLS: tls_pull

09 a7 ef c6 01 2a e8 80 1f 0f 73 30 df 89 44 7f
a8 c6 c2 7c e8 f7 c2 8f f6 9f d7 62 e5 5d e9 e0
47 6c c5 17 e6 3f 8c 58

===> TLS handshake done, send firs message after handshake and waits for
response

TLS GNUTLS: tls_send: [<?xml version='1.0'?><stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'
to='10.90.6.140' version='1.0'>] 137 bytes
TLS GNUTLS: tls_push: 253 bytes

17 03 01 00 f8 d4 75 17 4a 71 d4 1b f7 6e 5d 66
32 61 b6 c6 df a0 de 75 2b b9 74 93 52 8e ba ab
7f 66 a2 d4 5c eb 27 c7 03 ba 20 1a d6 7f d2 e9
03 81 ee e5 59 9a 75 0f df 65 ee 0e de af 2f f5
44 f2 7d 18 e7 4a 56 3c ca 21 4f d0 92 8e 71 7c
d8 29 06 88 b0 d0 b0 54 bc a6 0f 7f c3 4d 79 f4
c9 98 f7 b8 53 f0 7f 67 57 e6 d3 3e 0a 70 53 54
c4 bd 9b 39 b6 d9 9f ad 1f aa f9 a0 e3 82 41 ad
43 06 62 7d c8 14 3c 6c 6f bc 3b 54 ab 8e c6 f8
f4 da a5 ab f2 28 c5 22 8f 08 b9 97 35 d5 11 5e
68 3f 03 26 27 37 ba af e5 36 f5 9a 5e 6b a8 8d
5d 02 45 69 5f 42 90 3e c0 f1 ba 60 e0 d3 1d f8
8e 44 5d a8 00 0c ba 48 3e 42 e4 d3 41 be 57 7a
55 4d 5a 35 65 db b0 b9 1c ff 0c a1 3f ca 8c c4
25 42 26 46 ae a5 aa cc ac c7 43 74 41 26 51 c3
45 44 25 c3 68 48 9d 77 bc df af b2 16

SecSEND[<?xml version='1.0'?><stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'
to='10.90.6.140' version='1.0'>]


===> recieve first message after TLS handshake


TLS GNUTLS: tls_recv
TLS GNUTLS: tls_pull

16 03 01 00 28

TLS GNUTLS: tls_recv: ret: -9 <== GNUTLS_E_UNEXPECTED_PACKET_LENGTH /*
GNUTLS_A_RECORD_OVERFLOW */


Best regards,
   -vitali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120511/56592508/attachment.htm>

From nmav at gnutls.org  Sat May 12 10:02:05 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 May 2012 10:02:05 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>
Message-ID: <4FAE18FD.6050704@gnutls.org>

On 05/11/2012 01:14 PM, Thorsten Glaser wrote:


>>  What do you mean by the usual debugging output?
> These lines from the gnutls output on Debian:
> - Certificate[1] info:
> For example.


You can use --print-certs to get the certificates.


regards,
Nikos



From nmav at gnutls.org  Sat May 12 10:05:13 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 May 2012 10:05:13 +0200
Subject: Receiving forst message after succcessfull TLS negotiation failed
In-Reply-To: <1858476268.72338.1336742818355.JavaMail.open-xchange@com4.strato.de>
References: <1858476268.72338.1336742818355.JavaMail.open-xchange@com4.strato.de>
Message-ID: <4FAE19B9.3050703@gnutls.org>

On 05/11/2012 03:26 PM, Vitali Schauermann wrote:

> Hello,
> 
> 
> i am using a XMPP library (iksemel) with GnuTLS support for communication with a
> XMPP server (GoogleTalk or Openfire).
> 
> The TLS negotiation (handshake) is performed without errors, but the firs read
> request fails with following error code:
> 
> GNUTLS_E_UNEXPECTED_PACKET_LENGTH /* GNUTLS_A_RECORD_OVERFLOW */
> Obviously, this as some kind of error, which is not ambiguous and points to some
> deeper problem,
> the question is, it is possible to "enable" some debuging information for gather
> the really problem ?


Yes, it is in the manual in the debugging section.
http://www.gnu.org/software/gnutls/documentation.html

Another ways to debug is by using packet capture of wireshark, or
reproducing the issue using gnutls-cli.

regards,
Nikos





From t.glaser at tarent.de  Mon May 14 10:20:57 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 14 May 2012 10:20:57 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FAE18FD.6050704@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>
	<4FAE18FD.6050704@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205141020001.5897@tglase.lan.tarent.de>

On Sat, 12 May 2012, Nikos Mavrogiannopoulos wrote:

> You can use --print-certs to get the certificates.

This doesn?t work either:

# gnutls-cli --print-cert -p 636 --x509cafile /etc/ssl/certs/ca-c* dc.lan.tarent.de    
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

I think it may misparse the certificates or something.
Do you think I?d better raise this with Ubuntu? I had
looked here first because it seems way more active and
responsive?

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From branko at majic.rs  Mon May 14 13:21:31 2012
From: branko at majic.rs (=?UTF-8?B?0JHRgNCw0L3QutC+INCc0LDRmNC40Zs=?=)
Date: Mon, 14 May 2012 13:21:31 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205141020001.5897@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>
	<4FAE18FD.6050704@gnutls.org>
	<alpine.DEB.2.02.1205141020001.5897@tglase.lan.tarent.de>
Message-ID: <20120514132131.4e97171e@majic.rs>

If I were you, I'd try to download the source of the Ubuntu package and
check the patches, possibly rebuilding the relevant packages by hand
without those patches. You may find this guide helpful:

http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/

Iirc, all you need is to remove the patch files from patches directory
of some sorts.

What happens if you tell gnutls-cli to ignore check of certificates?
Does it fail in the same way (i.e. just curious if the actual
establishing of connections works ok)?

I know that, for example, between upgrade Lenny from Squeeze the slapd
server would no longer be able to read a PKCS#8 PEM-encoded private key
(a bit unrelated, but a small note).

Best regards

???? Mon, 14 May 2012 10:20:57 +0200 (CEST)
Thorsten Glaser <t.glaser at tarent.de> ??????:

> On Sat, 12 May 2012, Nikos Mavrogiannopoulos wrote:
> 
> > You can use --print-certs to get the certificates.
> 
> This doesn?t work either:
> 
> # gnutls-cli --print-cert -p 636 --x509cafile /etc/ssl/certs/ca-c*
> dc.lan.tarent.de Processed 407 CA certificate(s).
> Resolving 'dc.lan.tarent.de'...
> Connecting to '172.26.100.1:636'...
> *** Verifying server certificate failed...
> *** Fatal error: Error in the certificate.
> *** Handshake has failed
> GnuTLS error: Error in the certificate.
> 
> I think it may misparse the certificates or something.
> Do you think I?d better raise this with Ubuntu? I had
> looked here first because it seems way more active and
> responsive?
> 
> bye,
> //mirabilos


-- 
Branko Majic
Jabber: branko at majic.rs
Please use only Free formats when sending attachments to me.

?????? ?????
?????: branko at majic.rs
????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: </pipermail/attachments/20120514/fcd8d476/attachment.pgp>

From t.glaser at tarent.de  Mon May 14 14:31:03 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 14 May 2012 14:31:03 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <20120514132131.4e97171e@majic.rs>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205111310150.16441@tglase.lan.tarent.de>
	<4FAE18FD.6050704@gnutls.org>
	<alpine.DEB.2.02.1205141020001.5897@tglase.lan.tarent.de>
	<20120514132131.4e97171e@majic.rs>
Message-ID: <alpine.DEB.2.02.1205141425380.5897@tglase.lan.tarent.de>

On Mon, 14 May 2012, ?????? ????? wrote:

> If I were you, I'd try to download the source of the Ubuntu package and
> check the patches, possibly rebuilding the relevant packages by hand

Yeah, I was trying to avoid having to dig in the sources myself,
as I?ve got quite a lot on my hands already. It?s even for a
coworker, as I disagree with them using *buntu anyway.

> without those patches. You may find this guide helpful:
> 
> http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/

Maybe, if I were not a Debian Developer already ;-)

> What happens if you tell gnutls-cli to ignore check of certificates?
> Does it fail in the same way (i.e. just curious if the actual
> establishing of connections works ok)?

Ah, _there_?s the output I was looking for. Yes, it works,
but it does too when I disable CA checking in OpenLDAP.
Which is not quite the point though.

# gnutls-cli --insecure -p 636 dc.lan.tarent.de                                        
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject =DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=dc.lan.tarent.de,EMAIL=admins at tarent.de', issuer =DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de', RSA key 1024 bits, signed using RSA-SHA1, activated ?1-02-07 10:24:29 UTC', expires ?6-02-06 10:24:29 UTC', SHA-1 fingerprint 11f5038e915c4cdf36743bc39b62ff60be8fdbf'
 - Certificate[1] info:
  - subject =DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de', issuer =DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de', RSA key 2048 bits, signed using RSA-SHA1, activated ?1-02-07 10:24:29 UTC', expires ?3-02-06 10:24:29 UTC', SHA-1 fingerprint a9e3f7bcea0df189a7f599599bc253517a57fc'
- The hostname in the certificate matches 'dc.lan.tarent.de'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

^C


?????
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From psalters at gmail.com  Tue May 15 09:54:13 2012
From: psalters at gmail.com (Paul Salters)
Date: Tue, 15 May 2012 09:54:13 +0200
Subject: Problem with libgcrypt maybe because of libgnutls
Message-ID: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>

Dear mailinglist members,

I have an problem with my application. My application is using the
xmlrpc-c library (http://xmlrpc-c.sourceforge.net/) that library is
using the curl library which is using the gnutls library which is
using libgcrypt. (So far so good?)

My application is multi-threaded most of the time it runs fine but
sometimes i get the following error message: ""ath.c:193:
_gcry_ath_mutex_lock: Assertion '*lock == ((ath_mutex_t) 0)' failed".
Of course I have checked if the different library's are thread safe.
All claim to be thread safe. Also i have asked the xmlrpc-c developer
if he saw this problem before. But unfortunately he did not see this
problem before. I have searched Google and it looks like it's a
problem with libgcrypt. This error message can be found at curl
mailinglists and other mailinglists but that is from an few years ago.
So maybe this is an other problem?

I have posted the same question at the curl mailinglist but I think it
has maybe something to do with the libgnutls version in combination
with the libgcrypt version. But I am not that experienced c(++)
developer (in fact I am a student). So I hope you can point me in the
right direction.

I am using Debian stable as my OS. Which has the following versions installed.

xmlrpc-c: 1.25.15
libcurl4-gnutls-dev: 7.21.0-2.1+squeeze2
libgnutls-dev: 2.8.6-1+squeeze2
libgcrypt11-dev (1.4.5-2)

In advance I would like you to thank you for your help and time!

Yours sincerely,

Paul Salters
The Netherlands



From nmav at gnutls.org  Wed May 16 11:18:51 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 16 May 2012 11:18:51 +0200
Subject: Problem with libgcrypt maybe because of libgnutls
In-Reply-To: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>
References: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>
Message-ID: <CAJU7za+VkzY9isnHa04VdmrjgcbKfjwAeuUruUUGooO4101BWA@mail.gmail.com>

On Tue, May 15, 2012 at 9:54 AM, Paul Salters <psalters at gmail.com> wrote:
> Dear mailinglist members,
>
> I have an problem with my application. My application is using the
> xmlrpc-c library (http://xmlrpc-c.sourceforge.net/) that library is
> using the curl library which is using the gnutls library which is
> using libgcrypt. (So far so good?)

Hello,
 Libgcrypt requires mutex locks to be setup by the end application. I
don't know if curl does it already for you, but if it doesn't you
should set them up.
If you use gnutls 2.12.0 or later you need not to perform any of these
actions because the system mutexes are used by default.

regards,
Nikos



From nmav at gnutls.org  Wed May 16 11:44:29 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 16 May 2012 11:44:29 +0200
Subject: Problem with libgcrypt maybe because of libgnutls
In-Reply-To: <CAATOPO8qFkjZLmvgH9MwBKDwhqwsOVXf3xPfuvNVPc2bGfF8+g@mail.gmail.com>
References: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>
	<CAJU7za+VkzY9isnHa04VdmrjgcbKfjwAeuUruUUGooO4101BWA@mail.gmail.com>
	<CAATOPO8qFkjZLmvgH9MwBKDwhqwsOVXf3xPfuvNVPc2bGfF8+g@mail.gmail.com>
Message-ID: <CAJU7za+32xWf_dfbRmYRuJAs2dwhcMUSPm0pokb4c_+t67FCGQ@mail.gmail.com>

On Wed, May 16, 2012 at 11:33 AM, Paul Salters <psalters at gmail.com> wrote:

> Thank you for answer!
> I have add the following lines of code to my application.
> GCRY_THREAD_OPTION_PTHREAD_IMPL;
> gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
> gnutls_global_init();
> But the error still remains.

In that case you may have to debug the issue further and see why the
locks were not initialized and discuss with the libgcrypt guys. We
have dropped support of libgcrypt in our new releases, so what I can
do is to suggest that you use gnutls 2.12.x or even 3.0.x that do not
have such requirements.

regards,
Nikos



From psalters at gmail.com  Wed May 16 11:33:15 2012
From: psalters at gmail.com (Paul Salters)
Date: Wed, 16 May 2012 11:33:15 +0200
Subject: Problem with libgcrypt maybe because of libgnutls
In-Reply-To: <CAJU7za+VkzY9isnHa04VdmrjgcbKfjwAeuUruUUGooO4101BWA@mail.gmail.com>
References: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>
	<CAJU7za+VkzY9isnHa04VdmrjgcbKfjwAeuUruUUGooO4101BWA@mail.gmail.com>
Message-ID: <CAATOPO8qFkjZLmvgH9MwBKDwhqwsOVXf3xPfuvNVPc2bGfF8+g@mail.gmail.com>

On 16 May 2012 11:18, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, May 15, 2012 at 9:54 AM, Paul Salters <psalters at gmail.com> wrote:
>> Dear mailinglist members,
>>
>> I have an problem with my application. My application is using the
>> xmlrpc-c library (http://xmlrpc-c.sourceforge.net/) that library is
>> using the curl library which is using the gnutls library which is
>> using libgcrypt. (So far so good?)
>
> Hello,
> ?Libgcrypt requires mutex locks to be setup by the end application. I
> don't know if curl does it already for you, but if it doesn't you
> should set them up.
> If you use gnutls 2.12.0 or later you need not to perform any of these
> actions because the system mutexes are used by default.
>
> regards,
> Nikos

Thank you for answer!

I have add the following lines of code to my application.

GCRY_THREAD_OPTION_PTHREAD_IMPL;
gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
gnutls_global_init();

But the error still remains.

Regards,

Paul Salters



From psalters at gmail.com  Wed May 16 11:48:52 2012
From: psalters at gmail.com (Paul Salters)
Date: Wed, 16 May 2012 11:48:52 +0200
Subject: Problem with libgcrypt maybe because of libgnutls
In-Reply-To: <CAJU7za+32xWf_dfbRmYRuJAs2dwhcMUSPm0pokb4c_+t67FCGQ@mail.gmail.com>
References: <CAATOPO9q1QWmw_yiuoJ32GaYdGn9WG_d4QTo1P1LYs2F59Tvpw@mail.gmail.com>
	<CAJU7za+VkzY9isnHa04VdmrjgcbKfjwAeuUruUUGooO4101BWA@mail.gmail.com>
	<CAATOPO8qFkjZLmvgH9MwBKDwhqwsOVXf3xPfuvNVPc2bGfF8+g@mail.gmail.com>
	<CAJU7za+32xWf_dfbRmYRuJAs2dwhcMUSPm0pokb4c_+t67FCGQ@mail.gmail.com>
Message-ID: <CAATOPO-9O4FZD=s-18vYduMfnDd3BVECnssdwr_6872a28G3UA@mail.gmail.com>

On 16 May 2012 11:44, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> In that case you may have to debug the issue further and see why the
> locks were not initialized and discuss with the libgcrypt guys. We
> have dropped support of libgcrypt in our new releases, so what I can
> do is to suggest that you use gnutls 2.12.x or even 3.0.x that do not
> have such requirements.
>
> regards,
> Nikos

Ok. I have posted the message on the libgcrypt mailinglist. Nice to
hear that I am not doing anything wrong :) I have tested my
application with newer versions of your lib. And that works indeed
perfectly.  But I would like to use this version because I am using
Debian stable.

Thank you for your help!

Regards,

Paul Salters



From code at funwithsoftware.org  Sun May 20 10:00:09 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Sun, 20 May 2012 01:00:09 -0700
Subject: issues building gnutls from git on Ubuntu 12.04
Message-ID: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>

On Ubuntu 12.04, I'm attempting to build gnutls from git.  I'm on the  
head of the gnutls "master" branch, and "git status" shows I have no  
files modified, and yet when I do "make bootstrap", autopoint  
complains that I have modified files:

ppelletier at patrick64:~/src/gnutls$ make bootstrap
for f in po/*.po.in; do \
		cp $f `echo $f | sed 's/.in//'`; \
	done
mv build-aux/config.rpath build-aux/config.rpath-
autopoint
autopoint: File ABOUT-NLS has been locally modified.
autopoint: File po/Makefile.in.in has been locally modified.
autopoint: File po/Rules-quot has been locally modified.
autopoint: *** Some files have been locally modified. Not overwriting  
them because --force has not been specified. For your convenience, you  
find the local modifications in the file '/tmp/gtuXtRkI/autopoint.diff'.
autopoint: *** Stop.
make: *** [autoreconf] Error 1
ppelletier at patrick64:~/src/gnutls$

 From the message, it sounds like perhaps I should specify "--force",  
so I edited the line in cfg.mk that invokes autopoint to invoke it  
with "--force".  This seems to fix the problem, although I'm curious  
if this is something I should have to do, or if it indicates some  
deeper problem.

Anyway, with this change, the "make bootstrap" gets much further, but  
eventually fails with:

configure: creating ./config.status
config.status: error: cannot find input file: src/libopts/Makefile.in
make: *** [bootstrap] Error 1

And I'm not sure what to do about that one.  Here are the versions of  
various things that I have installed, although they should just be the  
standard versions that come with Ubuntu 12.04:

ppelletier at patrick64:~/src/gnutls$ autoconf --version
autoconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html 
 >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
ppelletier at patrick64:~/src/gnutls$ autopoint --version
/usr/bin/autopoint (GNU gettext-tools) 0.18.1
Uses a versions archive in git format.
Copyright (C) 2002-2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html 
 >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible
ppelletier at patrick64:~/src/gnutls$ automake --version
automake (GNU automake) 1.11.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html 
 >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey at redhat.com>
        and Alexandre Duret-Lutz <adl at gnu.org>.
ppelletier at patrick64:~/src/gnutls$ autogen --version
autogen (GNU AutoGen) 5.12
ppelletier at patrick64:~/src/gnutls$

Thanks for any advice!

--Patrick




From help-gnutls-phil at spodhuis.org  Sun May 20 12:40:45 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 20 May 2012 06:40:45 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120520101648.GA31383@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
Message-ID: <20120520104045.GA31858@redoubt.spodhuis.org>

On 2012-05-20 at 06:16 -0400, Phil Pennock wrote:
> Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
> GnuTLS dropping connection after reporting receiving a phantom packet.

I am sorry.

Correction: there is no phantom packet.  GnuTLS returns the
"GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9    /* GNUTLS_A_RECORD_OVERFLOW */"
error code when there is an EOF because of abrupt client disconnect.

So much of my analysis is bonkers, but there's still an issue.  NSS
*can* set up a client connection to GnuTLS 2.8 but not 2.12,
disconnecting after receiving server_hello_done.

Any help / guidance appreciated.

Thanks,
-Phil



From help-gnutls-phil at spodhuis.org  Sun May 20 12:16:48 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 20 May 2012 06:16:48 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
Message-ID: <20120520101648.GA31383@redoubt.spodhuis.org>

Folks,

Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
GnuTLS dropping connection after reporting receiving a phantom packet.

Long:

For the Exim 4.80 release, currently in Release Candidate, I re-did the
GnuTLS integration to stop using APIs which gave deprecation warnings.
As part of this, I removed the hard-coded lists of algorithms from Exim,
instead delegating that task to GnuTLS, and passing the Exim
tls_require_ciphers string to gnutls_priority_init().

Things had been going well in the Release Candidates, but we now have a
release blocker.  It seems that Thunderbird (NSS security library) can
not set up a TLS session with GnuTLS 2.12.18.  (I saw the .19
announcement, to me it doesn't look as though there's anything
relevant?)

Bug in 2.12.14 and 2.12.18, seen by two people (myself one of them); but
not in 2.8.5.  No problems observed with OpenSSL or GnuTLS clients, just
NSS.

Mail thread starts at:
  https://lists.exim.org/lurker/message/20120520.040118.edd7eecb.en.html
overview:
  https://lists.exim.org/lurker/thread/20120520.040118.edd7eecb.en.html#i20120520.040118.edd7eecb
Protocol dump in my mail:
  https://lists.exim.org/lurker/message/20120520.092423.0e38168b.en.html

It looks as though GnuTLS is claiming to have received a packet of
length 9, which ssltap does not see.  Could this be unconsumed data from
a previous packet?

Per ssltap, "openssl s_client" sent extensions:
  ec_point_formats
  elliptic_curves
  session_ticket
  signature_algorithms
  type 15
while Thunderbird sent extensions:
  server_name
  elliptic_curves
  ec_point_formats
  session_ticket

It's not server_name, we handle that just fine (and can now do SNI
dispatch for key/cert selection).  I see elliptic_curves and
ec_point_formats sent by both, so my "wild uneducated guess" was
probably wrong.

[source availability notes below]

Thanks for any help you can provide,
-Phil

On the off-chance that any GnuTLS devs run Exim themselves, I'll point
to our source; I don't expect you to debug our code, but I don't think
I'm being too arrogant in thinking someone may already be running Exim,
so I can point you at it to let you build yourselves to see the debug
messages.

You can add EXIM_GNUTLS_LIBRARY_LOG_LEVEL= to Local/Makefile with a
value accepted by gnutls_global_set_log_level() to have a callback
registered with gnutls_global_set_log_function(); "exim -d+tls" asks for
the TLS-specific debug messages, and the GnuTLS library messages will be
included.  My test builds just set "EXIM_GNUTLS_LIBRARY_LOG_LEVEL=9".

  4.80 RC2 announcement:
   https://lists.exim.org/lurker/message/20120519.075037.21283114.en.html
  git source:
    git://git.exim.org/exim.git
    The root of the distribution tarball is one-level deep inside git,
    in "src", so we do have src/src :( but if you "cd src" then you can
    create "Local/" inside there and proceed as per a normal release.




From nmav at gnutls.org  Sun May 20 16:24:53 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 20 May 2012 16:24:53 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120520101648.GA31383@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
Message-ID: <CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>

Hello,
 From what I can tell it is the client for some reason terminates the
connection. What is the output on the client? Do you have a tcpdump of
the issue? Have you tried alternative priority strings than normal
[0]?

[0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

regards,
Nikos

On Sun, May 20, 2012 at 12:16 PM, Phil Pennock
<help-gnutls-phil at spodhuis.org> wrote:
> Folks,
>
> Short: NSS client to GnuTLS 2.12 (but not 2.8) fails TLS negotiation,
> GnuTLS dropping connection after reporting receiving a phantom packet.
>
> Long:
>
> For the Exim 4.80 release, currently in Release Candidate, I re-did the
> GnuTLS integration to stop using APIs which gave deprecation warnings.
> As part of this, I removed the hard-coded lists of algorithms from Exim,
> instead delegating that task to GnuTLS, and passing the Exim
> tls_require_ciphers string to gnutls_priority_init().
>
> Things had been going well in the Release Candidates, but we now have a
> release blocker. ?It seems that Thunderbird (NSS security library) can
> not set up a TLS session with GnuTLS 2.12.18. ?(I saw the .19
> announcement, to me it doesn't look as though there's anything
> relevant?)
>
> Bug in 2.12.14 and 2.12.18, seen by two people (myself one of them); but
> not in 2.8.5. ?No problems observed with OpenSSL or GnuTLS clients, just
> NSS.
>
> Mail thread starts at:
> ?https://lists.exim.org/lurker/message/20120520.040118.edd7eecb.en.html
> overview:
> ?https://lists.exim.org/lurker/thread/20120520.040118.edd7eecb.en.html#i20120520.040118.edd7eecb
> Protocol dump in my mail:
> ?https://lists.exim.org/lurker/message/20120520.092423.0e38168b.en.html
>
> It looks as though GnuTLS is claiming to have received a packet of
> length 9, which ssltap does not see. ?Could this be unconsumed data from
> a previous packet?
>
> Per ssltap, "openssl s_client" sent extensions:
> ?ec_point_formats
> ?elliptic_curves
> ?session_ticket
> ?signature_algorithms
> ?type 15
> while Thunderbird sent extensions:
> ?server_name
> ?elliptic_curves
> ?ec_point_formats
> ?session_ticket
>
> It's not server_name, we handle that just fine (and can now do SNI
> dispatch for key/cert selection). ?I see elliptic_curves and
> ec_point_formats sent by both, so my "wild uneducated guess" was
> probably wrong.
>
> [source availability notes below]
>
> Thanks for any help you can provide,
> -Phil
>
> On the off-chance that any GnuTLS devs run Exim themselves, I'll point
> to our source; I don't expect you to debug our code, but I don't think
> I'm being too arrogant in thinking someone may already be running Exim,
> so I can point you at it to let you build yourselves to see the debug
> messages.
>
> You can add EXIM_GNUTLS_LIBRARY_LOG_LEVEL= to Local/Makefile with a
> value accepted by gnutls_global_set_log_level() to have a callback
> registered with gnutls_global_set_log_function(); "exim -d+tls" asks for
> the TLS-specific debug messages, and the GnuTLS library messages will be
> included. ?My test builds just set "EXIM_GNUTLS_LIBRARY_LOG_LEVEL=9".
>
> ?4.80 RC2 announcement:
> ? https://lists.exim.org/lurker/message/20120519.075037.21283114.en.html
> ?git source:
> ? ?git://git.exim.org/exim.git
> ? ?The root of the distribution tarball is one-level deep inside git,
> ? ?in "src", so we do have src/src :( but if you "cd src" then you can
> ? ?create "Local/" inside there and proceed as per a normal release.
>
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnutls



From nmav at gnutls.org  Sun May 20 16:34:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 20 May 2012 16:34:58 +0200
Subject: issues building gnutls from git on Ubuntu 12.04
In-Reply-To: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>
References: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>
Message-ID: <CAJU7zaLOZhF0w+UyvUPHBDMcznsyUjaYy1m-k2_DcBQ83eDVaA@mail.gmail.com>

On Sun, May 20, 2012 at 10:00 AM, Patrick Pelletier
<code at funwithsoftware.org> wrote:
> On Ubuntu 12.04, I'm attempting to build gnutls from git. ?I'm on the head
> of the gnutls "master" branch, and "git status" shows I have no files
> modified, and yet when I do "make bootstrap", autopoint complains that I
> have modified files:
>
> ppelletier at patrick64:~/src/gnutls$ make bootstrap
> for f in po/*.po.in; do \
> ? ? ? ? ? ? ? ?cp $f `echo $f | sed 's/.in//'`; \
> ? ? ? ?done
> mv build-aux/config.rpath build-aux/config.rpath-
> autopoint
> autopoint: File ABOUT-NLS has been locally modified.
> autopoint: File po/Makefile.in.in has been locally modified.
> autopoint: File po/Rules-quot has been locally modified.
> autopoint: *** Some files have been locally modified. Not overwriting them
> because --force has not been specified. For your convenience, you find the
> local modifications in the file '/tmp/gtuXtRkI/autopoint.diff'.
> autopoint: *** Stop.

That's strange because ABOUT-NLS isn't included in the repository. Are
you sure there wasn't a stray one from a previous checkout? (it is
being ignored as file so git status wouldn't show anything).

> Anyway, with this change, the "make bootstrap" gets much further, but
> eventually fails with:
> configure: creating ./config.status
> config.status: error: cannot find input file: src/libopts/Makefile.in
> make: *** [bootstrap] Error 1

If you run "autoreconf -fvi" does it fix the issue? make bootstrap may
be fine for the first bootstrap but after than autoreconf -fvi should
do.

regards,
Nikos



From code at funwithsoftware.org  Sun May 20 17:37:34 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Sun, 20 May 2012 08:37:34 -0700
Subject: issues building gnutls from git on Ubuntu 12.04
In-Reply-To: <CAJU7zaLOZhF0w+UyvUPHBDMcznsyUjaYy1m-k2_DcBQ83eDVaA@mail.gmail.com>
References: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>
	<CAJU7zaLOZhF0w+UyvUPHBDMcznsyUjaYy1m-k2_DcBQ83eDVaA@mail.gmail.com>
Message-ID: <BC478D79-FEA4-40DA-B0CA-96C13961C28C@funwithsoftware.org>

Thanks!  I did a "git clean -dfx" and that solved both of my previous  
problems.

I'd been so focused on the output of "git status" that I'd forgotten  
to consider that my checkout could be "dirty" in files that were being  
gitignored.  (I'd previously tried building gnutls in that same  
directory before I upgraded to Ubuntu 12.04, so that must be where the  
dirty files came from.  I just hadn't thought about that.)

Sorry for not figuring out such a basic issue on my own!

I'm now getting all the way through the "make bootstrap", and most of  
the way through "make", but it fails on the "compare-makefile" rule.   
Does that mean I'm still doing something wrong, or is this to be  
expected since I just grabbed the head of git, rather than using an  
official release?  (I'm not entirely clear what this step is doing,  
but perhaps these "FUNCS" lines are only updated before a release, and  
that's why they mismatch for me?)

--Patrick


Creating documentation for ../lib/includes/gnutls/ocsp.h... ok
mv -f enums.texi-tmp enums.texi
ENUMS=`grep '^@c ' enums.texi | sed 's/@c //g' | sort`; \
	STR=""; \
	for i in $ENUMS; do \
		STR="$STR\nENUMS += enums/$i"; \
	done; \
	grep -v -e '^ENUMS += ' ./Makefile.am | \
		perl -p -e "s,^ENUMS =,ENUMS =$STR," > tmp-compare-makefile; \
	diff -u ./Makefile.am tmp-compare-makefile
rm -f tmp-compare-makefile
FUNCS=`cat ../lib/includes/gnutls/*.h | ../doc/scripts/getfuncs.pl`; \
	MANS=""; \
	for i in $FUNCS; do \
		MANS="$MANS\nFUNCS += functions/$i"; \
	done; \
	grep -v -e '^FUNCS += ' Makefile.am | \
		perl -p -e "s,^FUNCS =,FUNCS =$MANS," > tmp-compare-makefile; \
	diff -u ./Makefile.am tmp-compare-makefile
--- ./Makefile.am	2012-05-19 23:10:37.000000000 -0700
+++ tmp-compare-makefile	2012-05-20 08:10:15.000000000 -0700
@@ -503,7 +503,6 @@
  FUNCS += functions/gnutls_x509_crt_set_pubkey
  FUNCS += functions/gnutls_x509_crq_set_pubkey
  FUNCS += functions/gnutls_pubkey_verify_hash
-FUNCS += functions/gnutls_pubkey_verify_hash2
  FUNCS += functions/gnutls_pubkey_get_verify_algorithm
  FUNCS += functions/gnutls_pubkey_verify_data
  FUNCS += functions/gnutls_pubkey_verify_data2
@@ -622,7 +621,6 @@
  FUNCS += functions/gnutls_certificate_type_get_name
  FUNCS += functions/gnutls_pk_get_name
  FUNCS += functions/gnutls_sign_get_name
-FUNCS += functions/gnutls_pk_to_sign
  FUNCS += functions/gnutls_mac_get_id
  FUNCS += functions/gnutls_compression_get_id
  FUNCS += functions/gnutls_cipher_get_id
make[5]: *** [compare-makefile] Error 1
make[5]: Leaving directory `/home/ppelletier/src/gnutls/doc'
make[4]: *** [stamp_functions] Error 2
make[4]: Leaving directory `/home/ppelletier/src/gnutls/doc'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/ppelletier/src/gnutls/doc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/ppelletier/src/gnutls/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ppelletier/src/gnutls'
make: *** [all] Error 2


On May 20, 2012, at 7:34 AM, Nikos Mavrogiannopoulos wrote:

> On Sun, May 20, 2012 at 10:00 AM, Patrick Pelletier
> <code at funwithsoftware.org> wrote:
>> On Ubuntu 12.04, I'm attempting to build gnutls from git.  I'm on  
>> the head
>> of the gnutls "master" branch, and "git status" shows I have no files
>> modified, and yet when I do "make bootstrap", autopoint complains  
>> that I
>> have modified files:
>>
>> ppelletier at patrick64:~/src/gnutls$ make bootstrap
>> for f in po/*.po.in; do \
>>                cp $f `echo $f | sed 's/.in//'`; \
>>        done
>> mv build-aux/config.rpath build-aux/config.rpath-
>> autopoint
>> autopoint: File ABOUT-NLS has been locally modified.
>> autopoint: File po/Makefile.in.in has been locally modified.
>> autopoint: File po/Rules-quot has been locally modified.
>> autopoint: *** Some files have been locally modified. Not  
>> overwriting them
>> because --force has not been specified. For your convenience, you  
>> find the
>> local modifications in the file '/tmp/gtuXtRkI/autopoint.diff'.
>> autopoint: *** Stop.
>
> That's strange because ABOUT-NLS isn't included in the repository. Are
> you sure there wasn't a stray one from a previous checkout? (it is
> being ignored as file so git status wouldn't show anything).
>
>> Anyway, with this change, the "make bootstrap" gets much further, but
>> eventually fails with:
>> configure: creating ./config.status
>> config.status: error: cannot find input file: src/libopts/Makefile.in
>> make: *** [bootstrap] Error 1
>
> If you run "autoreconf -fvi" does it fix the issue? make bootstrap may
> be fine for the first bootstrap but after than autoreconf -fvi should
> do.
>
> regards,
> Nikos
>




From help-gnutls-phil at spodhuis.org  Mon May 21 01:02:34 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 20 May 2012 19:02:34 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
Message-ID: <20120520230234.GA37647@redoubt.spodhuis.org>

On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>  From what I can tell it is the client for some reason terminates the
> connection. What is the output on the client? Do you have a tcpdump of
> the issue? Have you tried alternative priority strings than normal
> [0]?

The client is using NSS and from what I can tell does not log problems
at the NSS level.  I've searched for ways to do that but failed.  The
protocol dump email I referenced in the first post includes the output
from ssltap; is that sufficient or do you want a raw packet capture?

> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

Well, I need to add a new test to the test suite, since I had omitted an
assignment and the default of NORMAL was always being used.

NORMAL:%COMPAT does not help.
NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT does not help.

NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128:%COMPAT
*does* work.

With just "NORMAL:-CIPHER-ALL:+ARCFOUR-128" negotiation works and the
negotiated protocol is TLS1.0:RSA_ARCFOUR_MD5:128.  So it's not %COMPAT
that causes issues.

"AEAD" isn't recognised in 2.12.  Looking at the .texi I see that 2.12
supports: AES-128-CBC, AES-256-CBC, CAMELLIA-128-CBC, CAMELLIA-256-CBC,
ARCFOUR-128, 3DES-CBC ARCFOUR-40.

Incrementally adding each of the items listed below in turn, I needed:
  NORMAL:-AES-256-CBC:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-AES-128-CBC
go get Thunderbird negotiating.

NORMAL:-AES-128-CBC:-AES-256-CBC is *not* sufficient.
NORMAL:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC is *not* sufficient.

strings(1) on libnss3.dylib shipped with Thunderbird (MacOS) suggests
that it is 3.13.3.0 which is far more recent than anything listed on
<http://www.mozilla.org/projects/security/pki/nss/>.

However, Exim supports both OpenSSL and GnuTLS.  If I use an OpenSSL
Exim, then Thunderbird successfully delivers using
TLSv1:CAMELLIA256-SHA:256.

So it's not Camellia in itself that's the problem.  It's those ciphers
as offered by GnuTLS, as opposed to OpenSSL.

-Phil



From help-gnutls-phil at spodhuis.org  Mon May 21 01:17:04 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 20 May 2012 19:17:04 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
Message-ID: <20120520231704.GA39185@redoubt.spodhuis.org>

On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>  From what I can tell it is the client for some reason terminates the
> connection. What is the output on the client? Do you have a tcpdump of
> the issue? Have you tried alternative priority strings than normal
> [0]?
> 
> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html

Janne Snabb has done better detective work than I and found that NSS has
a hard-coded clamp on the number of DH bits used for ephemeral D-H and
GnuTLS's return value from gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH,
GNUTLS_SEC_PARAM_NORMAL) is over that limit.

I'll add a clamp option to Exim and default it to the current NSS limit.

Thanks,
-Phil



From nmav at gnutls.org  Mon May 21 11:41:14 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 May 2012 11:41:14 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120520231704.GA39185@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
Message-ID: <CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>

On Mon, May 21, 2012 at 1:17 AM, Phil Pennock
<help-gnutls-phil at spodhuis.org> wrote:
> On 2012-05-20 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
>> ?From what I can tell it is the client for some reason terminates the
>> connection. What is the output on the client? Do you have a tcpdump of
>> the issue? Have you tried alternative priority strings than normal
>> [0]?
>>
>> [0]. http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
> Janne Snabb has done better detective work than I and found that NSS has
> a hard-coded clamp on the number of DH bits used for ephemeral D-H and
> GnuTLS's return value from gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH,
> GNUTLS_SEC_PARAM_NORMAL) is over that limit.

That's very interesting. Our key sizes is according to recommendations
like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
people?

[0]. http://www.keylength.com/en/3/

regards,
Nikos



From help-gnutls-phil at spodhuis.org  Mon May 21 12:06:34 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Mon, 21 May 2012 06:06:34 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
Message-ID: <20120521100634.GA2616@redoubt.spodhuis.org>

On 2012-05-21 at 11:41 +0200, Nikos Mavrogiannopoulos wrote:
> That's very interesting. Our key sizes is according to recommendations
> like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
> people?
> 
> [0]. http://www.keylength.com/en/3/

NSS limit is 2236 bits.  I haven't reported it yet, been too busy
unblocking release and staying on top of the flood of mails whenever a
release candidate happens.  ;)

I'll dig out the reporting method for GnuTLS now.  Thanks for the
reminder.

-Phil



From help-gnutls-phil at spodhuis.org  Tue May 22 02:51:54 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Mon, 21 May 2012 20:51:54 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120521100634.GA2616@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
Message-ID: <20120522005153.GA13355@redoubt.spodhuis.org>

On 2012-05-21 at 06:06 -0400, Phil Pennock wrote:
> On 2012-05-21 at 11:41 +0200, Nikos Mavrogiannopoulos wrote:
> > That's very interesting. Our key sizes is according to recommendations
> > like ECRYPT [0]. What is the NSS limit? Did you report it to the NSS
> > people?
> > 
> > [0]. http://www.keylength.com/en/3/
> 
> NSS limit is 2236 bits.  I haven't reported it yet, been too busy
> unblocking release and staying on top of the flood of mails whenever a
> release candidate happens.  ;)
> 
> I'll dig out the reporting method for GnuTLS now.  Thanks for the
> reminder.

I must've needed sleep, as I instead got hung up on creating a Savannah
account to file a GnuTLS bug (blocked on account creation).  A little
more rested, I see that Janne Snabb has beaten me to it, commenting on
the existing bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=636802

-Phil



From snabb at epipe.com  Tue May 22 08:48:43 2012
From: snabb at epipe.com (Janne Snabb)
Date: Tue, 22 May 2012 06:48:43 +0000 (UTC)
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120522005153.GA13355@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
Message-ID: <alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>

On Mon, 21 May 2012, Phil Pennock wrote:

> I must've needed sleep, as I instead got hung up on creating a Savannah
> account to file a GnuTLS bug (blocked on account creation).

Maybe you were unconsicously planning to file a bug about the misleading
EOF handling? :) I think we both wasted several hours of debugging time
because of that.

If a new error code can not be introduced due to API compatibility
reasons, the debug output should at least clearly indicate what happened
(instead of "ASSERT: somefunction(): NNN").

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From nmav at gnutls.org  Tue May 22 09:19:30 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 09:19:30 +0200
Subject: issues building gnutls from git on Ubuntu 12.04
In-Reply-To: <BC478D79-FEA4-40DA-B0CA-96C13961C28C@funwithsoftware.org>
References: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>
	<CAJU7zaLOZhF0w+UyvUPHBDMcznsyUjaYy1m-k2_DcBQ83eDVaA@mail.gmail.com>
	<BC478D79-FEA4-40DA-B0CA-96C13961C28C@funwithsoftware.org>
Message-ID: <4FBB3E02.9020303@gnutls.org>

On 05/20/2012 05:37 PM, Patrick Pelletier wrote:


> I'm now getting all the way through the "make bootstrap", and most of
> the way through "make", but it fails on the "compare-makefile" rule. 
> Does that mean I'm still doing something wrong, or is this to be
> expected since I just grabbed the head of git, rather than using an
> official release?  (I'm not entirely clear what this step is doing, but
> perhaps these "FUNCS" lines are only updated before a release, and
> that's why they mismatch for me?)

> -FUNCS += functions/gnutls_pk_to_sign

>  FUNCS += functions/gnutls_mac_get_id


You may ignore that issue. It is because of an incomplete patch. I'm
expecting a commit in nettle in order to fully address it.

regards,
Nikos




From nmav at gnutls.org  Tue May 22 09:47:49 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 09:47:49 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
Message-ID: <CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>

On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <snabb at epipe.com> wrote:
>> I must've needed sleep, as I instead got hung up on creating a Savannah
>> account to file a GnuTLS bug (blocked on account creation).
> Maybe you were unconsicously planning to file a bug about the misleading
> EOF handling? :) I think we both wasted several hours of debugging time
> because of that.
> If a new error code can not be introduced due to API compatibility
> reasons, the debug output should at least clearly indicate what happened
> (instead of "ASSERT: somefunction(): NNN").

Hello,
 I don't really understand what you mean here. Is there an issue in
gnutls we can somehow improve?

regards,
Nikos



From help-gnutls-phil at spodhuis.org  Tue May 22 10:24:27 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Tue, 22 May 2012 04:24:27 -0400
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
Message-ID: <20120522082427.GA79677@redoubt.spodhuis.org>

On 2012-05-22 at 09:47 +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, May 22, 2012 at 8:48 AM, Janne Snabb <snabb at epipe.com> wrote:
> > Maybe you were unconsicously planning to file a bug about the misleading
> > EOF handling? :) I think we both wasted several hours of debugging time
> > because of that.
> > If a new error code can not be introduced due to API compatibility
> > reasons, the debug output should at least clearly indicate what happened
> > (instead of "ASSERT: somefunction(): NNN").
> 
> Hello,
>  I don't really understand what you mean here. Is there an issue in
> gnutls we can somehow improve?

When we were tracking down the NSS interop issue, we were both led a
little astray by one error return.

<gnutls/gnutls.h> says:
  #define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9    /* GNUTLS_A_RECORD_OVERFLOW */

The error message was "A TLS packet with unexpected length was
received."

The problem is that *no* TLS packet was received.  Instead, there was an
EOF condition.  (Okay, sure there's a TCP RST involved, but that's not
TLS).

I spent a bit of time looking for the extra packet, and not seeing it in
ssltap/etc this is what led me to initially wonder if there was stale
data being left behind from a previous packet to GnuTLS.

If it can be accomplished without real interoperability issues, a
separate error code for EOF would really help with diagnosis.

Thanks,
-Phil



From nmav at gnutls.org  Tue May 22 10:28:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 10:28:44 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120522082427.GA79677@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
Message-ID: <CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>

On Tue, May 22, 2012 at 10:24 AM, Phil Pennock
<help-gnutls-phil at spodhuis.org> wrote:

>> Hello,
>> ?I don't really understand what you mean here. Is there an issue in
>> gnutls we can somehow improve?
> When we were tracking down the NSS interop issue, we were both led a
> little astray by one error return.
> <gnutls/gnutls.h> says:
> ?#define GNUTLS_E_UNEXPECTED_PACKET_LENGTH -9 ? ?/* GNUTLS_A_RECORD_OVERFLOW */
>
> The error message was "A TLS packet with unexpected length was
> received."
> The problem is that *no* TLS packet was received. ?Instead, there was an
> EOF condition. ?(Okay, sure there's a TCP RST involved, but that's not
> TLS).
> I spent a bit of time looking for the extra packet, and not seeing it in
> ssltap/etc this is what led me to initially wonder if there was stale
> data being left behind from a previous packet to GnuTLS.
> If it can be accomplished without real interoperability issues, a
> separate error code for EOF would really help with diagnosis.

We have separate error codes for these conditions in gnutls 3.0.x.

regards,
Nikos



From snabb at epipe.com  Tue May 22 10:38:00 2012
From: snabb at epipe.com (Janne Snabb)
Date: Tue, 22 May 2012 15:38:00 +0700
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
Message-ID: <4FBB5068.4020908@epipe.com>

On 2012-05-22 14:47, Nikos Mavrogiannopoulos wrote:
>  I don't really understand what you mean here. Is there an issue in
> gnutls we can somehow improve?

The previously discussed interop problem between GnuTLS and NSS
manifests itself in such a way that NSS client just closes the TCP
connection after it receives the "Server Hello" packet which it does not
like. The GnuTLS library provides very misleading diagnostics in that case:

[..snip..]
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
length: 4
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
4011 LOG: MAIN
4011 TLS error on connection from localhost [127.0.0.1]
(gnutls_handshake): A TLS packet with unexpected length was received.
4003 child 4011 ended: status=0x0
4003 normal exit, 0

Instead of seeing an indication of EOF, GnuTLS reports "TLS packet with
unexpected length was received". One must dive into gnutls_buffers.c to
realize that it was EOF that just happened:

  if (ret == 0)
    {                           /* EOF */
      gnutls_assert ();
      return 0;
    }

For more complete log see:

http://www.gossamer-threads.com/lists/exim/users/94048#94048


I updated the NSS bug [1] with simple instructions on how to reproduce
the issue using GnuTLS command line tools and Firefox. Even if the hard
limit in NSS is fixed quickly, this will be a burden for TLS server side
developers for many years to come. Luckily new versions of GnuTLS now
have ECDHE-RSA key exchange support as it masks the DHE-RSA interop
problem. People can survive with recent NSS clients if they make sure
that ECDHE-RSA is enabled on their servers.

I think the only reason why we have not already seen wide-spread
breakage is that the developers who use GnuTLS are not yet using the new
gnutls_sec_param_to_pk_bits() API and are instead manually setting the
DHE key size to 1024 or 2048 which works with NSS.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=636802

-- 
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From code at funwithsoftware.org  Tue May 22 11:15:00 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Tue, 22 May 2012 02:15:00 -0700
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <4FBB5068.4020908@epipe.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<4FBB5068.4020908@epipe.com>
Message-ID: <6564FE02-9B01-47BA-9F9F-4EE9E90F26A6@funwithsoftware.org>

On May 22, 2012, at 1:38 AM, Janne Snabb wrote:

> Even if the hard
> limit in NSS is fixed quickly, this will be a burden for TLS server  
> side
> developers for many years to come.

It almost seems like a new TLS extension should be proposed, where the  
client can tell the server how many bits of DH it is willing to  
accept.  (Similar in spirit, although simpler than, the extension used  
to negotiate curves for elliptic curve.)  If the client sends the  
extension, then the server can know with confidence what size of DH  
params are acceptable.  If the client doesn't send the extension, the  
server can make a conservative assumption.  (Probably 2236 bits.)

Without such an extension, it seems like TLS servers that are  
concerned about interoperability (such as on the Web) will have to  
avoid exceeding 2236 bits for quite a long time.

--Patrick




From nmav at gnutls.org  Tue May 22 11:18:48 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 11:18:48 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <4FBB5068.4020908@epipe.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<4FBB5068.4020908@epipe.com>
Message-ID: <CAJU7zaJG4CmrL4Zktn4czA366+_pcqGf482vep7gB3dFg02Ngg@mail.gmail.com>

On Tue, May 22, 2012 at 10:38 AM, Janne Snabb <snabb at epipe.com> wrote:

> The previously discussed interop problem between GnuTLS and NSS
> manifests itself in such a way that NSS client just closes the TCP
> connection after it receives the "Server Hello" packet which it does not
> like. The GnuTLS library provides very misleading diagnostics in that case:
> [..snip..]
> 4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
> length: 4
> 4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
> 4011 GnuTLS<2>: ASSERT: gnutls_buffers.c:640
> 4011 GnuTLS<2>: ASSERT: gnutls_record.c:969
> 4011 GnuTLS<2>: ASSERT: gnutls_handshake.c:3061
[...]
> Instead of seeing an indication of EOF, GnuTLS reports "TLS packet with
> unexpected length was received". One must dive into gnutls_buffers.c to
> realize that it was EOF that just happened:

Indeed this was a long time request, but would have broken the API
(many clients or servers of gnutls check for that error code to
determine eof). Thus we have only incorporated that update in the
latest 3.0.x releases. Meaning that in a 3.0.x you should have
received the error code GNUTLS_E_PREMATURE_TERMINATION.

> I updated the NSS bug [1] with simple instructions on how to reproduce
> the issue using GnuTLS command line tools and Firefox. Even if the hard
> limit in NSS is fixed quickly, this will be a burden for TLS server side
> developers for many years to come. Luckily new versions of GnuTLS now
> have ECDHE-RSA key exchange support as it masks the DHE-RSA interop
> problem. People can survive with recent NSS clients if they make sure
> that ECDHE-RSA is enabled on their servers.

Thank you.

regards,
Nikos



From nmav at gnutls.org  Tue May 22 11:23:20 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 11:23:20 +0200
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <6564FE02-9B01-47BA-9F9F-4EE9E90F26A6@funwithsoftware.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<4FBB5068.4020908@epipe.com>
	<6564FE02-9B01-47BA-9F9F-4EE9E90F26A6@funwithsoftware.org>
Message-ID: <CAJU7zaJ7k3Bq2yxNR3C1P6ts1oZx5xRmTv27k7TFjbQ1K7ZvTw@mail.gmail.com>

On Tue, May 22, 2012 at 11:15 AM, Patrick Pelletier
<code at funwithsoftware.org> wrote:

> It almost seems like a new TLS extension should be proposed, where the
> client can tell the server how many bits of DH it is willing to accept.
> ?(Similar in spirit, although simpler than, the extension used to negotiate
> curves for elliptic curve.) ?If the client sends the extension, then the
> server can know with confidence what size of DH params are acceptable. ?If
> the client doesn't send the extension, the server can make a conservative
> assumption. ?(Probably 2236 bits.)

Such an extension would be useful, as it could be used to communicate
the DH exponent size which now is only known to the server. That would
also optimize the key exchange. However I doubt that the WG would
accept such a modification (most probably such a proposal will be
answered with why don't you use ECDH?).

regards,
Nikos



From t.glaser at tarent.de  Tue May 22 11:23:07 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 22 May 2012 11:23:07 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FAC0892.3040600@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>

On Thu, 10 May 2012, Nikos Mavrogiannopoulos wrote:

> So if I understand your issue is that gnutls 3.0.11 doesn't work
> for you in  ubuntu but gnutls 3.0.19 works for you in a debian

Actually, that?s not 3.0.11 but 2.12.14-5ubuntu3 in Ubuntu precise.
I?ve tracked it down a bit: 2.10.5-1ubuntu3 in Ubuntu oneiric also
fails; 2.8.6-1ubuntu2.1 in Ubuntu natty (and 2.8.5-2ubuntu0.1 in
Ubuntu lucid) pass.

But with those that do not fail, gnutls-cli still outputs a certificate
validation error which openssl s_client doesn?t (it says the connection
is fine):

root at natty:~ # gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt -p 636 dc.lan.tarent.de
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 01
	Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
	Validity:
		Not Before: Mon Feb 07 10:24:29 UTC 2011
		Not After: Sat Feb 06 10:24:29 UTC 2016
	Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=dc.lan.tarent.de,EMAIL=admins at tarent.de
	Subject Public Key Algorithm: RSA
		Modulus (bits 1024):
			b7:9c:d6:48:f1:e9:e6:c7:0d:68:cd:67:8e:c3:14:29
			3d:d6:83:11:d0:95:3b:75:62:9d:0d:c2:67:5f:83:69
			20:29:57:7d:89:9f:4f:99:54:d6:72:1d:11:59:1a:1b
			db:ea:00:48:2f:d6:d5:c6:56:1e:fc:cb:91:c4:36:f8
			cc:a2:a9:dd:34:ad:2f:66:eb:89:fa:1b:a8:57:9a:0b
			75:f1:da:0c:a7:d0:f4:73:3d:cf:24:1e:75:95:6f:bb
			7f:c1:65:12:36:64:eb:ac:b7:14:2b:6d:99:3f:05:b6
			36:cc:41:99:fa:fb:52:89:46:94:83:2d:ac:34:13:ef
		Exponent (bits 24):
			01:00:01
	Extensions:
		Basic Constraints (not critical):
			Certificate Authority (CA): FALSE
		Subject Key Identifier (not critical):
			85f8172fa622f26215c5da9092a64ba77e007fa6
		Authority Key Identifier (not critical):
			619b65ad7b77255a9ba408325077492ad6dd1d76
	Signature Algorithm: RSA-SHA
	Signature:
		23:36:68:08:39:7c:20:6e:71:37:97:44:bc:bb:b6:af
		30:6f:7d:e7:90:fb:3d:02:2d:88:c9:44:a4:76:4e:65
		21:aa:cd:6a:92:80:a5:86:4a:9d:7e:dc:5a:ba:4d:88
		67:a3:1b:a9:4b:c9:85:f0:4b:da:28:41:0b:3d:e1:29
		cb:b7:7e:7c:de:c2:fe:55:3c:52:4f:75:e3:e2:c4:22
		71:b9:19:5b:e2:3f:41:7f:98:de:c0:02:be:18:9b:0c
		46:b0:5c:76:4f:0b:33:10:c4:d8:24:2e:f0:6c:68:ce
		ee:02:8e:c7:87:3a:0f:55:09:4c:df:6a:e0:de:65:d7
		ec:db:2e:9e:fd:f5:87:0f:d6:8c:a1:c8:d0:c5:bc:61
		f0:48:3d:fd:e8:e3:41:86:9c:37:27:41:11:61:cd:84
		18:de:ef:9b:60:ac:f4:ab:3c:b5:61:f4:31:8e:fa:85
		06:7a:c9:24:50:b5:9b:dc:1f:66:cf:5d:7c:08:e4:0d
		be:53:0d:54:ca:47:5c:b5:b0:46:94:83:64:ab:37:8e
		8e:55:81:32:80:da:a5:49:32:5d:72:0c:5c:15:64:ab
		4b:55:b7:ca:bb:41:a1:db:8f:f3:1a:b2:59:e3:da:b0
		ed:d3:4c:75:a4:34:8c:1f:2a:73:e6:d0:72:40:16:55
Other Information:
	MD5 fingerprint:
		4b8a61b6a2db43ba96516ab90e50f23b
	SHA-1 fingerprint:
		c11f5038e915c4cdf36743bc39b62ff60be8fdbf
	Public Key Id:
		85f8172fa622f26215c5da9092a64ba77e007fa6

 - Certificate[1] info:
  - X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 009d7b9eab1ec7a249
	Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
	Validity:
		Not Before: Mon Feb 07 10:24:29 UTC 2011
		Not After: Wed Feb 06 10:24:29 UTC 2013
	Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
	Subject Public Key Algorithm: RSA
		Modulus (bits 2048):
			b1:86:75:49:51:8c:0d:19:f4:f5:1d:9e:63:c1:0b:01
			04:df:ba:dc:05:bc:49:4e:6c:21:de:7b:2c:a5:dd:bf
			89:bd:2f:8e:a6:e1:6a:61:aa:4c:e0:1e:c4:48:5e:04
			45:33:b9:d8:1f:99:ab:46:72:f4:42:f7:5a:4a:0d:ec
			a6:78:2d:1c:64:63:97:8a:16:90:80:36:9e:30:ac:a0
			c1:91:56:e4:6e:ea:38:9d:dd:de:30:a7:e5:6f:40:71
			91:90:38:6d:4e:c8:1a:f7:ed:59:6a:b8:96:bf:54:3b
			0e:6f:98:61:94:ab:1b:58:4d:db:78:a8:19:38:ea:4e
			b6:1c:0b:6d:b3:76:1a:4e:80:c7:68:9b:0b:e3:81:5a
			14:5d:ea:61:b5:a1:9d:b1:ec:d8:b7:37:f7:a4:01:d3
			13:b7:88:3f:08:9a:43:de:2d:30:f3:ad:60:d3:09:36
			b7:08:7e:d6:cf:04:9b:bd:45:ac:55:8f:0b:bc:49:ca
			3f:e7:c8:2a:42:3a:05:d5:dd:07:77:10:c2:07:ca:a2
			2a:2e:84:a9:6b:b3:b0:f8:79:25:8e:bc:b5:c1:d7:c2
			1c:d7:0a:41:b0:55:4f:d0:44:50:d2:15:75:5b:21:dd
			a5:24:82:a9:99:63:8b:8d:d5:7d:71:19:31:62:e4:f7
		Exponent (bits 24):
			01:00:01
	Extensions:
		Basic Constraints (critical):
			Certificate Authority (CA): TRUE
		Subject Key Identifier (not critical):
			619b65ad7b77255a9ba408325077492ad6dd1d76
		Authority Key Identifier (not critical):
			619b65ad7b77255a9ba408325077492ad6dd1d76
		Key Usage (not critical):
			Certificate signing.
			CRL signing.
		Unknown extension 2.16.840.1.113730.1.1 (not critical):
			ASCII: ....
			Hexdump: 03020007
		Subject Alternative Name (not critical):
			RFC822name: admins at tarent.de
		Unknown extension 2.5.29.18 (not critical):
			ASCII: 0...admins at tarent.de
			Hexdump: 3012811061646d696e7340746172656e742e6465
		Unknown extension 2.16.840.1.113730.1.13 (not critical):
			ASCII: .)This certificate is a Root CA Certificate
			Hexdump: 162954686973206365727469666963617465206973206120526f6f74204341204365727469666963617465
	Signature Algorithm: RSA-SHA
	Signature:
		5b:a1:a8:ec:95:0a:95:40:ed:da:55:79:bb:75:9e:0d
		1c:73:dd:dc:e7:79:17:00:57:d7:08:a7:1b:7b:45:f3
		e3:7d:41:80:e1:49:4b:34:a1:cc:91:e1:e3:db:20:d9
		1f:01:8a:bc:74:10:40:6a:2a:c4:9c:05:d6:1a:27:c0
		da:83:81:0e:34:f7:f4:04:c5:68:38:c1:67:74:44:ab
		28:ee:a7:54:32:d7:1c:95:eb:90:a6:b9:46:d1:96:05
		99:8b:f0:d2:a3:05:43:82:3c:a1:e3:9d:52:b5:94:65
		df:df:9d:88:b5:d7:7b:1e:71:28:1e:a1:b2:80:2b:80
		57:59:57:e9:3f:10:78:01:45:54:cf:11:3c:6d:3e:ab
		50:59:3b:11:82:9a:a8:ad:ca:5a:8f:4a:e2:0c:40:da
		84:9f:bc:14:41:31:f7:ec:13:4d:48:b5:1e:96:65:3b
		1d:58:49:70:cf:04:f8:57:d3:7e:a3:3a:45:4f:05:78
		12:20:a5:b8:3a:5e:d8:17:b1:4c:37:fc:16:4e:d0:3e
		b8:ef:18:7d:ed:b2:17:c5:a6:d8:c1:34:84:34:b1:bf
		a9:67:f9:fc:82:20:96:6f:39:86:3b:bd:bd:98:52:a1
		e8:3d:6f:cb:1d:ff:f0:36:a6:c2:bf:72:3c:9b:65:21
Other Information:
	MD5 fingerprint:
		bbece4964408c9d6c8ce8079f4c4363c
	SHA-1 fingerprint:
		6da9e3f7bcea0df189a7f599599bc253517a57fc
	Public Key Id:
		619b65ad7b77255a9ba408325077492ad6dd1d76

- The hostname in the certificate matches 'dc.lan.tarent.de'.
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Session ID: 3D:82:5B:4B:E3:DD:6C:A2:69:77:8C:B9:C6:A7:5A:4E:8F:F4:E9:5E:72:73:1C:BC:18:A3:4F:32:83:3A:03:30
*** Verifying server certificate failed...

Any idea about that?

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From nmav at gnutls.org  Tue May 22 11:41:37 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 11:41:37 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
Message-ID: <CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>

On Tue, May 22, 2012 at 11:23 AM, Thorsten Glaser <t.glaser at tarent.de> wrote:

>> So if I understand your issue is that gnutls 3.0.11 doesn't work
>> for you in ?ubuntu but gnutls 3.0.19 works for you in a debian
> Actually, that?s not 3.0.11 but 2.12.14-5ubuntu3 in Ubuntu precise.
> I?ve tracked it down a bit: 2.10.5-1ubuntu3 in Ubuntu oneiric also
> fails; 2.8.6-1ubuntu2.1 in Ubuntu natty (and 2.8.5-2ubuntu0.1 in
> Ubuntu lucid) pass.
> But with those that do not fail, gnutls-cli still outputs a certificate
> validation error

Is your intermediate CA signed by a trusted authority? If yes, could
you try verifying it with certtool?

regards,
Nikos



From t.glaser at tarent.de  Tue May 22 13:36:06 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 22 May 2012 13:36:06 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>

On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:

> Is your intermediate CA signed by a trusted authority?

There?s no intermediate; the CA is auto-generated by the
Univention Server installation and directly signs all
certificates for use with SSL and KerberosV, the latter
of which we however don?t use at the moment.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From snabb at epipe.com  Tue May 22 13:40:10 2012
From: snabb at epipe.com (Janne Snabb)
Date: Tue, 22 May 2012 18:40:10 +0700
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <CAJU7zaJG4CmrL4Zktn4czA366+_pcqGf482vep7gB3dFg02Ngg@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<4FBB5068.4020908@epipe.com>
	<CAJU7zaJG4CmrL4Zktn4czA366+_pcqGf482vep7gB3dFg02Ngg@mail.gmail.com>
Message-ID: <4FBB7B1A.50509@epipe.com>

On 2012-05-22 16:18, Nikos Mavrogiannopoulos wrote:
> Meaning that in a 3.0.x you should have
> received the error code GNUTLS_E_PREMATURE_TERMINATION.

Thanks for the clarification!

I linked Exim against more recent GnuTLS library and can now see the
following error message when the EOF happens:

(gnutls_handshake): The TLS connection was non-properly terminated.

Sorry to bother with bugs that do not exist any more :).

-- 
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From nmav at gnutls.org  Tue May 22 14:54:24 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 14:54:24 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
Message-ID: <CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>

On Tue, May 22, 2012 at 1:36 PM, Thorsten Glaser <t.glaser at tarent.de> wrote:

>> Is your intermediate CA signed by a trusted authority?
> There?s no intermediate; the CA is auto-generated by the
> Univention Server installation and directly signs all
> certificates for use with SSL and KerberosV, the latter
> of which we however don?t use at the moment.

Then it seems pretty good that verification of the certificate failed.
Shouldn't you specify the auto-generated ca in --x509cafile?

regards,
Nikos



From t.glaser at tarent.de  Tue May 22 16:31:13 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 22 May 2012 16:31:13 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>

On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:

> Shouldn't you specify the auto-generated ca in --x509cafile?

It?s part of those 409 certificates (cf. openssl s_client
succeeding to validate it).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From nmav at gnutls.org  Tue May 22 16:49:47 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 16:49:47 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
Message-ID: <4FBBA78B.1000900@gnutls.org>

On 05/22/2012 04:31 PM, Thorsten Glaser wrote:

> On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:
> 
>> Shouldn't you specify the auto-generated ca in --x509cafile?
> 
> It?s part of those 409 certificates (cf. openssl s_client
> succeeding to validate it).


Could you send those two certificates to reproduce the issue?





From t.glaser at tarent.de  Tue May 22 17:14:27 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 22 May 2012 17:14:27 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FBBA78B.1000900@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>

On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:

> Could you send those two certificates to reproduce the issue?

Sure.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese
-------------- next part --------------
A non-text attachment was scrubbed...
Name: certs.tgz
Type: application/x-gtar
Size: 3459 bytes
Desc: 
URL: </pipermail/attachments/20120522/adef04c4/attachment.tgz>

From nmav at gnutls.org  Tue May 22 19:03:59 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 May 2012 19:03:59 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
Message-ID: <4FBBC6FF.1070700@gnutls.org>

On 05/22/2012 05:14 PM, Thorsten Glaser wrote:

>> Could you send those two certificates to reproduce the issue?

> Sure.

Let's get the facts straight. What have you actually tried?
Have you tried to verify your server's certificate by setting the CA
certificate you've just sent?





From t.glaser at tarent.de  Tue May 22 19:07:39 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 22 May 2012 19:07:39 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FBBC6FF.1070700@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>

On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:

> Let's get the facts straight. What have you actually tried?

I?ve tried to connect to the server using OpenSSL and GnuTLS.
Both were pointed to a CA bundle containing the server CA.
With OpenSSL, the connection succeeds, and it says it can
validate the server certificate. With GnuTLS on older *buntu
systems and current Debian, the connection similarily succeeds.
With GnuTLS on the last two *buntu releases, it fails. I?ve
looked up in slapd.conf which certificates it uses, tarred
them up and sent them.

I?m not familiar with gnutls-cli and other non-OpenSSL tools,
so if I should test other things, please tell me what and how.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From help-gnutls-phil at spodhuis.org  Wed May 23 03:03:25 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Tue, 22 May 2012 21:03:25 -0400
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
Message-ID: <20120523010325.GA49102@redoubt.spodhuis.org>

On 2012-05-22 at 10:28 +0200, Nikos Mavrogiannopoulos wrote:
[ EOF vs buffer overflow ]
> We have separate error codes for these conditions in gnutls 3.0.x.

Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
stuck to 2.12.

Building GnuTLS 3 on my dated FreeBSD 7 series install is failing, but
when I check on a more recent (FreeBSD 9) system I see that the relevant
type has been changed to avoid the issue.

----------------------------8< cut here >8------------------------------
  CC     serv.o
In file included from common.h:31,
                 from serv.c:28:
/usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long'
serv.c: In function 'tcp_server':
serv.c:1245: warning: cast to pointer from integer of different size
*** Error code 1
----------------------------8< cut here >8------------------------------

----------------------------8< cut here >8------------------------------
149 struct  ip_timestamp {
...
161         union ipt_timestamp {
162                 n_long  ipt_time[1];
163                 struct  ipt_ta {
164                         struct in_addr ipt_addr;
165                         n_long ipt_time;
166                 } ipt_ta[1];
167         } ipt_timestamp;
----------------------------8< cut here >8------------------------------

Editing src/common.h to #include <netinet/in_systm.h> just before
pulling in <netinet/ip.h> fixes this.

That in_systm.h file really just does:
  typedef u_int16_t n_short;
  typedef u_int32_t n_long;
  typedef u_int32_t n_time;
(and a function definition if inside the kernel).

FreeBSD 9 has replaced n_long with uint32_t.

Browsing:
  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip.h
the annotated view shows this changed in file revision 1.34 and so is in
FreeBSD 8 onwards.  FreeBSD 7.4 is a legacy release.

I just built with:

  # if defined(__FreeBSD__) && __FreeBSD__ < 8
  #  include <netinet/in_systm.h>
  # endif
  # include <netinet/ip.h>

I see that NetBSD has switched to using "n_time" as the type:
  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip.h?rev=1.32&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
and n_time seems to still require pulling in <netinet/in_systm.h>.

OpenBSD is also using n_time, I don't have a handy VM for that to grep
over the source tree and confirm that <netinet/in_systm.h> is the only
definition and the only include path in userland.
  http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip.h?rev=1.13;content-type=text%2Fx-cvsweb-markup

I don't touch autoconf enough to provide a good solution for you, sorry.

-Phil



From simon at josefsson.org  Wed May 23 07:22:49 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 23 May 2012 07:22:49 +0200
Subject: issues building gnutls from git on Ubuntu 12.04
In-Reply-To: <BC478D79-FEA4-40DA-B0CA-96C13961C28C@funwithsoftware.org>
	(Patrick Pelletier's message of "Sun, 20 May 2012 08:37:34 -0700")
References: <B6E4DE55-B95A-4BFF-B165-A6F923BD700E@funwithsoftware.org>
	<CAJU7zaLOZhF0w+UyvUPHBDMcznsyUjaYy1m-k2_DcBQ83eDVaA@mail.gmail.com>
	<BC478D79-FEA4-40DA-B0CA-96C13961C28C@funwithsoftware.org>
Message-ID: <871umbii8m.fsf@latte.josefsson.org>

Patrick Pelletier <code at funwithsoftware.org> writes:

> Thanks!  I did a "git clean -dfx" and that solved both of my previous
> problems.
>
> I'd been so focused on the output of "git status" that I'd forgotten
> to consider that my checkout could be "dirty" in files that were being
> gitignored.  (I'd previously tried building gnutls in that same
> directory before I upgraded to Ubuntu 12.04, so that must be where the
> dirty files came from.  I just hadn't thought about that.)

I have been using a small tool called "git cruel checkout" which wipes a
clean directory clean as if it were just checked out, you may find it
useful in situations like this.  It's inspired by the "cvsco" tool there
applies to CVS.  It is short, here it is:

#!/bin/sh
# gitco - cruel checkout.  Discards everything that has not been
# committed, and checkout missing files.
#
# Written by Simon Josefsson.  Licensed under GPLv2 or later.
# Contributions by Yann Dirson.
git clean -d -x -f
git status
git reset --hard

/Simon



From nmav at gnutls.org  Wed May 23 09:49:03 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 May 2012 09:49:03 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
Message-ID: <4FBC966F.4040607@gnutls.org>

On 05/22/2012 07:07 PM, Thorsten Glaser wrote:

> On Tue, 22 May 2012, Nikos Mavrogiannopoulos wrote:
> 
>> Let's get the facts straight. What have you actually tried?
> 
> I?ve tried to connect to the server using OpenSSL and GnuTLS.
> Both were pointed to a CA bundle containing the server CA.
> With OpenSSL, the connection succeeds, and it says it can
> validate the server certificate. With GnuTLS on older *buntu
> systems and current Debian, the connection similarily succeeds.
> With GnuTLS on the last two *buntu releases, it fails. I?ve
> looked up in slapd.conf which certificates it uses, tarred
> them up and sent them.
> 
> I?m not familiar with gnutls-cli and other non-OpenSSL tools,
> so if I should test other things, please tell me what and how.


Did you try specifying in the gnutls-cli command line the CA
certificate that you sent in the previous mail?




From t.glaser at tarent.de  Wed May 23 12:39:10 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Wed, 23 May 2012 12:39:10 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FBC966F.4040607@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>

On Wed, 23 May 2012, Nikos Mavrogiannopoulos wrote:

> Did you try specifying in the gnutls-cli command line the CA
> certificate that you sent in the previous mail?

I had not. Oh, this is too good. In this case, sorry for the
noise, and I?ll have to investigate what happened here.

[?]

Ah. Got it. And it?s too a bug in GnuTLS. Please try with
the attached file. (For what it?s worth, the file I attached
to this mail is an excerpt of the ca-bundle.crt file, and in
OpenSSL -CApath ?syntax?, they are named a4e96d2f.0 and
a4e96d2f.1, respectively ? so they have the same short hash.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese
-------------- next part --------------
-----BEGIN CERTIFICATE-----
MIIFWzCCBEOgAwIBAgIJAP9SiVa2XhxOMA0GCSqGSIb3DQEBBQUAMIGcMQswCQYD
VQQGEwJERTEMMAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0
YXJlbnQgR21iSDELMAkGA1UECxMCSVQxLDAqBgNVBAMTI1VuaXZlbnRpb24gQ29y
cG9yYXRlIFNlcnZlciBSb290IENBMR8wHQYJKoZIhvcNAQkBFhBhZG1pbnNAdGFy
ZW50LmRlMB4XDTExMDMzMTEzMjAxN1oXDTE2MDkyMDEzMjAxN1owgZwxCzAJBgNV
BAYTAkRFMQwwCgYDVQQIEwNOUlcxDTALBgNVBAcTBEJvbm4xFDASBgNVBAoTC3Rh
cmVudCBHbWJIMQswCQYDVQQLEwJJVDEsMCoGA1UEAxMjVW5pdmVudGlvbiBDb3Jw
b3JhdGUgU2VydmVyIFJvb3QgQ0ExHzAdBgkqhkiG9w0BCQEWEGFkbWluc0B0YXJl
bnQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCuIhQQB5h5ONzo
fxErFM5pqS+/WV+2fooBNdtSHPjk62Qwe44jT8owsAfMCowkhCTRJqQ8cS1/mN1Z
xvlIcjCFWcK0IbJM01XW6tfsJ1Kmylh0SFTcbhHDFXNqKo7BwECIJTeeEY/3J3oY
0+rbO15gmn+N8eYGLuBQyYzkbie9J9F7hjnipTjks0V7ra/1uvplPxUHOYxBUBSE
lhPpqJkQU5KExzWSX0pU/Qn0aYKWq1GVlg3dHPINkorHrML4+dbduaCTvdr3RffH
LL1b861kbi0uYYnoQUGk3o1BVEeZMy+YUycDjvnQGmpDY243RCDKe+0A844og4vB
hOXkZB7XAgMBAAGjggGcMIIBmDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRn
IDNw6CoTPpX7mXnts0lK1AWnvzCB0QYDVR0jBIHJMIHGgBRnIDNw6CoTPpX7mXnt
s0lK1AWnv6GBoqSBnzCBnDELMAkGA1UEBhMCREUxDDAKBgNVBAgTA05SVzENMAsG
A1UEBxMEQm9ubjEUMBIGA1UEChMLdGFyZW50IEdtYkgxCzAJBgNVBAsTAklUMSww
KgYDVQQDEyNVbml2ZW50aW9uIENvcnBvcmF0ZSBTZXJ2ZXIgUm9vdCBDQTEfMB0G
CSqGSIb3DQEJARYQYWRtaW5zQHRhcmVudC5kZYIJAP9SiVa2XhxOMAsGA1UdDwQE
AwIBBjARBglghkgBhvhCAQEEBAMCAAcwGwYDVR0RBBQwEoEQYWRtaW5zQHRhcmVu
dC5kZTAbBgNVHRIEFDASgRBhZG1pbnNAdGFyZW50LmRlMDgGCWCGSAGG+EIBDQQr
FilUaGlzIGNlcnRpZmljYXRlIGlzIGEgUm9vdCBDQSBDZXJ0aWZpY2F0ZTANBgkq
hkiG9w0BAQUFAAOCAQEAg5Mtl326C0Cp286Jr5uQyUgegueZcWK+tI5ziDzudNZ5
o5jknYTKT19dnGz7DOxn7oHCY9V6/EKiHdkIgbN/OUyYu6jwhbVXaauUNNsQlbte
qnJEXCvvJiolYISKrZ0SJ6uyGse9KCJZMc/YxrwBbU5CpZwaTc5/0+6So2hr3880
9hIauNZ/1kFQ2ZQm2IQNjM9yPYaMWI1E8y6Qy9Oi+oFqe70QTw+WUo+02Yj5bvxS
8R+dnUyjnjqFltP01xPZPBeuPly8eQ0Iwnlst4pDLLC3vnv6yyG3V7hssnEiyHex
XcpGiNsF6ON05jXSxaoh8G9xHiu/8mXNVMk76U0cGA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFWzCCBEOgAwIBAgIJAJ17nqsex6JJMA0GCSqGSIb3DQEBBQUAMIGcMQswCQYD
VQQGEwJERTEMMAoGA1UECBMDTlJXMQ0wCwYDVQQHEwRCb25uMRQwEgYDVQQKEwt0
YXJlbnQgR21iSDELMAkGA1UECxMCSVQxLDAqBgNVBAMTI1VuaXZlbnRpb24gQ29y
cG9yYXRlIFNlcnZlciBSb290IENBMR8wHQYJKoZIhvcNAQkBFhBhZG1pbnNAdGFy
ZW50LmRlMB4XDTExMDIwNzEwMjQyOVoXDTEzMDIwNjEwMjQyOVowgZwxCzAJBgNV
BAYTAkRFMQwwCgYDVQQIEwNOUlcxDTALBgNVBAcTBEJvbm4xFDASBgNVBAoTC3Rh
cmVudCBHbWJIMQswCQYDVQQLEwJJVDEsMCoGA1UEAxMjVW5pdmVudGlvbiBDb3Jw
b3JhdGUgU2VydmVyIFJvb3QgQ0ExHzAdBgkqhkiG9w0BCQEWEGFkbWluc0B0YXJl
bnQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxhnVJUYwNGfT1
HZ5jwQsBBN+63AW8SU5sId57LKXdv4m9L46m4WphqkzgHsRIXgRFM7nYH5mrRnL0
QvdaSg3spngtHGRjl4oWkIA2njCsoMGRVuRu6jid3d4wp+VvQHGRkDhtTsga9+1Z
ariWv1Q7Dm+YYZSrG1hN23ioGTjqTrYcC22zdhpOgMdomwvjgVoUXephtaGdsezY
tzf3pAHTE7eIPwiaQ94tMPOtYNMJNrcIftbPBJu9RaxVjwu8Sco/58gqQjoF1d0H
dxDCB8qiKi6EqWuzsPh5JY68tcHXwhzXCkGwVU/QRFDSFXVbId2lJIKpmWOLjdV9
cRkxYuT3AgMBAAGjggGcMIIBmDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRh
m2Wte3clWpukCDJQd0kq1t0ddjCB0QYDVR0jBIHJMIHGgBRhm2Wte3clWpukCDJQ
d0kq1t0ddqGBoqSBnzCBnDELMAkGA1UEBhMCREUxDDAKBgNVBAgTA05SVzENMAsG
A1UEBxMEQm9ubjEUMBIGA1UEChMLdGFyZW50IEdtYkgxCzAJBgNVBAsTAklUMSww
KgYDVQQDEyNVbml2ZW50aW9uIENvcnBvcmF0ZSBTZXJ2ZXIgUm9vdCBDQTEfMB0G
CSqGSIb3DQEJARYQYWRtaW5zQHRhcmVudC5kZYIJAJ17nqsex6JJMAsGA1UdDwQE
AwIBBjARBglghkgBhvhCAQEEBAMCAAcwGwYDVR0RBBQwEoEQYWRtaW5zQHRhcmVu
dC5kZTAbBgNVHRIEFDASgRBhZG1pbnNAdGFyZW50LmRlMDgGCWCGSAGG+EIBDQQr
FilUaGlzIGNlcnRpZmljYXRlIGlzIGEgUm9vdCBDQSBDZXJ0aWZpY2F0ZTANBgkq
hkiG9w0BAQUFAAOCAQEAW6Go7JUKlUDt2lV5u3WeDRxz3dzneRcAV9cIpxt7RfPj
fUGA4UlLNKHMkeHj2yDZHwGKvHQQQGoqxJwF1honwNqDgQ409/QExWg4wWd0RKso
7qdUMtccleuQprlG0ZYFmYvw0qMFQ4I8oeOdUrWUZd/fnYi113secSgeobKAK4BX
WVfpPxB4AUVUzxE8bT6rUFk7EYKaqK3KWo9K4gxA2oSfvBRBMffsE01ItR6WZTsd
WElwzwT4V9N+ozpFTwV4EiCluDpe2BexTDf8Fk7QPrjvGH3tshfFptjBNIQ0sb+p
Z/n8giCWbzmGO729mFKh6D1vyx3/8Damwr9yPJtlIQ==
-----END CERTIFICATE-----

From nmav at gnutls.org  Wed May 23 13:21:29 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 May 2012 13:21:29 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
	<alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
Message-ID: <CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>

On Wed, May 23, 2012 at 12:39 PM, Thorsten Glaser <t.glaser at tarent.de> wrote:

>> Did you try specifying in the gnutls-cli command line the CA
>> certificate that you sent in the previous mail?
> I had not. Oh, this is too good. In this case, sorry for the
> noise, and I?ll have to investigate what happened here.
> [?]
> Ah. Got it. And it?s too a bug in GnuTLS. Please try with
> the attached file. (For what it?s worth, the file I attached
> to this mail is an excerpt of the ca-bundle.crt file, and in
> OpenSSL -CApath ?syntax?, they are named a4e96d2f.0 and
> a4e96d2f.1, respectively ? so they have the same short hash.

GnuTLS doesn't use this hash. It just loads all certificates from the
provided file (in that case you ca-bundle.crt). Could it be that the
generation of the ca-bundle.crt isn't correct?

regards,
Nikos



From t.glaser at tarent.de  Wed May 23 13:29:43 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Wed, 23 May 2012 13:29:43 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
	<alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
	<CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1205231329010.24315@tglase.lan.tarent.de>

On Wed, 23 May 2012, Nikos Mavrogiannopoulos wrote:

> GnuTLS doesn't use this hash. It just loads all certificates from the
> provided file (in that case you ca-bundle.crt). Could it be that the
> generation of the ca-bundle.crt isn't correct?

No, we have two almost-the-same certificates (please look at the
file I?ve attached to the last mail), and apparently, GnuTLS looks
only at the first of these two.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From nmav at gnutls.org  Wed May 23 20:59:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 May 2012 20:59:44 +0200
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <alpine.DEB.2.02.1205231329010.24315@tglase.lan.tarent.de>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
	<alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
	<CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>
	<alpine.DEB.2.02.1205231329010.24315@tglase.lan.tarent.de>
Message-ID: <4FBD33A0.7070501@gnutls.org>

On 05/23/2012 01:29 PM, Thorsten Glaser wrote:

>> GnuTLS doesn't use this hash. It just loads all certificates from the
>> provided file (in that case you ca-bundle.crt). Could it be that the
>> generation of the ca-bundle.crt isn't correct?
> No, we have two almost-the-same certificates (please look at the
> file I?ve attached to the last mail), and apparently, GnuTLS looks
> only at the first of these two.


Thank you. Indeed this is an issue. Would the attach patch solve that?

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20120523/cda7b695/attachment.txt>

From n.mavrogiannopoulos at gmail.com  Wed May 23 21:03:37 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 23 May 2012 21:03:37 +0200
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <20120523010325.GA49102@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
Message-ID: <4FBD3489.9010109@gmail.com>

On 05/23/2012 03:03 AM, Phil Pennock wrote:

> On 2012-05-22 at 10:28 +0200, Nikos Mavrogiannopoulos wrote:
> [ EOF vs buffer overflow ]
>> We have separate error codes for these conditions in gnutls 3.0.x.
> 
> Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> stuck to 2.12.
> 
> Building GnuTLS 3 on my dated FreeBSD 7 series install is failing, but
> when I check on a more recent (FreeBSD 9) system I see that the relevant
> type has been changed to avoid the issue.
> ----------------------------8< cut here >8------------------------------
>   CC     serv.o
> In file included from common.h:31,
>                  from serv.c:28:
> /usr/include/netinet/ip.h:162: error: expected specifier-qualifier-list before 'n_long'
> serv.c: In function 'tcp_server':
> serv.c:1245: warning: cast to pointer from integer of different size
> *** Error code 1
> ----------------------------8< cut here >8------------------------------


It looks like an issue in the system rather than something that's worth
fixing in gnutls. So it is that the netinet/in.h is unusable on this
system? In that case could you submit to gnulib [0] your suggested patch?

[0]. http://www.gnu.org/software/gnulib/

regards,
Nikos



From help-gnutls-phil at spodhuis.org  Wed May 23 22:45:56 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Wed, 23 May 2012 16:45:56 -0400
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <4FBD3489.9010109@gmail.com>
References: <20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
	<4FBD3489.9010109@gmail.com>
Message-ID: <20120523204556.GA22678@redoubt.spodhuis.org>

On 2012-05-23 at 21:03 +0200, Nikos Mavrogiannopoulos wrote:
> It looks like an issue in the system rather than something that's worth
> fixing in gnutls. So it is that the netinet/in.h is unusable on this
> system?

netinet/ip.h != netinet/in.h

netinet/in.h is perfectly usable; ip.h defines struct ip, the IP
options, IPTOS values, struct ip_timestamp, ippseudo and some TTL & MSS
constants.  On a Linux box, mostly the same except that it's "struct
timestamp", no "ip_" prefix.

I wondered why this was needed so just did a build with the include
completely removed.

Everything built just fine.  It appears to be superfluous.

-Phil



From n.mavrogiannopoulos at gmail.com  Thu May 24 00:18:23 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 24 May 2012 00:18:23 +0200
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <20120523204556.GA22678@redoubt.spodhuis.org>
References: <20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
	<4FBD3489.9010109@gmail.com>
	<20120523204556.GA22678@redoubt.spodhuis.org>
Message-ID: <4FBD622F.9060704@gmail.com>

On 05/23/2012 10:45 PM, Phil Pennock wrote:

 
> netinet/ip.h != netinet/in.h
> 
> netinet/in.h is perfectly usable; ip.h defines struct ip, the IP
> options, IPTOS values, struct ip_timestamp, ippseudo and some TTL & MSS
> constants.  On a Linux box, mostly the same except that it's "struct
> timestamp", no "ip_" prefix.
> 
> I wondered why this was needed so just did a build with the include
> completely removed.
> 
> Everything built just fine.  It appears to be superfluous.


Indeed. I've dropped it as well.

regards,
Nikos




From t.glaser at tarent.de  Thu May 24 11:17:31 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 24 May 2012 11:17:31 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FBD33A0.7070501@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
	<alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
	<CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>
	<alpine.DEB.2.02.1205231329010.24315@tglase.lan.tarent.de>
	<4FBD33A0.7070501@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205241116430.16988@tglase.lan.tarent.de>

Note: this is now https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1003841

On Wed, 23 May 2012, Nikos Mavrogiannopoulos wrote:

> Thank you. Indeed this is an issue. Would the attach patch solve that?

Thanks, yes it does (applied to oneiric first, to test):

root at oneiric:~ # gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt -p 636 dc.lan.tarent.de
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.
1|root at oneiric:~ # dpkg -i libgnutls26_2.10.5-1ubuntu3.2_amd64.deb gnutls-bin_2.10.5-1ubuntu3.2_amd64.deb
(Reading database ... 19058 files and directories currently installed.)
Preparing to replace libgnutls26 2.10.5-1ubuntu3 (using libgnutls26_2.10.5-1ubuntu3.2_amd64.deb) ...
Unpacking replacement libgnutls26 ...
Preparing to replace gnutls-bin 2.10.5-1ubuntu3 (using gnutls-bin_2.10.5-1ubuntu3.2_amd64.deb) ...
Unpacking replacement gnutls-bin ...
Setting up libgnutls26 (2.10.5-1ubuntu3.2) ...
Setting up gnutls-bin (2.10.5-1ubuntu3.2) ...
Processing triggers for man-db ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
root at oneiric:~ # gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt -p 636 dc.lan.tarent.de
Processed 407 CA certificate(s).
Resolving 'dc.lan.tarent.de'...
Connecting to '172.26.100.1:636'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 01
        Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Validity:
                Not Before: Mon Feb 07 10:24:29 UTC 2011
                Not After: Sat Feb 06 10:24:29 UTC 2016
        Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=dc.lan.tarent.de,EMAIL=admins at tarent.de
        Subject Public Key Algorithm: RSA
                Modulus (bits 1024):
                        b7:9c:d6:48:f1:e9:e6:c7:0d:68:cd:67:8e:c3:14:29
                        3d:d6:83:11:d0:95:3b:75:62:9d:0d:c2:67:5f:83:69
                        20:29:57:7d:89:9f:4f:99:54:d6:72:1d:11:59:1a:1b
                        db:ea:00:48:2f:d6:d5:c6:56:1e:fc:cb:91:c4:36:f8
                        cc:a2:a9:dd:34:ad:2f:66:eb:89:fa:1b:a8:57:9a:0b
                        75:f1:da:0c:a7:d0:f4:73:3d:cf:24:1e:75:95:6f:bb
                        7f:c1:65:12:36:64:eb:ac:b7:14:2b:6d:99:3f:05:b6
                        36:cc:41:99:fa:fb:52:89:46:94:83:2d:ac:34:13:ef
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (not critical):
                        Certificate Authority (CA): FALSE
                Subject Key Identifier (not critical):
                        85f8172fa622f26215c5da9092a64ba77e007fa6
                Authority Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
        Signature Algorithm: RSA-SHA1
        Signature:
                23:36:68:08:39:7c:20:6e:71:37:97:44:bc:bb:b6:af
                30:6f:7d:e7:90:fb:3d:02:2d:88:c9:44:a4:76:4e:65
                21:aa:cd:6a:92:80:a5:86:4a:9d:7e:dc:5a:ba:4d:88
                67:a3:1b:a9:4b:c9:85:f0:4b:da:28:41:0b:3d:e1:29
                cb:b7:7e:7c:de:c2:fe:55:3c:52:4f:75:e3:e2:c4:22
                71:b9:19:5b:e2:3f:41:7f:98:de:c0:02:be:18:9b:0c
                46:b0:5c:76:4f:0b:33:10:c4:d8:24:2e:f0:6c:68:ce
                ee:02:8e:c7:87:3a:0f:55:09:4c:df:6a:e0:de:65:d7
                ec:db:2e:9e:fd:f5:87:0f:d6:8c:a1:c8:d0:c5:bc:61
                f0:48:3d:fd:e8:e3:41:86:9c:37:27:41:11:61:cd:84
                18:de:ef:9b:60:ac:f4:ab:3c:b5:61:f4:31:8e:fa:85
                06:7a:c9:24:50:b5:9b:dc:1f:66:cf:5d:7c:08:e4:0d
                be:53:0d:54:ca:47:5c:b5:b0:46:94:83:64:ab:37:8e
                8e:55:81:32:80:da:a5:49:32:5d:72:0c:5c:15:64:ab
                4b:55:b7:ca:bb:41:a1:db:8f:f3:1a:b2:59:e3:da:b0
                ed:d3:4c:75:a4:34:8c:1f:2a:73:e6:d0:72:40:16:55
Other Information:
        MD5 fingerprint:
                4b8a61b6a2db43ba96516ab90e50f23b
        SHA-1 fingerprint:
                c11f5038e915c4cdf36743bc39b62ff60be8fdbf
        Public Key Id:
                85f8172fa622f26215c5da9092a64ba77e007fa6

 - Certificate[1] info:
  - X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 009d7b9eab1ec7a249
        Issuer: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Validity:
                Not Before: Mon Feb 07 10:24:29 UTC 2011
                Not After: Wed Feb 06 10:24:29 UTC 2013
        Subject: C=DE,ST=NRW,L=Bonn,O=tarent GmbH,OU=IT,CN=Univention Corporate Server Root CA,EMAIL=admins at tarent.de
        Subject Public Key Algorithm: RSA
                Modulus (bits 2048):
                        b1:86:75:49:51:8c:0d:19:f4:f5:1d:9e:63:c1:0b:01
                        04:df:ba:dc:05:bc:49:4e:6c:21:de:7b:2c:a5:dd:bf
                        89:bd:2f:8e:a6:e1:6a:61:aa:4c:e0:1e:c4:48:5e:04
                        45:33:b9:d8:1f:99:ab:46:72:f4:42:f7:5a:4a:0d:ec
                        a6:78:2d:1c:64:63:97:8a:16:90:80:36:9e:30:ac:a0
                        c1:91:56:e4:6e:ea:38:9d:dd:de:30:a7:e5:6f:40:71
                        91:90:38:6d:4e:c8:1a:f7:ed:59:6a:b8:96:bf:54:3b
                        0e:6f:98:61:94:ab:1b:58:4d:db:78:a8:19:38:ea:4e
                        b6:1c:0b:6d:b3:76:1a:4e:80:c7:68:9b:0b:e3:81:5a
                        14:5d:ea:61:b5:a1:9d:b1:ec:d8:b7:37:f7:a4:01:d3
                        13:b7:88:3f:08:9a:43:de:2d:30:f3:ad:60:d3:09:36
                        b7:08:7e:d6:cf:04:9b:bd:45:ac:55:8f:0b:bc:49:ca
                        3f:e7:c8:2a:42:3a:05:d5:dd:07:77:10:c2:07:ca:a2
                        2a:2e:84:a9:6b:b3:b0:f8:79:25:8e:bc:b5:c1:d7:c2
                        1c:d7:0a:41:b0:55:4f:d0:44:50:d2:15:75:5b:21:dd
                        a5:24:82:a9:99:63:8b:8d:d5:7d:71:19:31:62:e4:f7
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Subject Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
                Authority Key Identifier (not critical):
                        619b65ad7b77255a9ba408325077492ad6dd1d76
                Key Usage (not critical):
                        Certificate signing.
                        CRL signing.
                Unknown extension 2.16.840.1.113730.1.1 (not critical):
                        ASCII: ....
                        Hexdump: 03020007
                Subject Alternative Name (not critical):
                        RFC822name: admins at tarent.de
                Issuer Alternative Name (not critical):
                        RFC822name: admins at tarent.de
                Unknown extension 2.16.840.1.113730.1.13 (not critical):
                        ASCII: .)This certificate is a Root CA Certificate
                        Hexdump: 162954686973206365727469666963617465206973206120526f6f74204341204365727469666963617465
        Signature Algorithm: RSA-SHA1
        Signature:
                5b:a1:a8:ec:95:0a:95:40:ed:da:55:79:bb:75:9e:0d
                1c:73:dd:dc:e7:79:17:00:57:d7:08:a7:1b:7b:45:f3
                e3:7d:41:80:e1:49:4b:34:a1:cc:91:e1:e3:db:20:d9
                1f:01:8a:bc:74:10:40:6a:2a:c4:9c:05:d6:1a:27:c0
                da:83:81:0e:34:f7:f4:04:c5:68:38:c1:67:74:44:ab
                28:ee:a7:54:32:d7:1c:95:eb:90:a6:b9:46:d1:96:05
                99:8b:f0:d2:a3:05:43:82:3c:a1:e3:9d:52:b5:94:65
                df:df:9d:88:b5:d7:7b:1e:71:28:1e:a1:b2:80:2b:80
                57:59:57:e9:3f:10:78:01:45:54:cf:11:3c:6d:3e:ab
                50:59:3b:11:82:9a:a8:ad:ca:5a:8f:4a:e2:0c:40:da
                84:9f:bc:14:41:31:f7:ec:13:4d:48:b5:1e:96:65:3b
                1d:58:49:70:cf:04:f8:57:d3:7e:a3:3a:45:4f:05:78
                12:20:a5:b8:3a:5e:d8:17:b1:4c:37:fc:16:4e:d0:3e
                b8:ef:18:7d:ed:b2:17:c5:a6:d8:c1:34:84:34:b1:bf
                a9:67:f9:fc:82:20:96:6f:39:86:3b:bd:bd:98:52:a1
                e8:3d:6f:cb:1d:ff:f0:36:a6:c2:bf:72:3c:9b:65:21
Other Information:
        MD5 fingerprint:
                bbece4964408c9d6c8ce8079f4c4363c
        SHA-1 fingerprint:
                6da9e3f7bcea0df189a7f599599bc253517a57fc
        Public Key Id:
                619b65ad7b77255a9ba408325077492ad6dd1d76

- The hostname in the certificate matches 'dc.lan.tarent.de'.
- Peer's certificate is trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Session ID: 42:94:C9:9A:AD:39:EB:4C:AF:32:B9:22:BB:DC:EA:5E:A3:F9:DC:F3:C0:70:74:4E:32:D8:69:E6:C0:73:04:F7
- Handshake was completed

- Simple Client Mode:


bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese



From snabb at epipe.com  Thu May 24 12:28:41 2012
From: snabb at epipe.com (Janne Snabb)
Date: Thu, 24 May 2012 10:28:41 +0000 (UTC)
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <20120523010325.GA49102@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
Message-ID: <alpine.DEB.2.02.1205241012150.25242@hun-sen.epipe.com>

On Tue, 22 May 2012, Phil Pennock wrote:

> Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> stuck to 2.12.

Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in Debian
sid and testing: the package name is really confusing, they call it
"libgnutls28" for some strange reason. Unfortunately all the GnuTLS
consumers (such as Exim packages for example) are linking against some
older 2.x version depending on the distribution.

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From hramrach at gmail.com  Thu May 24 20:07:04 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Thu, 24 May 2012 20:07:04 +0200
Subject: documentation incomplete?
Message-ID: <CAOMqctQPW7KtCMvubPg-b-ixF5JPnE6FaeY+NPoW_4Y+1-QD2Q@mail.gmail.com>

Hello,

Debian ships a GNUTLS pdf book in the package gnutls-doc.

In the foreword it says it aims to be self-contained.

I tried to implement gnutls in a program based on the manual (as
opposed to ripping a working code from another program as suggested in
some places on the net).

This was a terrible experience.

There is not much in the way of explanation of most return values that
contain any complex information, and the examples are grossly
incomplete.

First off I tried the example with anonymous authentication which of
course does not work. A notice that even services that do not require
client authentication (such as most https servers) typically don't
support anonymous authentication either would be quite helpful in the
manual. That client example is kind of useless because you need to
build a matching server to run it which is not included.

Second comes x509 client which should work in normal environments.

This somewhat differs for version 2 and 3 of the docs.

The v2 docs have a client with authentication and no verification and
a client with verification only, the v3 a client with both and a
separate verification function.

In the client samples the verification function helpfully prints out
some info on what is wrong with the certificate but does NOT reject it
when it is invalid.

The separate verification function is better in that regard and shows
that the INVALID flag means the cert is invalid and the rest is
informative, at least those used there. However, it does not show off
NOT_ACTIVATED or REVOKED, and there is no description of how these
flags fit together. Does REVOKED also imply invalid or should that be
checked separately?

Another issue is with checking hostname. The client samples note that
this is not real world example as hostname is checked only on the
first cert in chain yet the separate function happily does just that
as well.

Final problem is that I have a CA cert, not cert list. All the
examples deal with cert lists because it is easy, a function imports
all of it but fails to import a single cert. To import a single cert
it has to be loaded into memory, converted, and then loaded into the
credentials.

Sadly this has to be done using the undocumented gnutls_datum_t. The
structure is quite simple and examples using it abound yet I cannot
find its description and semantics when used as input or output in
gnutls.

Is there some other documentation I am missing?

Thanks

Michal



From help-gnutls-phil at spodhuis.org  Fri May 25 08:42:28 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Fri, 25 May 2012 02:42:28 -0400
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <alpine.DEB.2.02.1205241012150.25242@hun-sen.epipe.com>
References: <20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205241012150.25242@hun-sen.epipe.com>
Message-ID: <20120525064228.GA40641@redoubt.spodhuis.org>

On 2012-05-24 at 10:28 +0000, Janne Snabb wrote:
> On Tue, 22 May 2012, Phil Pennock wrote:
> > Ah, thanks.  FreeBSD Ports system and Ubuntu both lack GnuTLS 3, so I
> > stuck to 2.12.
> 
> Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in Debian
> sid and testing: the package name is really confusing, they call it
> "libgnutls28" for some strange reason. Unfortunately all the GnuTLS
> consumers (such as Exim packages for example) are linking against some
> older 2.x version depending on the distribution.

*sigh*  Well, we now use pkg-config for finding dependencies; I've
updated my Ubuntu colo VM from Oneiric to Pangolin, to get libgnutls28
available.  libgnutls28 remains non-default, but I have it now.

There are now two -dev packages containing headers and the pkg-config
file, "libgnutls-dev" and "libgnutls28-dev".  They're marked as
conflicting, so only one can be installed at once.

So Exim's current limitations concerning conflicts in include/library
paths for different components aren't an issue.  Install the -dev
package wanted, use USE_GNUTLS_PC=gnutls as suggested in Local/Makefile
and anyone building for themselves will get GnuTLS 3.

-Phil



From snabb at epipe.com  Fri May 25 19:22:30 2012
From: snabb at epipe.com (Janne Snabb)
Date: Fri, 25 May 2012 17:22:30 +0000 (UTC)
Subject: GnuTLS/NSS interop in Exim 4.80 RC
In-Reply-To: <20120521100634.GA2616@redoubt.spodhuis.org>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
Message-ID: <alpine.DEB.2.02.1205251702080.25242@hun-sen.epipe.com>

On Mon, 21 May 2012, Phil Pennock wrote:

> NSS limit is 2236 bits.

Just a brief update on this in case someone is interested:


It appears that this limit has been already increased to 3072 bits in
the latest NSS release 3.13.4. See the diff at:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=blapit.h&branch=&root=/cvsroot&subdir=mozilla/security/nss/lib/freebl&command=DIFF_FRAMESET&rev1=1.25&rev2=1.26

Thus we should be soon starting to see NSS based clients which can
negotiate DHE-RSA with GnuTLS at "NORMAL" security level.


Now they are planning to increase the limit to 16k in the next NSS
release 3.13.5. See the latest update of the NSS bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=636802

After that has been completed, NSS clients should be able to do DHE
(but probably not RSA) with GnuTLS server at all security levels.

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From nmav at gnutls.org  Fri May 25 22:25:11 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 May 2012 22:25:11 +0200
Subject: documentation incomplete?
In-Reply-To: <CAOMqctQPW7KtCMvubPg-b-ixF5JPnE6FaeY+NPoW_4Y+1-QD2Q@mail.gmail.com>
References: <CAOMqctQPW7KtCMvubPg-b-ixF5JPnE6FaeY+NPoW_4Y+1-QD2Q@mail.gmail.com>
Message-ID: <4FBFEAA7.3020005@gnutls.org>

On 05/24/2012 08:07 PM, Michal Suchanek wrote:

Hello Michal,
 Thank you for the comments.

 
> There is not much in the way of explanation of most return values that
> contain any complex information,


Could you pinpoint those?

> and the examples are grossly incomplete.

Do your comments below show the parts of the examples you consider
incomplete or you had other issues as well?  Note, however, that
examples are just that and cannot be complete applications.

> First off I tried the example with anonymous authentication which of
> course does not work. 

> A notice that even services that do not require

> client authentication (such as most https servers) typically don't
> support anonymous authentication either would be quite helpful in the
> manual. That client example is kind of useless because you need to
> build a matching server to run it which is not included.


I've added some text in the Anonymous authentication chapter to make
this more clear.

> Second comes x509 client which should work in normal environments.
> This somewhat differs for version 2 and 3 of the docs.


The documentation is continuously updated based on comments and new
library features.

> In the client samples the verification function helpfully prints out
> some info on what is wrong with the certificate but does NOT reject it
> when it is invalid.


What does it mean reject in an example application? I'd expect that
someone would customize it to his needs, but you may have a point for
someone who blindly copies it. I'll make it return an error.

> The separate verification function is better in that regard and shows
> that the INVALID flag means the cert is invalid and the rest is
> informative, at least those used there. However, it does not show off
> NOT_ACTIVATED or REVOKED, and there is no description of how these
> flags fit together. Does REVOKED also imply invalid or should that be
> checked separately?


GNUTLS_CERT_INVALID is always set on a verification error. I've
committed an update in the documentation to make that explicit.

> Another issue is with checking hostname. The client samples note that
> this is not real world example as hostname is checked only on the
> first cert in chain yet the separate function happily does just that
> as well.


The comment is a mistake. It is leftover from a previous version of this
function. Thanks for pointing out.

> Final problem is that I have a CA cert, not cert list. All the
> examples deal with cert lists because it is easy, a function imports
> all of it but fails to import a single cert. To import a single cert
> it has to be loaded into memory, converted, and then loaded into the
> credentials.


I don't understand the issue. Could you explain further?
If you are referring to gnutls_certificate_set_x509_trust_file(), it
can read PEM or DER formatted files.

> Sadly this has to be done using the undocumented gnutls_datum_t. The

> structure is quite simple and examples using it abound yet I cannot
> find its description and semantics when used as input or output in
> gnutls.

That's an omission. I've added some small text on that.

> Is there some other documentation I am missing?

Unfortunately none that I know of.


regards,
Nikos



From help-gnutls-phil at spodhuis.org  Sun May 27 07:24:24 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 27 May 2012 01:24:24 -0400
Subject: Feature req: DH prime bitsize query
Message-ID: <20120527052424.GA65833@redoubt.spodhuis.org>

Folks,

When gnutls_dh_params_generate2() is used to generate DH parameters of a
particular size, it has a tendency to overshoot.

Asking for 2236 bits, a 2237 bit prime seems to be fairly common.

I can find no GnuTLS API to ask for the size of the prime inside the
parameters structure, nor to deal with it once PKCS#3 exported.  I can
see the debug callback invoked with the generated size, and I can see
one static function which has the data, and a dispatch table which can
use one of two backend math/crypto libraries for functions which might
get the data, but no actual API which can sanely be used.

There is an API call to find out the DH size used in a TLS session.

Could GnuTLS 3 *please* get an API call to find out the size in bits of
the DH prime in a gnutls_dh_params_t ?  Perhaps even add a query mode to
certtool?

Thanks,
-Phil



From snabb at epipe.com  Sun May 27 10:47:26 2012
From: snabb at epipe.com (Janne Snabb)
Date: Sun, 27 May 2012 08:47:26 +0000 (UTC)
Subject: Feature req: DH prime bitsize query
In-Reply-To: <20120527052424.GA65833@redoubt.spodhuis.org>
References: <20120527052424.GA65833@redoubt.spodhuis.org>
Message-ID: <alpine.DEB.2.02.1205270838050.25242@hun-sen.epipe.com>

On Sun, 27 May 2012, Phil Pennock wrote:

> When gnutls_dh_params_generate2() is used to generate DH parameters of a
> particular size, it has a tendency to overshoot.
> 
> Asking for 2236 bits, a 2237 bit prime seems to be fairly common.

Ouch!

> Could GnuTLS 3 *please* get an API call to find out the size in bits of
> the DH prime in a gnutls_dh_params_t ?  Perhaps even add a query mode to
> certtool?

New version of certtool prints out the number of bits. Are you looking
for this:

$ certtool --dh-info --infile=/var/spool/exim4/gnutls-params-2236
Generator (8 bits): 02

Prime (2240 bits):
        0f:00:55:99:82:cb:c0:eb:42:eb:ef:33
[..]

The --dh-info option does not seem to be available in Ubuntu packaged
gnutls-bin version 3.0.11+really2.12.14-5ubuntu3 (wtf?) but gnutls-bin
version 3.0.19-2 on debian "sid" has the --dh-info option. I did not
have time now to look how it gets the information.

Appears that I have 2240 bits when Exim had asked for 2236. Which means
that Thunderbird/NSS would not be able to negotiate DHE-RSA with this
server :(.

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From nmav at gnutls.org  Sun May 27 13:04:33 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 May 2012 13:04:33 +0200
Subject: Feature req: DH prime bitsize query
In-Reply-To: <20120527052424.GA65833@redoubt.spodhuis.org>
References: <20120527052424.GA65833@redoubt.spodhuis.org>
Message-ID: <4FC20A41.7010508@gnutls.org>

On 05/27/2012 07:24 AM, Phil Pennock wrote:

> Folks,
> 
> When gnutls_dh_params_generate2() is used to generate DH parameters of a
> particular size, it has a tendency to overshoot.
> 
> Asking for 2236 bits, a 2237 bit prime seems to be fairly common.


Is that an issue for you? Because the bits on the various security
levels are a result of some interpolation being extreme precise in the
size of bits doesn't make IMO much sense. GnuTLS will make sure however
that there will be at least so many bits.

> I can find no GnuTLS API to ask for the size of the prime inside the
> parameters structure, nor to deal with it once PKCS#3 exported.  I can
> see the debug callback invoked with the generated size, and I can see
> one static function which has the data, and a dispatch table which can
> use one of two backend math/crypto libraries for functions which might
> get the data, but no actual API which can sanely be used.
> Could GnuTLS 3 *please* get an API call to find out the size in bits of
> the DH prime in a gnutls_dh_params_t ?  Perhaps even add a query mode to
> certtool?


Currently this can only be done indirectly by using
gnutls_dh_params_export_raw() and then checking the number of bits in
the prime. Why do you need this information? I'm thinking whether it
makes sense to have a function that will provide those numbers for
the DH parameters only, or have a generic function to return the
bits of an unsigned raw number as returned by the export_raw() functions.

regards,
Nikos





From n.mavrogiannopoulos at gmail.com  Sun May 27 13:06:00 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 27 May 2012 13:06:00 +0200
Subject: Feature req: DH prime bitsize query
In-Reply-To: <alpine.DEB.2.02.1205270838050.25242@hun-sen.epipe.com>
References: <20120527052424.GA65833@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205270838050.25242@hun-sen.epipe.com>
Message-ID: <4FC20A98.4040903@gmail.com>

On 05/27/2012 10:47 AM, Janne Snabb wrote:

> On Sun, 27 May 2012, Phil Pennock wrote:
> 
>> When gnutls_dh_params_generate2() is used to generate DH parameters of a
>> particular size, it has a tendency to overshoot.
>>
>> Asking for 2236 bits, a 2237 bit prime seems to be fairly common.
> 
> Ouch!
> 
>> Could GnuTLS 3 *please* get an API call to find out the size in bits of
>> the DH prime in a gnutls_dh_params_t ?  Perhaps even add a query mode to
>> certtool?
> 
> New version of certtool prints out the number of bits. Are you looking
> for this:
> 
> $ certtool --dh-info --infile=/var/spool/exim4/gnutls-params-2236
> Generator (8 bits): 02
> 
> Prime (2240 bits):
>         0f:00:55:99:82:cb:c0:eb:42:eb:ef:33
> [..]


That number is an overestimation. It is the number of bytes in the
number times 8, thus a function that returns a more precise number would
improve this aspect as well.

regards,
Nikos



From help-gnutls-phil at spodhuis.org  Sun May 27 16:14:07 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Sun, 27 May 2012 10:14:07 -0400
Subject: Feature req: DH prime bitsize query
In-Reply-To: <4FC20A41.7010508@gnutls.org>
References: <20120527052424.GA65833@redoubt.spodhuis.org>
	<4FC20A41.7010508@gnutls.org>
Message-ID: <20120527141407.GA2396@redoubt.spodhuis.org>

On 2012-05-27 at 13:04 +0200, Nikos Mavrogiannopoulos wrote:
> On 05/27/2012 07:24 AM, Phil Pennock wrote:
> 
> > Folks,
> > 
> > When gnutls_dh_params_generate2() is used to generate DH parameters of a
> > particular size, it has a tendency to overshoot.
> > 
> > Asking for 2236 bits, a 2237 bit prime seems to be fairly common.
> 
> 
> Is that an issue for you? Because the bits on the various security
> levels are a result of some interpolation being extreme precise in the
> size of bits doesn't make IMO much sense. GnuTLS will make sure however
> that there will be at least so many bits.

It is when 2236 is the limit used by NSS and we're clamping down the
result of
  gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_NORMAL)
to try to avoid breaking clients.

What I've actually done is grab the primes from RFCs 2409, 3526 and
5114, converted to PKCS#3 and built those into Exim as constants, and
chosen the 2048 bit prime from section 2.2 of RFC 5114 (IKE id 23) as
the default.

So by default, the new release of Exim will use vetted primes which are
within bounds, and generating the DH params using GnuTLS becomes the
non-default behaviour, thus preserving interoperability.

-Phil



From nmav at gnutls.org  Sun May 27 22:09:26 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 May 2012 22:09:26 +0200
Subject: Feature req: DH prime bitsize query
In-Reply-To: <20120527141407.GA2396@redoubt.spodhuis.org>
References: <20120527052424.GA65833@redoubt.spodhuis.org>
	<4FC20A41.7010508@gnutls.org>
	<20120527141407.GA2396@redoubt.spodhuis.org>
Message-ID: <4FC289F6.1090607@gnutls.org>

On 05/27/2012 04:14 PM, Phil Pennock wrote:

>> Is that an issue for you? Because the bits on the various security
>> levels are a result of some interpolation being extreme precise in the
>> size of bits doesn't make IMO much sense. GnuTLS will make sure however
>> that there will be at least so many bits.


> It is when 2236 is the limit used by NSS and we're clamping down the
> result of
>   gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_NORMAL)
> to try to avoid breaking clients.
> 
> What I've actually done is grab the primes from RFCs 2409, 3526 and
> 5114, converted to PKCS#3 and built those into Exim as constants, and
> chosen the 2048 bit prime from section 2.2 of RFC 5114 (IKE id 23) as
> the default.


You could also use certtool --get-dh-params to get the parameters used
in SRP (which are mostly common with the IKE parameters). However those
parameters would be much slower than using the generated with gnutls
parameters (which contain a subgroup of the order of the security
parameter, to lower the load on the server).

> So by default, the new release of Exim will use vetted primes which are
> within bounds, and generating the DH params using GnuTLS becomes the
> non-default behaviour, thus preserving interoperability.


You could also generate parameters of smaller size (2048 bits) to allow
interoperability with NSS.

regards,
Nikos




From hramrach at gmail.com  Mon May 28 13:58:51 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Mon, 28 May 2012 13:58:51 +0200
Subject: documentation incomplete?
In-Reply-To: <4FBFEAA7.3020005@gnutls.org>
References: <CAOMqctQPW7KtCMvubPg-b-ixF5JPnE6FaeY+NPoW_4Y+1-QD2Q@mail.gmail.com>
	<4FBFEAA7.3020005@gnutls.org>
Message-ID: <CAOMqctRoJhmjEtcRCnAPzTGyQ=BL1Zw+=5cbV4oxCWDYyZWJ8w@mail.gmail.com>

Hello,

On 25 May 2012 22:25, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 05/24/2012 08:07 PM, Michal Suchanek wrote:
>
> Hello Michal,
> ?Thank you for the comments.

Thanks for updating the docs.

>
>
>> There is not much in the way of explanation of most return values that
>> contain any complex information,
>
>
> Could you pinpoint those?

Besides those mentioned earlier there is an issue with error values.

You can get E_FATAL_ALERT (and the non-fatal too) and this is happily
converted to a text string by gnutls_strerror but this is NOT what you
want to do.

There are applications out in the wild that return the "Fatal alert
received" string instead of the actual error. A notice in the
gnu_strerror description could maybe prevent this issue in the future.

>
>> and the examples are grossly incomplete.
>
> Do your comments below show the parts of the examples you consider
> incomplete or you had other issues as well? ?Note, however, that
> examples are just that and cannot be complete applications.

Of course, examples aren't complete applications.

In my view the purpose of examples is  to show how is the thing they
do done correctly, and that is not always the case here.

Also when the documentation is not complete it rests on the examples
to complete it in which case they should be more verbose and
descriptive.

>> Final problem is that I have a CA cert, not cert list. All the
>> examples deal with cert lists because it is easy, a function imports
>> all of it but fails to import a single cert. To import a single cert
>> it has to be loaded into memory, converted, and then loaded into the
>> credentials.
>
>
> I don't understand the issue. Could you explain further?
> If you are referring to gnutls_certificate_set_x509_trust_file(), it
> can read PEM or DER formatted files.

Indeed, it does work as described.

The problem was in my code.

Thanks

Michal



From hramrach at gmail.com  Mon May 28 14:33:52 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Mon, 28 May 2012 14:33:52 +0200
Subject: problem with hostname matching
Message-ID: <CAOMqctRYCgAYwom+TpW+wGKQh8Hxt1bYqgY2Ogo0cDdwmAQ5cQ@mail.gmail.com>

Hello,

I have created a cert long time ago using a howto that suggested to
include the trailing dot in the domain name as good practice.

The verification with gnutls_x509_crt_check_hostname now works only
when the trailing dot is also specified in the host name.

Is this expected behaviour?

The trailing dot in the domain name should not be significant in this
case as the certificate is supposed to be issued for a fully qualified
domain name.

I am not quite sure how I would go about checking the name myself
without using the shorthand function, either.

Thanks

Michal



From nmav at gnutls.org  Mon May 28 23:16:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 May 2012 23:16:58 +0200
Subject: problem with hostname matching
In-Reply-To: <CAOMqctRYCgAYwom+TpW+wGKQh8Hxt1bYqgY2Ogo0cDdwmAQ5cQ@mail.gmail.com>
References: <CAOMqctRYCgAYwom+TpW+wGKQh8Hxt1bYqgY2Ogo0cDdwmAQ5cQ@mail.gmail.com>
Message-ID: <4FC3EB4A.2090309@gnutls.org>

On 05/28/2012 02:33 PM, Michal Suchanek wrote:

> Hello,
> 
> I have created a cert long time ago using a howto that suggested to
> include the trailing dot in the domain name as good practice.

> The verification with gnutls_x509_crt_check_hostname now works only

> when the trailing dot is also specified in the host name.

> Is this expected behaviour?

Yes. These fields are under the "preferred named syntax" of rfc1035,
that does not allow a trailing dot.

> I am not quite sure how I would go about checking the name myself
> without using the shorthand function, either.

You have to check RFC2818 which documents the procedure. You need to
read the certificate fields of subject alternative name, common name etc.

regards,
Nikos



From tobias at 23.gs  Tue May 29 11:35:43 2012
From: tobias at 23.gs (Tobias Gruetzmacher)
Date: Tue, 29 May 2012 11:35:43 +0200
Subject: GnuTLS 3, BSD, netinet/ip.h
In-Reply-To: <alpine.DEB.2.02.1205241012150.25242@hun-sen.epipe.com>
References: <20120520101648.GA31383@redoubt.spodhuis.org>
	<CAJU7zaJ7ykaOH_gqoEhVDzVU4nPJnGu=-uU2LQ_r7DKqA8NC4w@mail.gmail.com>
	<20120520231704.GA39185@redoubt.spodhuis.org>
	<CAJU7zaKguu4pUsHnCzsSwxKDhaiUx8KaFovvMUGcU2HY6WyFEw@mail.gmail.com>
	<20120521100634.GA2616@redoubt.spodhuis.org>
	<20120522005153.GA13355@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205220644350.25242@hun-sen.epipe.com>
	<CAJU7za+-swZehG5pSCpWw8FnRrLjit_TthApmWZvbXpeBYJqQg@mail.gmail.com>
	<20120522082427.GA79677@redoubt.spodhuis.org>
	<CAJU7zaJw2h2hQ4HybAv5bU9hDSu+EqPOTHtq4x6RTNn_r9-ANA@mail.gmail.com>
	<20120523010325.GA49102@redoubt.spodhuis.org>
	<alpine.DEB.2.02.1205241012150.25242@hun-sen.epipe.com>
Message-ID: <995051fcaac2d12e64e26f4ab03807f7@heapsort.de>

Hi,

On Thu, 24 May 2012 10:28:41 +0000 (UTC), Janne Snabb wrote:
> Ubuntu 12.04 actually has GnuTLS 3.0.11 but it is the same as in 
> Debian
> sid and testing: the package name is really confusing, they call it
> "libgnutls28" for some strange reason.

This "strange reason" is called "library versioning" - The internal 
major version of gnutls 3.0.x is 28 (That's LT_CURRENT-LT_AGE in 
m4/hooks.m4). And since Debian has the policy of using the library 
version in the package name to allow installation of multiple 
incompatible versions of the same library on the same system, you get 
libgnutls28 for gnutls 3.0 (or something like libx264-118, libx264-120 
and libx264-123 for packages with really unstable ABIs).

HTH, Tobias



From snabb at epipe.com  Tue May 29 16:46:18 2012
From: snabb at epipe.com (Janne Snabb)
Date: Tue, 29 May 2012 21:46:18 +0700
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
Message-ID: <4FC4E13A.903@epipe.com>

I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
a big pile of CA certificates to verify against. I can not reproduce the
problem with GnuTLS 2.12.14.

Steps to re-produce:

1. Create server key+certificate:

certtool --generate-privkey --outfile foo.key
certtool --generate-self-signed --load-privkey foo.key --outfile foo.crt

(leave all fields empty except expiration and enable signing and
encryption)

2. Start server:

gnutls-serv --x509keyfile foo.key --x509certfile foo.crt --x509cafile
/etc/ssl/certs/ca-certificates.crt

3. Connect with client and observe failure:

gnutls-cli --insecure -p 5556 localhost

4. Start server without CA cert bundle:

gnutls-serv --x509keyfile foo.key --x509certfile foo.crt

5. Connect with client and observe success:

gnutls-cli --insecure -p 5556 localhost


Note that the file /etc/ssl/certs/ca-certificates.crt contains a big
pile of certificates, as distributed by Debian and Ubuntu
"ca-certificates" package. (I am happy to send it if needed.) If I
specify just a sigle CA cert I do not see any problems.

This means that when the problem happens the "certificate request" is
bigger than 16k.

Is this a bug, or is there just too many certificates? I suspect a bug
because GnuTLS 2.12.14 nor OpenSSL does not have any issues. I am happy
to supply any additional information.


gnutls-serv outputs the following when the failure happens:

Set static Diffie-Hellman parameters, consider --dhparams.
Processed 141 CA certificate(s).
HTTP Server listening on IPv4 0.0.0.0 port 5556...done
HTTP Server listening on IPv6 :: port 5556...bind() failed: Address
already in use

* Accepted connection from IPv4 127.0.0.1 port 48518 on Tue May 29
14:18:09 2012
* Received alert '22': Record overflow.
Error in handshake
Error: A TLS fatal alert has been received.


And the gnutls-cli outputs the following:

Processed 141 CA certificate(s).
Resolving 'localhost'...
Connecting to '127.0.0.1:5556'...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate does NOT match 'localhost'
*** Verifying server certificate failed...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.


gnutls-serv output with --debug 9:

|<2>| ASSERT: pkcs11.c:459
|<2>| ASSERT: mpi.c:249
|<2>| ASSERT: gnutls_dh_primes.c:293
|<2>| ASSERT: dn.c:362
|<2>| ASSERT: dn.c:481
HTTP Server listening on IPv4 0.0.0.0 port 5556...done
HTTP Server listening on IPv6 :: port 5556...bind() failed: Address
already in use
|<4>| REC[0xa1cd60]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0xa1cd60]: Allocating epoch #1
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0xa1cd60]: SSL 3.0 Handshake packet received. Epoch 0, length: 202
|<4>| REC[0xa1cd60]: Expected Packet Handshake(22)
|<4>| REC[0xa1cd60]: Received Packet Handshake(22) with length: 202
|<4>| REC[0xa1cd60]: Decrypted Packet[0] Handshake(22) with length: 202
|<3>| HSK[0xa1cd60]: CLIENT HELLO was received. Length 198[198], frag
offset 0, frag length: 198, sequence: 0
|<3>| HSK[0xa1cd60]: Client's version: 3.3
|<2>| ASSERT: gnutls_db.c:265
|<2>| ASSERT: gnutls_db.c:297
|<3>| EXT[0xa1cd60]: Parsing extension 'SERVER NAME/0' (14 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
|<3>| HSK[0xa1cd60]: Selected ECC curve SECP192R1 (5)
|<3>| EXT[0xa1cd60]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11'
(2 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SIGNATURE ALGORITHMS/13' (28 bytes)
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.1) RSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.2) DSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (5.1) RSA-SHA384
|<3>| EXT[0xa1cd60]: rcvd signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0xa1cd60]: rcvd signature algo (6.1) RSA-SHA512
|<3>| EXT[0xa1cd60]: rcvd signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.1) RSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.2) DSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.1) RSA-SHA1
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.2) DSA-SHA1
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.3) ECDSA-SHA1
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
(C0.27)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
(C0.2F)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
(C0.30)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
(C0.12)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
(00.45)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
(00.88)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| HSK[0xa1cd60]: Requested cipher suites[size: 80]:
|<3>| 	0xc0, 0x09 ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>| 	0xc0, 0x23 ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>| 	0xc0, 0x2b ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>| 	0xc0, 0x0a ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>| 	0xc0, 0x24 ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>| 	0xc0, 0x2c ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>| 	0xc0, 0x08 ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>| 	0xc0, 0x13 ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Selected Compression Method: NULL
|<3>| HSK[0xa1cd60]: Safe renegotiation succeeded
|<3>| EXT[0xa1cd60]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0xa1cd60]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
|<3>| HSK[0xa1cd60]: SessionID:
176537c551ca398133358e980be582adc4243490f0d5d9559384190fd366d705
|<3>| HSK[0xa1cd60]: SERVER HELLO was queued [87 bytes]
|<3>| HSK[0xa1cd60]: CERTIFICATE was queued [816 bytes]
|<3>| HSK[0xa1cd60]: signing handshake data: using RSA-SHA256
|<3>| HSK[0xa1cd60]: SERVER KEY EXCHANGE was queued [365 bytes]
|<3>| EXT[0xa1cd60]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0xa1cd60]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0xa1cd60]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0xa1cd60]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0xa1cd60]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0xa1cd60]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0xa1cd60]: sent signature algo (2.3) ECDSA-SHA1
|<3>| HSK[0xa1cd60]: CERTIFICATE REQUEST was queued [17029 bytes]
|<3>| HSK[0xa1cd60]: SERVER HELLO DONE was queued [4 bytes]
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 87
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 816
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[2] Handshake(22) in epoch 0 and length: 821
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 365
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[3] Handshake(22) in epoch 0 and length: 370
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 17029
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[4] Handshake(22) in epoch 0 and length:
16389
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 645
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[5] Handshake(22) in epoch 0 and length: 650
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 4
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[6] Handshake(22) in epoch 0 and length: 9
|<2>| ASSERT: gnutls_buffers.c:974
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0xa1cd60]: SSL 3.3 Alert packet received. Epoch 0, length: 2
|<4>| REC[0xa1cd60]: Expected Packet Handshake(22)
|<4>| REC[0xa1cd60]: Received Packet Alert(21) with length: 2
|<4>| REC[0xa1cd60]: Decrypted Packet[1] Alert(21) with length: 2
|<4>| REC[0xa1cd60]: Alert[2|22] - Record overflow - was received
|<2>| ASSERT: gnutls_record.c:627
|<2>| ASSERT: gnutls_record.c:633
|<2>| ASSERT: gnutls_record.c:1111
|<2>| ASSERT: gnutls_buffers.c:1175
|<2>| ASSERT: gnutls_handshake.c:1269
|<2>| ASSERT: gnutls_handshake.c:2827
Error in handshake
|<4>| REC: Sending Alert[2|80] - Internal error
|<4>| REC[0xa1cd60]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[7] Alert(21) in epoch 0 and length: 7
|<2>| ASSERT: gnutls_record.c:238
|<4>| REC[0xa1cd60]: Start of epoch cleanup
|<4>| REC[0xa1cd60]: End of epoch cleanup
|<4>| REC[0xa1cd60]: Epoch #0 freed
|<4>| REC[0xa1cd60]: Epoch #1 freed

gnutls-cli output with --debug 9:

|<2>| ASSERT: pkcs11.c:459
|<4>| REC[0x24e4120]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0x24e4120]: Allocating epoch #1
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
(C0.09)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
(C0.0A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
(C0.08)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1
(C0.13)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
(C0.27)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
(C0.2F)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1
(C0.14)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
(C0.30)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
(C0.12)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
(00.67)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
(00.45)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256
(00.9E)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
(00.6B)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
(00.88)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
(00.40)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
(00.44)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256
(00.A2)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
(00.6A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
(00.87)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| EXT[0x24e4120]: Sending extension SERVER NAME (14 bytes)
|<3>| EXT[0x24e4120]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0x24e4120]: Sending extension SUPPORTED ECC (12 bytes)
|<3>| EXT[0x24e4120]: Sending extension SUPPORTED ECC POINT FORMATS (2
bytes)
|<3>| EXT[0x24e4120]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0x24e4120]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0x24e4120]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0x24e4120]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0x24e4120]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0x24e4120]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0x24e4120]: sent signature algo (2.3) ECDSA-SHA1
|<3>| EXT[0x24e4120]: Sending extension SIGNATURE ALGORITHMS (28 bytes)
|<3>| HSK[0x24e4120]: CLIENT HELLO was queued [202 bytes]
|<4>| REC[0x24e4120]: Preparing Packet Handshake(22) with length: 202
|<9>| ENC[0x24e4120]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0x24e4120]: Sent Packet[1] Handshake(22) in epoch 0 and
length: 207
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0, length: 87
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 87
|<4>| REC[0x24e4120]: Decrypted Packet[0] Handshake(22) with length: 87
|<3>| HSK[0x24e4120]: SERVER HELLO was received. Length 83[83], frag
offset 0, frag length: 83, sequence: 0
|<3>| HSK[0x24e4120]: Server's version: 3.3
|<3>| HSK[0x24e4120]: SessionID length: 32
|<3>| HSK[0x24e4120]: SessionID:
176537c551ca398133358e980be582adc4243490f0d5d9559384190fd366d705
|<3>| HSK[0x24e4120]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x24e4120]: Selected compression method: NULL (0)
|<3>| EXT[0x24e4120]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| EXT[0x24e4120]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11'
(2 bytes)
|<3>| HSK[0x24e4120]: Safe renegotiation succeeded
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 816
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 816
|<4>| REC[0x24e4120]: Decrypted Packet[1] Handshake(22) with length: 816
|<3>| HSK[0x24e4120]: CERTIFICATE was received. Length 812[812], frag
offset 0, frag length: 812, sequence: 0
|<2>| ASSERT: dn.c:1190
|<2>| ASSERT: verify.c:395
|<2>| ASSERT: verify.c:642
|<2>| ASSERT: dn.c:362
|<2>| ASSERT: dn.c:481
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 365
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 365
|<4>| REC[0x24e4120]: Decrypted Packet[2] Handshake(22) with length: 365
|<3>| HSK[0x24e4120]: SERVER KEY EXCHANGE was received. Length 361[361],
frag offset 0, frag length: 361, sequence: 0
|<3>| HSK[0x24e4120]: Selected ECC curve SECP192R1 (5)
|<3>| HSK[0x24e4120]: verify handshake data: using RSA-SHA256
|<2>| ASSERT: signature.c:304
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 16384
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 16384
|<4>| REC[0x24e4120]: Decrypted Packet[3] Handshake(22) with length: 16384
|<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
17025[16380], frag offset 0, frag length: 17025, sequence: 0
|<2>| ASSERT: gnutls_buffers.c:819
|<2>| ASSERT: gnutls_buffers.c:1031
|<2>| ASSERT: gnutls_handshake.c:1269
|<2>| ASSERT: gnutls_handshake.c:2515
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0x24e4120]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0x24e4120]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0x24e4120]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.
|<4>| REC[0x24e4120]: Start of epoch cleanup
|<4>| REC[0x24e4120]: End of epoch cleanup
|<4>| REC[0x24e4120]: Epoch #0 freed
|<4>| REC[0x24e4120]: Epoch #1 freed
Processed 141 CA certificate(s).
Resolving 'localhost'...
Connecting to '127.0.0.1:5556'...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate does NOT match 'localhost'
*** Verifying server certificate failed...


-- 
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From help-gnutls-phil at spodhuis.org  Tue May 29 17:31:10 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Tue, 29 May 2012 11:31:10 -0400
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <4FC4E13A.903@epipe.com>
References: <4FC4E13A.903@epipe.com>
Message-ID: <20120529153110.GA984@redoubt.spodhuis.org>

On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
> a big pile of CA certificates to verify against. I can not reproduce the
> problem with GnuTLS 2.12.14.

It appears to be commit 67f4dba6 from March 20th:
"Avoided waiting for peer's retransmission to ensure receipt of finished
 messages, and used a 'timer'-like to retransmit packets."

-  data_size = _mbuffer_get_udata_size(bufel) - handshake_header_size;
+  if (hsk->length > 0 && 
+        (hsk->end_offset-hsk->start_offset >=  data_size))

> |<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
> 17025[16380], frag offset 0, frag length: 17025, sequence: 0
> |<2>| ASSERT: gnutls_buffers.c:819
> |<2>| ASSERT: gnutls_buffers.c:1031
> |<2>| ASSERT: gnutls_handshake.c:1269
> |<2>| ASSERT: gnutls_handshake.c:2515
> *** Fatal error: A TLS packet with unexpected length was received.

The "was received" code is:
----------------------------8< cut here >8------------------------------
  _gnutls_handshake_log ("HSK[%p]: %s was received. Length %d[%d], frag offset %d, frag length: %d, sequence: %d\n",
                         session, _gnutls_handshake2str (hsk->htype),
                         (int) hsk->length, (int)data_size, hsk->start_offset, hsk->end_offset-hsk->start_offset+1, (int)hsk->sequen
ce);
----------------------------8< cut here >8------------------------------

hsk->length is read from the Handshake->length (uint24); data_size is
the size of the CertificateRequest (received buffer size less 4 for the
handshake header (type 1 octet, length 3 octets).

hsk->start_offset is always 0.
hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].

So the check added in 67f4dba6 is going to always reject a fragmented
handshake packet.

-Phil



From help-gnutls-phil at spodhuis.org  Tue May 29 17:39:28 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Tue, 29 May 2012 11:39:28 -0400
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <20120529153110.GA984@redoubt.spodhuis.org>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
Message-ID: <20120529153928.GB984@redoubt.spodhuis.org>

On 2012-05-29 at 11:31 -0400, Phil Pennock wrote:
> It appears to be commit 67f4dba6 from March 20th:

*cough* March 20th, 2011.  Sorry.

Branches:
  master, remotes/origin/ecc, remotes/origin/gnutls_3_0_12_x,
  remotes/origin/gnutls_3_0_x, remotes/origin/gnutls_3_0_x-2,
  remotes/origin/master, remotes/origin/ocsp

First tag to have this was gnutls_2_99_0.

-Phil



From nmav at gnutls.org  Tue May 29 22:34:33 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 May 2012 22:34:33 +0200
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <20120529153110.GA984@redoubt.spodhuis.org>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
Message-ID: <4FC532D9.3030603@gnutls.org>

On 05/29/2012 05:31 PM, Phil Pennock wrote:

> On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
>> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
>> a big pile of CA certificates to verify against. I can not reproduce the
>> problem with GnuTLS 2.12.14.
[...]
> hsk->length is read from the Handshake->length (uint24); data_size is
> the size of the CertificateRequest (received buffer size less 4 for the
> handshake header (type 1 octet, length 3 octets).
> hsk->start_offset is always 0.
> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
> So the check added in 67f4dba6 is going to always reject a fragmented
> handshake packet.


Correct. I've committed a fix at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=6299e8a8c7371da1e674419c36cbcbe1630aef0a
regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Tue May 29 22:36:55 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 29 May 2012 22:36:55 +0200
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <4FC4E13A.903@epipe.com>
References: <4FC4E13A.903@epipe.com>
Message-ID: <4FC53367.7010704@gmail.com>

On 05/29/2012 04:46 PM, Janne Snabb wrote:

> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
> a big pile of CA certificates to verify against. I can not reproduce the
> problem with GnuTLS 2.12.14.
> 
> Steps to re-produce:
[...]
> Note that the file /etc/ssl/certs/ca-certificates.crt contains a big
> pile of certificates, as distributed by Debian and Ubuntu
> "ca-certificates" package. (I am happy to send it if needed.) If I
> specify just a sigle CA cert I do not see any problems.
> This means that when the problem happens the "certificate request" is
> bigger than 16k.


Thank you for reporting this. A quick solution to avoid this issue is to
restrict the CAs that you enable to the server to the minimum required
(a typical server needs to trust only the authorities that signed the
user's certificates).

regards,
Nikos




From hramrach at gmail.com  Tue May 29 22:37:56 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Tue, 29 May 2012 22:37:56 +0200
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <20120529153110.GA984@redoubt.spodhuis.org>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
Message-ID: <CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>

On 29 May 2012 17:31, Phil Pennock <help-gnutls-phil at spodhuis.org> wrote:
> On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
>> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
>> a big pile of CA certificates to verify against. I can not reproduce the
>> problem with GnuTLS 2.12.14.
>
> It appears to be commit 67f4dba6 from March 20th:
> "Avoided waiting for peer's retransmission to ensure receipt of finished
> ?messages, and used a 'timer'-like to retransmit packets."
>
> - ?data_size = _mbuffer_get_udata_size(bufel) - handshake_header_size;
> + ?if (hsk->length > 0 &&
> + ? ? ? ?(hsk->end_offset-hsk->start_offset >= ?data_size))
>
>> |<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
>> 17025[16380], frag offset 0, frag length: 17025, sequence: 0
>> |<2>| ASSERT: gnutls_buffers.c:819
>> |<2>| ASSERT: gnutls_buffers.c:1031
>> |<2>| ASSERT: gnutls_handshake.c:1269
>> |<2>| ASSERT: gnutls_handshake.c:2515
>> *** Fatal error: A TLS packet with unexpected length was received.
>
> The "was received" code is:
> ----------------------------8< cut here >8------------------------------
> ?_gnutls_handshake_log ("HSK[%p]: %s was received. Length %d[%d], frag offset %d, frag length: %d, sequence: %d\n",
> ? ? ? ? ? ? ? ? ? ? ? ? session, _gnutls_handshake2str (hsk->htype),
> ? ? ? ? ? ? ? ? ? ? ? ? (int) hsk->length, (int)data_size, hsk->start_offset, hsk->end_offset-hsk->start_offset+1, (int)hsk->sequen
> ce);
> ----------------------------8< cut here >8------------------------------
>
> hsk->length is read from the Handshake->length (uint24); data_size is
> the size of the CertificateRequest (received buffer size less 4 for the
> handshake header (type 1 octet, length 3 octets).
>
> hsk->start_offset is always 0.
> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
>
> So the check added in 67f4dba6 is going to always reject a fragmented
> handshake packet.
>

Now what I do not get is how a pile of CA certificates is fragmenting
the packets.

Sounds like a security hole. CA cert piles should be local to either
side, only one CA cert relevant for the session. Technically there can
be more than one cert in the trust chain but not pile of them.

Thanks

Michal



From n.mavrogiannopoulos at gmail.com  Tue May 29 22:48:50 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 29 May 2012 22:48:50 +0200
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
Message-ID: <4FC53632.1080101@gmail.com>

On 05/29/2012 10:37 PM, Michal Suchanek wrote:

>> hsk->start_offset is always 0.
>> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
>>
>> So the check added in 67f4dba6 is going to always reject a fragmented
>> handshake packet.


> Now what I do not get is how a pile of CA certificates is fragmenting

> the packets.

In the TLS protocol the server advertises its CA certificates so a
client would know which certificate to present. If a server trusts all
the certificates in the system, the server would advertise all of them
(their DNs actually).

regards,
Nikos



From snabb at epipe.com  Tue May 29 23:17:19 2012
From: snabb at epipe.com (Janne Snabb)
Date: Wed, 30 May 2012 04:17:19 +0700
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
Message-ID: <4FC53CDF.2050209@epipe.com>

On 2012-05-30 03:37, Michal Suchanek wrote:
> Now what I do not get is how a pile of CA certificates is fragmenting
> the packets.
> 
> Sounds like a security hole. CA cert piles should be local to either
> side, only one CA cert relevant for the session. Technically there can
> be more than one cert in the trust chain but not pile of them.

If the *server* chooses to trust a pile of CA's in the same way as web
browsers (clients) typically do, this will happen, see:

https://tools.ietf.org/html/rfc5246#section-7.4.4

It also says:

"If the certificate_authorities list is empty, then the client MAY send
any certificate of the appropriate ClientCertificateType, unless there
is some external arrangement to the contrary."

...which suggests that in cases like this it might be a good idea or at
least acceptable *not* to put anything in the certificate_authorities
list when the server sends the Certificate Request. It is unclear how
various client side implementations implement the "MAY" part of the
above RFC quote. Do they send a client certificate if the CA list is
empty? Which one will they send if they have several?

It feels like there should be a way in the GnuTLS API to define whether
the list of trusted CAs is to be advertised in Certificate Request or
not. (Maybe there is a way but I am missing it?)

I encountered this issue with Exim SMTP server with the default
configuration that is packaged in Debian and Ubuntu. If the
administrator enables TLS but does not specify which CAs to trust, in
Ubuntu 12.04 it will trust 152 of them (basically the same ones as
trusted by Mozilla NSS plus a couple of more) and advertise all of them
in Certificate Request. I am sure there are many mail servers out there
which are sending more than 16 kb of data in every TLS handshake
basically just to say "we trust everyone".

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From n.mavrogiannopoulos at gmail.com  Tue May 29 23:24:47 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 29 May 2012 23:24:47 +0200
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <4FC53CDF.2050209@epipe.com>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
	<4FC53CDF.2050209@epipe.com>
Message-ID: <4FC53E9F.4030806@gmail.com>

On 05/29/2012 11:17 PM, Janne Snabb wrote:

> On 2012-05-30 03:37, Michal Suchanek wrote:
>> Now what I do not get is how a pile of CA certificates is fragmenting
>> the packets.
>>
>> Sounds like a security hole. CA cert piles should be local to either
>> side, only one CA cert relevant for the session. Technically there can
>> be more than one cert in the trust chain but not pile of them.
> 
> If the *server* chooses to trust a pile of CA's in the same way as web
> browsers (clients) typically do, this will happen, see:
> 
> https://tools.ietf.org/html/rfc5246#section-7.4.4
> 
> It also says:
> 
> "If the certificate_authorities list is empty, then the client MAY send
> any certificate of the appropriate ClientCertificateType, unless there
> is some external arrangement to the contrary."
> 
> ...which suggests that in cases like this it might be a good idea or at
> least acceptable *not* to put anything in the certificate_authorities
> list when the server sends the Certificate Request. It is unclear how
> various client side implementations implement the "MAY" part of the
> above RFC quote. Do they send a client certificate if the CA list is
> empty? Which one will they send if they have several?

Most send any certificate selected by the user.


> It feels like there should be a way in the GnuTLS API to define whether
> the list of trusted CAs is to be advertised in Certificate Request or
> not. (Maybe there is a way but I am missing it?)


There is. Check client certificate authentication at:
http://www.gnu.org/software/gnutls/manual/html_node/Certificate-credentials.html#Certificate-credentials

regards,
Nikos



From mrsam at courier-mta.com  Wed May 30 01:04:48 2012
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Tue, 29 May 2012 19:04:48 -0400
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
	<4FC53632.1080101@gmail.com>
Message-ID: <cone.1338332688.413179.1134.1000@monster.email-scan.com>

Nikos Mavrogiannopoulos writes:

> In the TLS protocol the server advertises its CA certificates so a
> client would know which certificate to present. If a server trusts all
> the certificates in the system, the server would advertise all of them
> (their DNs actually).

IIRC, this occurs only when client certificates are enabled. Yes, I would  
think that in that case only the certificates that the server trusts, should  
be loaded.

I would think that in most situations an organization would have only their  
own CA trusted, and loaded into a TLS server. I suppose I can imagine a  
situation where an org would, in some context, decide that accepting a  
client cert signed by any public CA to be acceptable, and then use it for  
some particular purpose. But I don't think this would be the case for most  
practical situations. And, in those cases, loading the public CA certs would  
be a security hole. Depending on the purpose the client cert is being used  
for, and how, it wouldn't take much imagination to get some public CA to  
sign something that looks good enough to 0wn JOO.

So, I would take a hard look at why someone really wants to load a public CA  
bundle, in the first place, to validate client certs.

I suppose someone might want, for some odd reason, to blow a wad of cash on  
having some public CA sign some certs, for their clients, even though it's  
trivial to set up your own cert, and do it yourself for free. But, still, in  
that case, at the very least you should only load /that/ CA, and not the  
whole bundle.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20120529/fabdd136/attachment.pgp>

From snabb at epipe.com  Wed May 30 05:10:15 2012
From: snabb at epipe.com (Janne Snabb)
Date: Wed, 30 May 2012 03:10:15 +0000 (UTC)
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <cone.1338332688.413179.1134.1000@monster.email-scan.com>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
	<4FC53632.1080101@gmail.com>
	<cone.1338332688.413179.1134.1000@monster.email-scan.com>
Message-ID: <alpine.DEB.2.02.1205300304560.2411@hun-sen.epipe.com>

On Tue, 29 May 2012, Sam Varshavchik wrote:

> I suppose someone might want, for some odd reason, to blow a wad of cash on
> having some public CA sign some certs, for their clients, even though it's
> trivial to set up your own cert, and do it yourself for free. But, still, in
> that case, at the very least you should only load /that/ CA, and not the whole
> bundle.

Google is one big e-mail sender that presents a client certificate signed
by one of the ~150 "well-known" CAs (I have not checked which one). There
are other similar but smaller mail senders also.

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/



From help-gnutls-phil at spodhuis.org  Wed May 30 05:47:54 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Tue, 29 May 2012 23:47:54 -0400
Subject: Big CA certificate bundle causes problems with GnuTLS 3.0.11
In-Reply-To: <alpine.DEB.2.02.1205300304560.2411@hun-sen.epipe.com>
References: <4FC4E13A.903@epipe.com>
	<20120529153110.GA984@redoubt.spodhuis.org>
	<CAOMqctS3psUuFYf1fUhY44xrRBoa5cAuzqFz68LRYvKrfSnFrQ@mail.gmail.com>
	<4FC53632.1080101@gmail.com>
	<cone.1338332688.413179.1134.1000@monster.email-scan.com>
	<alpine.DEB.2.02.1205300304560.2411@hun-sen.epipe.com>
Message-ID: <20120530034754.GA52261@redoubt.spodhuis.org>

On 2012-05-30 at 03:10 +0000, Janne Snabb wrote:
> Google is one big e-mail sender that presents a client certificate signed
> by one of the ~150 "well-known" CAs (I have not checked which one). There
> are other similar but smaller mail senders also.

Equifax, apparently:

52394 SSL verify ok: depth=2 cert=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
52394 SSL verify ok: depth=1 cert=/C=US/O=Google Inc/CN=Google Internet Authority
52394 SSL peer: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com

Hrm, Exim needs a +tls_peer_issuerdn log selector.

-Phil



From joshua.sutton at RACKSPACE.COM  Wed May 30 23:26:17 2012
From: joshua.sutton at RACKSPACE.COM (Josh Sutton)
Date: Wed, 30 May 2012 21:26:17 +0000
Subject: I get the following error
Message-ID: <BE20451B62F17E41A6A51082E05F8BFE07FB2FFC@ORD1EXD01.RACKSPACE.CORP>

Good Afternoon,

I am trying to build a wget RPM, as I am attempting the build I get the following error:

configure: error: --with-ssl was given, but GNUTLS is not available.
error: Bad exit status from /var/tmp/rpm-tmp.dgol9M (%build)

Any assistance would be appreciated.

Thanks
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120530/580d9c21/attachment.htm>

From t.glaser at tarent.de  Thu May 31 14:24:35 2012
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 31 May 2012 14:24:35 +0200 (CEST)
Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain
In-Reply-To: <4FBD33A0.7070501@gnutls.org>
References: <alpine.DEB.2.02.1205101228480.16644@tglase.lan.tarent.de>
	<4FAC0892.3040600@gnutls.org>
	<alpine.DEB.2.02.1205221120200.29998@tglase.lan.tarent.de>
	<CAJU7zaLe8i=FXEN1GiqfV5iNG=48tttuwQLJkM7KAEN9-OGu_Q@mail.gmail.com>
	<alpine.DEB.2.02.1205221335170.29998@tglase.lan.tarent.de>
	<CAJU7zaJ8ca5eL9fDtMLE9if8fBhNJZYdA3acV76qHJubqk9kiA@mail.gmail.com>
	<alpine.DEB.2.02.1205221630530.29998@tglase.lan.tarent.de>
	<4FBBA78B.1000900@gnutls.org>
	<alpine.DEB.2.02.1205221714160.29998@tglase.lan.tarent.de>
	<4FBBC6FF.1070700@gnutls.org>
	<alpine.DEB.2.02.1205221905520.29998@tglase.lan.tarent.de>
	<4FBC966F.4040607@gnutls.org>
	<alpine.DEB.2.02.1205231233100.24315@tglase.lan.tarent.de>
	<CAJU7za+jSOAZNWbqgq1C1o9C1uax+g_avfEJAvzmaHqaPQ7zsw@mail.gmail.com>
	<alpine.DEB.2.02.1205231329010.24315@tglase.lan.tarent.de>
	<4FBD33A0.7070501@gnutls.org>
Message-ID: <alpine.DEB.2.02.1205311419260.7573@tglase.lan.tarent.de>

On Wed, 23 May 2012, Nikos Mavrogiannopoulos wrote:

> Thank you. Indeed this is an issue. Would the attach patch solve that?

In the meanwhile, I tested this patch on Debian squeeze (exemplarily;
lenny is also affected), *buntu hardy, lucid, oneiric and precise,
and it works (turns out the older versions are also affected). I only
had thought it to be a regression since we used to have
	TLS_CACERT	/etc/ssl/certs/dc.lan.tarent.de.cer
in our /etc/ldap/ldap.conf, and my coworker?s new setup places the
whole ca-certificates.crt file there, instead of just the certificate
of the CA who signed the LDAP servers? certs.

Debian wheezy/sid ships two packages (gnutls26 and gnutls28); gnutls-cli
is linked against the latter there and does not exhibit the problem, but
the former might still need this patch. (But if it ends up in a GnuTLS
release, Andreas will probably add it anyway.)

There?s a comment typo (isser instead of issuer) and a few occurences of
trailing whitespace in the patch. </nitpick-mode>

https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1003841

Applying one of the debdiffs against the lenny and squeeze (and
probably sid) packages is trivial.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-314
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Boris Esser, Elmar Geese