From mike at zentific.com  Fri Oct  1 00:24:08 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Thu, 30 Sep 2010 18:24:08 -0400
Subject: ssl connection issues
In-Reply-To: <20101001070042.9497ca33.raster@rasterman.com>
References: <20100928050430.31da0423@darc.ath.cx>
	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
	<20100928054353.27e747bf@darc.ath.cx> <4CA2102E.9080104@gnutls.org>
	<20100929091515.7ab9aae2@darc.ath.cx>
	<AANLkTinw1hesAptVEy23kgN=+fub-FXxgc=Fb760x3HS@mail.gmail.com>
	<20100929102229.64224bb5@darc.ath.cx> <4CA34EE3.1050007@gnutls.org>
	<20100929104845.41ec97e5@darc.ath.cx> <4CA358A4.3050807@gnutls.org>
	<20100929150627.6513899e@darc.ath.cx>
	<20100929173514.20da21a3@darc.ath.cx>
	<20100930031055.4c133304@darc.ath.cx>
	<AANLkTi=iO5jdd2vi7F7HS=0nK7aQJTgABRaduRS_n81K@mail.gmail.com>
	<20100930153206.443ef7ce@darc.ath.cx> <4CA4EF46.3030907@gnutls.org>
	<20100930162546.1d11130b@darc.ath.cx>
	<20101001070042.9497ca33.raster@rasterman.com>
Message-ID: <20100930182408.5e0da4b8@darc.ath.cx>

On Fri, 1 Oct 2010 07:00:42 +0900
Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:

> On Thu, 30 Sep 2010 16:25:46 -0400 Michael Blumenkrantz <mike at zentific.com>
> said:
> 
> > On Thu, 30 Sep 2010 22:12:54 +0200
> > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > 
> > > On 09/30/2010 09:32 PM, Michael Blumenkrantz wrote:
> > > 
> > > > 2.10.2 fixes it! Excellent!  Is there any way that this async fix can be
> > > > backported to the 2.8 branch?  A very large portion of the EFL's users
> > > > rely on that branch and have not moved to 2.10 yet.
> > > 
> > > They are compatible so I think moving to 2.10 is pretty straight forward.
> > > 
> > > regards,
> > > Nikos
> > Indeed, however on platforms such as mobile or embedded, only the 2.8 series
> > may be available.
> 
> there is nothing u can do if all u have is 2.8 - u are stuck. the binary is
> already there. a backport would mean a rebuild and update/change of the
> shipped 2.8... and that would mean you can just as well move to 2.10 anyway
> with less work (is 2.10 doesnt break anything).
> 
> 
Ah, I thought that they had just been staying on that series.  Nevermind then!

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.



From mrsam at courier-mta.com  Sun Oct  3 00:14:57 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sat, 02 Oct 2010 18:14:57 -0400
Subject: When do I need to install dh parameters?
Message-ID: <cone.1286057697.252390.4311.500@commodore.email-scan.com>

Conceptually, I'm trying to understand when I need to install DH parameters 
if I'm using RSA certificates, using gnutls_certificate_set_dh_params(). I 
understand that DH parameters are required when using DH server certs, but 
I've got a bunch of test code (an internal testsuite) that uses RSA certs, 
with gnutls on both the client and server side, setting up TLS sessions in 
various ways -- installing a certificate up front, on the server side, or 
using a callback to return a certificate for particular TLS sessionm, etc.

I find that sometimes I can get through a handshake without loading DH 
parameters, other times handshake fails unless I install them. As far as I 
can see that's the only major difference between my code that works without 
DH parameters, and the one that fails to handshake unless DH parameters are 
installed. Am I on the right track, or are there also other situations?

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

From mike at zentific.com  Sun Oct  3 00:26:45 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Sat, 2 Oct 2010 18:26:45 -0400
Subject: memory leaks
In-Reply-To: <AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
References: <20100928050430.31da0423@darc.ath.cx>
	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
Message-ID: <20101002182645.6e30f418@darc.ath.cx>

Hi,

I have been doing some valgrinding and came across the following leaks in
gnutls, demonstrated by loading a number of CA files and then performing
gnutls_handshake().

==11329== 32 bytes in 4 blocks are definitely lost in loss record 65 of 171
==11329==    at 0x40266EA: calloc (vg_replace_malloc.c:467)
==11329==    by 0x42B9532: gnutls_x509_crt_init (x509.c:50)
==11329==    by 0x427795B: parse_pem_ca_mem (gnutls_x509.c:1007)
==11329==    by 0x4277FD2: gnutls_certificate_set_x509_trust_file
(gnutls_x509.c:1245)


==11329== 1,024 bytes in 1 blocks are definitely lost in loss record 113 of 171
==11329==    at 0x4027A66: malloc (vg_replace_malloc.c:236)
==11329==    by 0x42527D4: _gnutls_send_client_hello (gnutls_handshake.c:1985)
==11329==    by 0x4253253: _gnutls_send_hello (gnutls_handshake.c:2299)
==11329==    by 0x4254037: _gnutls_handshake_client (gnutls_handshake.c:2775)
==11329==    by 0x4253F0D: gnutls_handshake (gnutls_handshake.c:2699)

If more info is required, feel free to inquire.
-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.



From nmav at gnutls.org  Sun Oct  3 08:02:47 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Oct 2010 08:02:47 +0200
Subject: When do I need to install dh parameters?
In-Reply-To: <cone.1286057697.252390.4311.500@commodore.email-scan.com>
References: <cone.1286057697.252390.4311.500@commodore.email-scan.com>
Message-ID: <4CA81C87.4020007@gnutls.org>

On 10/03/2010 12:14 AM, Sam Varshavchik wrote:
> Conceptually, I'm trying to understand when I need to install DH
> parameters if I'm using RSA certificates, using
> gnutls_certificate_set_dh_params(). I understand that DH parameters are
> required when using DH server certs, but I've got a bunch of test code
> (an internal testsuite) that uses RSA certs, with gnutls on both the
> client and server side, setting up TLS sessions in various ways --
> installing a certificate up front, on the server side, or using a
> callback to return a certificate for particular TLS sessionm, etc.

DH parameters are used in the ephemeral Diffie Hellman ciphersuites and
the anonymous ciphersuites. DH certificates are not supported by gnutls
(and even if they were they wouldn't use the parameters). Those
ciphersuites provide forward secrecy by performing a diffie hellman
negotiation signed with your RSA certificate.

> I find that sometimes I can get through a handshake without loading DH
> parameters, other times handshake fails unless I install them. As far as
> I can see that's the only major difference between my code that works
> without DH parameters, and the one that fails to handshake unless DH
> parameters are installed. Am I on the right track, or are there also
> other situations?

Depends on the ciphersuite chosen (by you or the peer). The DHE
ciphersuites require them.

regards,
Nikos



From nmav at gnutls.org  Sun Oct  3 08:03:15 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Oct 2010 08:03:15 +0200
Subject: memory leaks
In-Reply-To: <20101002182645.6e30f418@darc.ath.cx>
References: <20100928050430.31da0423@darc.ath.cx>	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
	<20101002182645.6e30f418@darc.ath.cx>
Message-ID: <4CA81CA3.5080701@gnutls.org>

On 10/03/2010 12:26 AM, Michael Blumenkrantz wrote:
> Hi,
> 
> I have been doing some valgrinding and came across the following leaks in
> gnutls, demonstrated by loading a number of CA files and then performing
> gnutls_handshake().
> 
> ==11329== 32 bytes in 4 blocks are definitely lost in loss record 65 of 171
> ==11329==    at 0x40266EA: calloc (vg_replace_malloc.c:467)
> ==11329==    by 0x42B9532: gnutls_x509_crt_init (x509.c:50)
> ==11329==    by 0x427795B: parse_pem_ca_mem (gnutls_x509.c:1007)
> ==11329==    by 0x4277FD2: gnutls_certificate_set_x509_trust_file
> (gnutls_x509.c:1245)

Did you deallocate the structure properly?

regards,
Nikos



From mike at zentific.com  Sun Oct  3 09:45:37 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Sun, 3 Oct 2010 02:45:37 -0500
Subject: memory leaks
In-Reply-To: <4CA81CA3.5080701@gnutls.org>
References: <20100928050430.31da0423@darc.ath.cx>
	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
	<20101002182645.6e30f418@darc.ath.cx> <4CA81CA3.5080701@gnutls.org>
Message-ID: <20101003024537.5f2376ca@darc.ath.cx>

On Sun, 03 Oct 2010 08:03:15 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 10/03/2010 12:26 AM, Michael Blumenkrantz wrote:
> > Hi,
> > 
> > I have been doing some valgrinding and came across the following leaks in
> > gnutls, demonstrated by loading a number of CA files and then performing
> > gnutls_handshake().
> > 
> > ==11329== 32 bytes in 4 blocks are definitely lost in loss record 65 of 171
> > ==11329==    at 0x40266EA: calloc (vg_replace_malloc.c:467)
> > ==11329==    by 0x42B9532: gnutls_x509_crt_init (x509.c:50)
> > ==11329==    by 0x427795B: parse_pem_ca_mem (gnutls_x509.c:1007)
> > ==11329==    by 0x4277FD2: gnutls_certificate_set_x509_trust_file
> > (gnutls_x509.c:1245)
> 
> Did you deallocate the structure properly?
> 
> regards,
> Nikos
> 
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls
All that needs to be done is gnutls_certificate_free_credentials(), yes?  Or is
there more that I am missing?

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.



From bradh at frogmouth.net  Sun Oct  3 11:36:38 2010
From: bradh at frogmouth.net (Brad Hards)
Date: Sun, 3 Oct 2010 20:36:38 +1100
Subject: memory leaks
In-Reply-To: <20101003024537.5f2376ca@darc.ath.cx>
References: <20100928050430.31da0423@darc.ath.cx> <4CA81CA3.5080701@gnutls.org>
	<20101003024537.5f2376ca@darc.ath.cx>
Message-ID: <201010032036.38929.bradh@frogmouth.net>

On Sunday, October 03, 2010 06:45:37 pm Michael Blumenkrantz wrote:
> Or is there more that I am missing?
Perhaps you can post a minimal compilable example that demonstrates the 
problem?

Brad



From mrsam at courier-mta.com  Sun Oct  3 16:19:57 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 03 Oct 2010 10:19:57 -0400
Subject: When do I need to install dh parameters?
References: <cone.1286057697.252390.4311.500@commodore.email-scan.com>
	<4CA81C87.4020007@gnutls.org>
Message-ID: <cone.1286115597.13917.11599.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> On 10/03/2010 12:14 AM, Sam Varshavchik wrote:
> 
>> I find that sometimes I can get through a handshake without loading DH
>> parameters, other times handshake fails unless I install them. As far as
>> I can see that's the only major difference between my code that works
>> without DH parameters, and the one that fails to handshake unless DH
>> parameters are installed. Am I on the right track, or are there also
>> other situations?
> 
> Depends on the ciphersuite chosen (by you or the peer). The DHE
> ciphersuites require them.

Thanks, but my question was, fundamentally, why would AES-256-CBC/RSA/SHA1 
be unavailable, and common ciphersuites for a session would include only DHE 
ciphersuites, like, AES-256-CBC/DHE-RSA/SHA1, so DH parameters are required.

The docs I read were easily understood in terms of requirements for 
temporary RSA parametes -- to support weak ciphersuites. But for DH 
parameters, the documented requirement was described as just to support DHE 
ciphersuites, but without explaining when DHE ciphersuites are required.

In one of my test suites, AES-256-CBC/RSA/SHA1 was easily negotiated. In 
another one, only a DHE ciphersuite could be negotiated, and it would fail 
unless I install DH parameters, and then the handshake easily produced a 
AES-256-CBC/DHE-RSA/SHA1 session. I was trying to understand why 
AES-256-CBC/RSA/SHA1 was dropped in that case, and not available in that 
specific test scenario.

By trial and error, I think I found at least a part of the answer: it seems 
to me that if the server's certificate includes the 
GNUTLS_KEY_KEY_ENCIPHERMENT flag, set by gnutls_x509_crt_set_key(), then the 
non-DHE cipher suites are available. Without this flag, only DHE 
ciphersuites are available for negotiation.

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

From nmav at gnutls.org  Thu Oct  7 09:09:00 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Oct 2010 09:09:00 +0200
Subject: When do I need to install dh parameters?
In-Reply-To: <cone.1286115597.13917.11599.500@commodore.email-scan.com>
References: <cone.1286057697.252390.4311.500@commodore.email-scan.com>
	<4CA81C87.4020007@gnutls.org>
	<cone.1286115597.13917.11599.500@commodore.email-scan.com>
Message-ID: <4CAD720C.3070403@gnutls.org>

On 10/03/2010 04:19 PM, Sam Varshavchik wrote:

>> Depends on the ciphersuite chosen (by you or the peer). The DHE
>> ciphersuites require them.
> Thanks, but my question was, fundamentally, why would
> AES-256-CBC/RSA/SHA1 be unavailable, and common ciphersuites for a
> session would include only DHE ciphersuites, like,
> AES-256-CBC/DHE-RSA/SHA1, so DH parameters are required.

It depends on your and your peer's configuration. If the peer accepts
only DHE, or has them at higher priority than the non-DHE ciphersuites
you might end-up negotiating them. You should disable them if you don't
want to negotiate them.

> The docs I read were easily understood in terms of requirements for
> temporary RSA parametes -- to support weak ciphersuites. But for DH
> parameters, the documented requirement was described as just to support
> DHE ciphersuites, but without explaining when DHE ciphersuites are
> required.

There is no such "required". They are used if you asked for them
(enabled in the priority strings).

> By trial and error, I think I found at least a part of the answer: it
> seems to me that if the server's certificate includes the
> GNUTLS_KEY_KEY_ENCIPHERMENT flag, set by gnutls_x509_crt_set_key(), then
> the non-DHE cipher suites are available. Without this flag, only DHE
> ciphersuites are available for negotiation.

This flag orders the server not to use signing with this key. Because
the DHE ciphersuites use signing they are effectively disabled. It's
a side-effect. If you want to disable them use the priority strings.

btw. I think it is a bad idea disabling them. They offer a higher
security level than the plain RSA ciphersuites, due to perfect forward
secrecy (that is if someone steals your private key at some point, he
will not be able to decrypt previously cached sessions).

regards,
Nikos






From nmav at gnutls.org  Fri Oct  8 08:46:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Oct 2010 08:46:21 +0200
Subject: gnutls 2.11.2
Message-ID: <4CAEBE3D.6040609@gnutls.org>

Hello,

The GnuTLS 2.11.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

This is major update release that includes features such as PKCS #11
support for cryptographic objects, support for local system thread
locks, new message buffering layer, support for nettle library and more.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.2.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.2.tar.bz2

Here is the OpenPGP signature:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.2.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.2.tar.bz2.sig

regards,
Nikos

* Version 2.11.2 (released 2010-10-08)

** libgnutls: Several bug fixes on session resumption
and session tickets support.

** libgnutls: Add new extended key usage ipsecIKE.

** certtool: Renamed PKCS #11 options to: --p11-provider,
--p11-export-url, --p11-list-certs, --p11-list-certs,
--p11-list-privkeys, --p11-list-trusted, --p11-list-all-certs,
--p11-list-all, --p11-list-tokens, --p11-login, --p11-write,
--p11-write-label, --p11-write-trusted, --p11-detailed-url,
--p11-delete-url

** libgnutls: Corrected bug that caused importing DSA keys as RSA,
introduced with the new nettle code.

** libgnutls: Corrected advertizing issue for session tickets.

** API and ABI modifications:
gnutls_x509_crt_get_subject_unique_id: ADDED.
gnutls_x509_crt_get_issuer_unique_id: ADDED.



From jay.janra at gmail.com  Thu Oct 21 12:55:57 2010
From: jay.janra at gmail.com (Jay Anra)
Date: Thu, 21 Oct 2010 11:55:57 +0100
Subject: libgcrypt thread problem, maybe
Message-ID: <AANLkTingYGgmQV=uk4GdFgZT6eKrMPc5gmMZJ=mUR6ZU@mail.gmail.com>

I'm using  libgnutls.so.26.14.11 with libgcrypt.so.11.4.3 on Solaris 10.

The problem only occurs when I test my software using a local ftp server
that we have set up within our own site network.  If I test using a remote
ftp server no problem occurs.

To start with the problem was reported as an assert fail; (*lock ==
MUTEX_UNLOCKED). My code is not threaded, however I assumed there may be
some interrupts as I am using asynchronous sockets and still followed the
guide as discussed here

http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html

using the pthread model.

This resulted in the error

"Ohhhh jeeee: operation is not possible without initialized secure memory"


So then I followed the guidance here

http://lists.gnupg.org/pipermail/gcrypt-devel/2008-December/001425.html

However this resulted in another problem with the Solaris privileges system
in that I do not have permission to lock memory. I also tried the disable
secure memory option but this results in abort signals being issued either
during the initial handshake or passing the user name or password.


I don't understand why I get different behaviour with our local server and
the remote server apart from possible time delays and I don't understand why
I can't lock memory direct from my code and yet there are no such problems
when I just call gnutls_global_init() without the gcry_control() calls.

Can anyone help me understand why this is proving so difficult?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101021/3437b665/attachment.htm>