From jonathan at plews.org.uk  Tue Sep  7 12:36:34 2010
From: jonathan at plews.org.uk (Jonathan Plews)
Date: Tue, 07 Sep 2010 11:36:34 +0100
Subject: An issue that wont die? A TLS packet with unexpected length was
 received
Message-ID: <20100907113634.154151jibjiei64g@horde.syn.co.uk>

Hi,

I've used as much time as I can practically allow to try find out what  
is wrong here. This issue has raised its head because of Exchange  
severs sending mail to one of my clients do not fall back to  
unencrypted when it encounters an error, and this seems to only be  
happening recently. They just sit there trying to connect again and  
again (sending unhelpful errors back to the sender)


I'm using Debain 5, the packages directly related to the problem are  
Exim, GNUTLS and ca-certificates.

The quick fix was to hack at /etc/ssl/certs and remove it all (apart  
from ones used by services running on the box itself)

Before I embark on trying to find problems between ca-certificates and  
gnutls I just wanted to ask if anyone knows about this issue and a  
better way to fix it?

Judging from the years of mess and bug reports this issue could do  
with being wrapped up for everyone, I saw it crop up on the debian  
exim list a month or so ago.

I may be missing something, in which case I'm sorry and grateful for the help.

-- 
Jonathan Plews




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: PGP Digital Signature
URL: </pipermail/attachments/20100907/98f02dbe/attachment.pgp>

From iAMin83567 at HotMail.com  Mon Sep  6 06:41:06 2010
From: iAMin83567 at HotMail.com (Li Min Yu)
Date: Mon, 6 Sep 2010 04:41:06 +0000 (UTC)
Subject: compile gnu-tls 2.10.1
References: <AANLkTimSKrzebnuy42x4qNCgCmqCfz5k7KMkjEXc2B+i@mail.gmail.com>
Message-ID: <loom.20100906T063627-970@post.gmane.org>

Goran Pivac <goran.pivac <at> gmail.com> writes:

> 
> Hi,
> I'm trying to compile and install gnutls2.10.1 on my AIX6.1 machine
> ld: 0711-317 ERROR: Undefined symbol: .gcry_control
> 

How solved this issue? I got the same error on AIX 5.3.0.10 64-bits.(powerpc-
ibm-aix5.3.0.0)
GCC Version is : 4.2.0.0




From nmav at gnutls.org  Tue Sep  7 18:35:18 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 07 Sep 2010 18:35:18 +0200
Subject: An issue that wont die? A TLS packet with unexpected length was
 received
In-Reply-To: <20100907133940.14084xbxygxlzp1c@horde.syn.co.uk>
References: <20100907113634.154151jibjiei64g@horde.syn.co.uk>
	<AANLkTim3Ep846UHuW3ERCSOav28-A5MR2BGq23ZjyNK4@mail.gmail.com>
	<20100907133940.14084xbxygxlzp1c@horde.syn.co.uk>
Message-ID: <4C8669C6.4050801@gnutls.org>

On 09/07/2010 02:39 PM, Jonathan Plews wrote:
> On servers that get these errors: 2.4.2-6+lenny2 and 2.8.6-1 (both from
> debian packages)
> 
> I can try downloading latest source, but these are all live servers so I
> have to be careful, I've already taken some heat because of problems ;)
> I just wanted to see if anyone knew anything before putting time into
> things like that.

I suspect that the peer doesn't like the fact that a big list of CA
names is being sent to him. Could you try the attached patch with a test
server?

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

From goran.pivac at gmail.com  Wed Sep  8 10:44:15 2010
From: goran.pivac at gmail.com (Goran Pivac)
Date: Wed, 8 Sep 2010 10:44:15 +0200
Subject: compile gnu-tls 2.10.1
In-Reply-To: <loom.20100906T063627-970@post.gmane.org>
References: <AANLkTimSKrzebnuy42x4qNCgCmqCfz5k7KMkjEXc2B+i@mail.gmail.com>
	<loom.20100906T063627-970@post.gmane.org>
Message-ID: <AANLkTi=1dpvh1MsPkepUXV7qkP=mQ_XwtdWWX13V2=y1@mail.gmail.com>

Hi,
I didn't
I'm using openssl instead, and it works fine!
But i'm still interested to see the solution!


On Mon, Sep 6, 2010 at 6:41 AM, Li Min Yu <iAMin83567 at hotmail.com> wrote:
> Goran Pivac <goran.pivac <at> gmail.com> writes:
>
>>
>> Hi,
>> I'm trying to compile and install gnutls2.10.1 on my AIX6.1 machine
>> ld: 0711-317 ERROR: Undefined symbol: .gcry_control
>>
>
> How solved this issue? I got the same error on AIX 5.3.0.10 64-bits.(powerpc-
> ibm-aix5.3.0.0)
> GCC Version is : 4.2.0.0
>
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls
>



From nmav at gnutls.org  Wed Sep  8 13:07:55 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 08 Sep 2010 13:07:55 +0200
Subject: compile gnu-tls 2.10.1
In-Reply-To: <AANLkTi=1dpvh1MsPkepUXV7qkP=mQ_XwtdWWX13V2=y1@mail.gmail.com>
References: <AANLkTimSKrzebnuy42x4qNCgCmqCfz5k7KMkjEXc2B+i@mail.gmail.com>	<loom.20100906T063627-970@post.gmane.org>
	<AANLkTi=1dpvh1MsPkepUXV7qkP=mQ_XwtdWWX13V2=y1@mail.gmail.com>
Message-ID: <4C876E8B.2080005@gnutls.org>

On 09/08/2010 10:44 AM, Goran Pivac wrote:
> Hi,
> I didn't
> I'm using openssl instead, and it works fine!
> But i'm still interested to see the solution!

This is a gcrypt symbol. Try linking with gcrypt. (-lgcrypt in LDFLAGS).

regards,
Nikos



From iAMin83567 at HotMail.com  Wed Sep  8 17:42:41 2010
From: iAMin83567 at HotMail.com (Li Min Yu)
Date: Wed, 8 Sep 2010 15:42:41 +0000 (UTC)
Subject: compile gnu-tls 2.10.1
References: <AANLkTimSKrzebnuy42x4qNCgCmqCfz5k7KMkjEXc2B+i@mail.gmail.com>	<loom.20100906T063627-970@post.gmane.org>
	<AANLkTi=1dpvh1MsPkepUXV7qkP=mQ_XwtdWWX13V2=y1@mail.gmail.com>
	<4C876E8B.2080005@gnutls.org>
Message-ID: <loom.20100908T163650-570@post.gmane.org>

Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:
> 
> On 09/08/2010 10:44 AM, Goran Pivac wrote:
> > Hi,
> > I didn't
> > I'm using openssl instead, and it works fine!
> > But i'm still interested to see the solution!
> 
> This is a gcrypt symbol. Try linking with gcrypt. (-lgcrypt in LDFLAGS).
> 
> regards,
> Nikos
> 

Thanks Nikos, I installed gnu-tls 2.10 successfully.
export LDFLAGS=-lgcrypt
./configure
make
make install




From hoyt6 at llnl.gov  Fri Sep 10 03:31:39 2010
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 9 Sep 2010 18:31:39 -0700
Subject: MinGW-w64 Compatibility with v2.10.1
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9EE88184A0C@NSPEXMBX-C.the-lab.llnl.gov>

A build using the latest from MinGW-w64 fails with a redefinition error b/c it finds socklen_t in two places. Configure finds both winsock2.h and ws2tcipip.h and when it finds winsock.h, it does a "typedef int socklen_t" in gl/sys_socket.in.h but this is already defined in ws2tcpip.h. When I specified -D_WIN32_WINNT=0x0501 for Windows XP or higher support only, it compiled cleanly. It looks like a guard is needed at line 154 of gl/sys_socket.in.h - something along the lines of (this has not been tested): 

#ifndef @HAVE_WS2TCPIP_H@
typedef int socklen_t;
#endif

Thanks,
- David Hoyt



From nmav at gnutls.org  Tue Sep 14 13:56:46 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 14 Sep 2010 13:56:46 +0200
Subject: gnutls 2.11.1
Message-ID: <4C8F62FE.1020808@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.1.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.1.tar.bz2

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

regards,
Nikos

* Version 2.11.1 (released 2010-09-14)

** libgnutls: Nettle is the default crypto back end. Use
--with-libgcrypt to use the libgcrypt back end.

** libgnutls: Depend on nettle 2.1. This makes nettle a fully working
backend crypto library.

** libgnutls: Added RSA_NULL_SHA1 and SHA256 ciphersuites.

** libgnutls: Several updates in the buffering internal interface.

** libgnutls: Is now more liberal in the PEM decoding. That is spaces
and tabs are being skipped.

** libgnutls: Added support for draft-pechanec-pkcs11uri-02.

** libgnutls: The %COMPAT flag now allows larger records that violate
the TLS spec.

** libgnutls: by default lowat level has been set to zero to avoid
unnecessary system calls. Applications that depended on it being 1
should explicitly call gnutls_transport_set_lowat().

** libgnutls: Updated documentation and gnutls_pk_params_t mappings
to ECRYPT II recommendations. Mappings were moved to a single location
and DSA keys are handled differently (since DSA2 allows for 1024,2048
and 3072 keys only).

** libgnutls: gnutls_x509_privkey_import() will fallback to
gnutls_x509_privkey_import_pkcs8() without a password, if it
is unable to decode the key.

** libgnutls: HMAC-MD5 no longer used by default.

** API and ABI modifications:
gnutls_openpgp_privkey_sec_param: ADDED
gnutls_x509_privkey_sec_param: ADDED



From nmav at gnutls.org  Tue Sep 14 14:00:57 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 14 Sep 2010 14:00:57 +0200
Subject: MinGW-w64 Compatibility with v2.10.1
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9EE88184A0C@NSPEXMBX-C.the-lab.llnl.gov>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9EE88184A0C@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <4C8F63F9.5070906@gnutls.org>

On 09/10/2010 03:31 AM, Hoyt, David wrote:
> A build using the latest from MinGW-w64 fails with a redefinition error b/c it finds socklen_t in two places. Configure finds both winsock2.h and ws2tcipip.h and when it finds winsock.h, it does a "typedef int socklen_t" in gl/sys_socket.in.h but this is already defined in ws2tcpip.h. When I specified -D_WIN32_WINNT=0x0501 for Windows XP or higher support only, it compiled cleanly. It looks like a guard is needed at line 154 of gl/sys_socket.in.h - something along the lines of (this has not been tested): 
> 
> #ifndef @HAVE_WS2TCPIP_H@
> typedef int socklen_t;
> #endif

Hello,
 Thanks for the report. you might want to report it directly to gnulib
people[0] since in gnutls we only transparently use it.

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

best regards,
Nikos



From simon at josefsson.org  Tue Sep 21 14:54:40 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 21 Sep 2010 14:54:40 +0200
Subject: Libtasn1-1.8 doesn't exist in gnutls directory
In-Reply-To: <AANLkTi=OLtqsgvrpZuOueqD4nJg4QiBMs662rYym9jE6@mail.gmail.com>
	(Dwi Sasongko Supriyadi's message of "Wed, 25 Aug 2010 10:00:00
	+0700")
References: <AANLkTi=OLtqsgvrpZuOueqD4nJg4QiBMs662rYym9jE6@mail.gmail.com>
Message-ID: <87tyljz27j.fsf@mocca.josefsson.org>

Dwi Sasongko Supriyadi <ruckuus at gmail.com> writes:

> Hello Folks,
>
> I did not see libtasn1-1.8 in gnutls directory,
>
> [1] ftp://ftp.gnu.org/gnu/gnutls/
>
> instead I get it from:
>
> [2] http://ftp.gnu.org/gnu/libtasn1/
>
> According this post:
>
> http://www.mail-archive.com/help-shishi at gnu.org/msg00491.html
>
> the "official" place for libtasn is in [1]. Does anyone aware of this?

The official place has changed, check the official GNU Libtasn1
homepage:

http://www.gnu.org/software/libtasn1/

And also check any recent release announcement, for example the latest
one:

http://lists.gnu.org/archive/html/help-libtasn1/2010-05/msg00000.html

/Simon



From fwi at opensynergy.com  Fri Sep 24 12:36:32 2010
From: fwi at opensynergy.com (Florian Wirth)
Date: Fri, 24 Sep 2010 12:36:32 +0200
Subject: TLS 1.2
Message-ID: <1285324592.3970.13.camel@fwi>

Hi I have a question about Gnutls. I use Gnutls-2-10.1 and connect to
your test server. My Problem is that the connection is only TLS 1.1. So
I want to know how can I use TLS 1.2 with Gnu TLS. I have the same
Problem when I try to connect to my own apache.

Thanks for helping



From nmav at gnutls.org  Fri Sep 24 18:15:36 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 24 Sep 2010 18:15:36 +0200
Subject: TLS 1.2
In-Reply-To: <1285324592.3970.13.camel@fwi>
References: <1285324592.3970.13.camel@fwi>
Message-ID: <4C9CCEA8.7040009@gnutls.org>

On 09/24/2010 12:36 PM, Florian Wirth wrote:
> Hi I have a question about Gnutls. I use Gnutls-2-10.1 and connect to
> your test server. My Problem is that the connection is only TLS 1.1. So
> I want to know how can I use TLS 1.2 with Gnu TLS. I have the same
> Problem when I try to connect to my own apache.

Some test sites that support TLS 1.2 are:
tls.woodgrovebank.com:443
www.mikestoolbox.net:443

test.gnutls.org doesn't support TLS 1.2 yet.

regards,
Nikos



From mike at zentific.com  Sat Sep 25 09:53:19 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Sat, 25 Sep 2010 03:53:19 -0400
Subject: gnutls async rehandshakes
In-Reply-To: <4C9D9E68.1030107@gnutls.org>
References: <20100925003048.2b48a9d5@darc.ath.cx> <4C9D9E68.1030107@gnutls.org>
Message-ID: <20100925035319.1e9289de@darc.ath.cx>

|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<2>| EXT[0x81f9038]: Sending extension CERT_TYPE
|<2>| EXT[0x81f9038]: Sending extension SERVER_NAME
|<2>| EXT[0x81f9038]: Sending extension SAFE_RENEGOTIATION
|<2>| EXT[0x81f9038]: Sending extension SESSION_TICKET
|<3>| HSK[0x81f9038]: CLIENT HELLO was sent [112 bytes]
|<4>| REC[0x81f9038]: Sending Packet[0] Handshake(22) with length: 112
|<2>| ASSERT: gnutls_record.c:450
|<2>| ASSERT: gnutls_buffers.c:933
|<2>| ASSERT: gnutls_buffers.c:957
|<2>| ASSERT: gnutls_handshake.c:2772
|<2>| ASSERT: gnutls_buffers.c:857
|<4>| REC[0x81f9038]: Sending Packet[1] Handshake(22) with length: 112
|<4>| REC[0x81f9038]: Sent Packet[1] Handshake(22) with length: 117
|<4>| REC[0x81f9038]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[0] Handshake(22) with length: 48
|<4>| REC[0x81f9038]: Decrypted Packet[0] Handshake(22) with length: 48
|<3>| HSK[0x81f9038]: SERVER HELLO was received [48 bytes]
|<3>| HSK[0x81f9038]: Server's version: 3.1
|<3>| HSK[0x81f9038]: SessionID length: 0
|<3>| HSK[0x81f9038]: SessionID: 
|<3>| HSK[0x81f9038]: Selected cipher suite: RSA_AES_256_CBC_SHA1
|<2>| EXT[0x81f9038]: Found extension 'SESSION_TICKET/35'
|<3>| HSK[0x81f9038]: Allowing unsafe initial negotiation
|<4>| REC[0x81f9038]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[1] Handshake(22) with length: 1098
|<4>| REC[0x81f9038]: Decrypted Packet[1] Handshake(22) with length: 1098
|<3>| HSK[0x81f9038]: CERTIFICATE was received [1098 bytes]
|<4>| REC[0x81f9038]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[2] Handshake(22) with length: 4
|<4>| REC[0x81f9038]: Decrypted Packet[2] Handshake(22) with length: 4
|<3>| HSK[0x81f9038]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1332
|<3>| HSK[0x81f9038]: CLIENT KEY EXCHANGE was sent [262 bytes]
|<4>| REC[0x81f9038]: Sending Packet[1] Handshake(22) with length: 262
|<4>| REC[0x81f9038]: Sent Packet[2] Handshake(22) with length: 267
|<3>| REC[0x81f9038]: Sent ChangeCipherSpec
|<4>| REC[0x81f9038]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<4>| REC[0x81f9038]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[48]:
0302e7de0ed59cc23c0c076f5e7e2a129d9a2bbcf616ba40e86d2c6887c04cfad540ae7e6b9725fe99661a0a48e45fb6
|<9>| INT: CLIENT RANDOM[32]:
4c9da96ad4b1f1311900c375822eb7a65c4a2f702b714f51bcc656d7528c7d9c |<9>| INT:
SERVER RANDOM[32]:
4c9da96a2e7cda3976a4116d2346be24e8fda32dc16cc1c9a6c7d75fe830af91 |<9>| INT:
MASTER SECRET:
a1f91917a565a52d362127fa7fecbf589ade4e92fa112e79536ddcddb6345991d00e4798043a3af3517ac84496969093
|<9>| INT: KEY BLOCK[136]:
9148f69667f9486ef9a2d23ee55f6b19fe3d3ffb99d9fc244d0ae53be4c9b959 |<9>| INT:
CLIENT WRITE KEY [32]:
7c013f2aa1be779eb06c5c4019dd05b2fa1497cf54552cb7502711dfce9a76b7 |<9>| INT:
SERVER WRITE KEY [32]:
b608e543ca1aa97a0af17cdfdabadee28815a70cf7385ae31d84089f319873ba |<3>|
HSK[0x81f9038]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x81f9038]:
Initializing internal [write] cipher sessions |<3>| HSK[0x81f9038]: FINISHED
was sent [16 bytes] |<4>| REC[0x81f9038]: Sending Packet[0] Handshake(22) with
length: 16 |<4>| REC[0x81f9038]: Sent Packet[1] Handshake(22) with length: 277
|<2>| ASSERT: ext_session_ticket.c:582
------repeats a large number of times--------
|<4>| REC[0x81f9038]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[3] Alert(21) with length: 2
|<4>| REC[0x81f9038]: Decrypted Packet[3] Alert(21) with length: 2
|<4>| REC[0x81f9038]: Alert[2|51] - Decrypt error - was received
|<2>| ASSERT: gnutls_record.c:695
|<2>| ASSERT: gnutls_record.c:1055
|<2>| ASSERT: ext_session_ticket.c:582
|<2>| ASSERT: gnutls_handshake.c:3146
ERR:EcoreCon ecore_con_ssl.c:455 _ecore_con_ssl_server_init_gnutls() Error at
ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:455! ERR:EcoreCon
ecore_con_ssl.c:468 _ecore_con_ssl_server_init_gnutls() gnutls returned with
error: GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
ERR:EcoreCon ecore_con_ssl.c:470 _ecore_con_ssl_server_init_gnutls() Also
received alert: Decrypt error ERR:EcoreCon ecore_con_ssl.c:471
_ecore_con_ssl_server_init_gnutls() last out: Finished ERR:EcoreCon
ecore_con_ssl.c:472 _ecore_con_ssl_server_init_gnutls() last in: Server hello
done |<2>| ASSERT: gnutls_record.c:262 ERR:EcoreCon ecore_con.c:1870
_ecore_con_cl_handler() ssl handshaking failed!


On Sat, 25 Sep 2010 09:02:00 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/25/2010 06:30 AM, Michael Blumenkrantz wrote:
> > Hi,
> > I am working on an asynchronous server/client api using gnutls, and there
> > are two things that are stumping me.  I have emailed you directly because
> > some of the information here I would prefer not to be public, though I
> > apologize if I have broken protocol in doing so.  My issues are as follows:
> 
> Hello,
>  I prefer having the mailing list CC for future reference and for
> someone to read when having similar problems.
I have CCed the mailing list now and removed all references to the data I
mentioned.

> > 1) asynchronous rehandshake detection
> > It seems that if a rehandshake request is sent, it is not possible to detect
> > this once I am at the point of calling gnutls_record_send?  As soon as I
> > get to this part, instead of not performing the send and returning
> > GNUTLS_E_REHANDSHAKE as expected, the data is actually sent and so my
> > client/server is lost. Is there a method of preventing this?
> 
> I don't quite understand. Is the case that you have a server that
> continuously sends, and you want to detect the GNUTLS_E_REHANDSHAKE?
> Couldn't you also recv() when you detect data in the input buffer?
The case I am talking about is simply running my server and then running
gnutls-cli -e on it to test a rehandshake.  I was more curious as to whether
there is a function to peak at the fd to see if a rehandshake request has just
been received, or something of that nature.


> > 2) certain cipher types don't seem to work at times
> > There are certain ssl servers which I do not seem to be able to connect to,
> > such as a mail server.  I have a small
> > client app which tests connections to a site, and I am unable to
> > successfully handshake with this server for some reason.  I am, however,
> > able to handshake using gnutls-cli.  After several days of googling and
> > trying to figure it out on my own, I have admitted defeat!  Attached are
> > two logs of trying to connect to the server - one for gnutls-cli and one
> > using the small client app and api that I have been working on.
> 
> I'd suggest that you start with a very basic client such as:
> http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support
> test if works and then try augmenting it for your needs. The fact that
> you get a decryption error is strange, it could mean that data were
> rearranged or straw bytes were inserted.
> 
> regards,
> Nikos
> 
My problem is that I am able to connect to all other types of servers with
whichever ciphers/macs/kx, and receiving/sending certificates works fine.  It is
just this one specific type of server which does not seem to work and I have no
idea why.
The code found at
https://svn.enlightenment.org/svn/e/trunk/ecore/src/lib/ecore_con/ecore_con_ssl.c
specifically the function _ecore_con_ssl_server_init_gnutls is where all of the
session/priority setup occurs.

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



From mike at zentific.com  Tue Sep 28 11:04:30 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Tue, 28 Sep 2010 05:04:30 -0400
Subject: ssl connection issues
Message-ID: <20100928050430.31da0423@darc.ath.cx>

Hi,

I figured I would mail again since I now have more specifics of the issue I am
experiencing as well as an easy way to replicate it.

I have a client which uses gnutls to connect to a specified url/port.  It
functions fine except for certain sites which I am having issues with.  An easy
public example site/port would be verisign.com:443 : I receive the following
output while trying to connect to it:


---CLIP---
|<4>| REC[0x8e92098]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x8e92098]: Received Packet[1] Handshake(22) with length: 4600
|<4>| REC[0x8e92098]: Decrypted Packet[1] Handshake(22) with length: 4600
|<3>| HSK[0x8e92098]: CERTIFICATE was received [4600 bytes]
|<4>| REC[0x8e92098]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[0x8e92098]: Received Packet[2] Handshake(22) with length: 525
|<4>| REC[0x8e92098]: Decrypted Packet[2] Handshake(22) with length: 525
|<3>| HSK[0x8e92098]: SERVER KEY EXCHANGE was received [525 bytes]
|<4>| REC[0x8e92098]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[0x8e92098]: Received Packet[3] Handshake(22) with length: 4
|<4>| REC[0x8e92098]: Decrypted Packet[3] Handshake(22) with length: 4
|<3>| HSK[0x8e92098]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1332
|<3>| HSK[0x8e92098]: CLIENT KEY EXCHANGE was sent [134 bytes]
|<4>| REC[0x8e92098]: Sending Packet[1] Handshake(22) with length: 134
|<4>| REC[0x8e92098]: Sent Packet[2] Handshake(22) with length: 139
|<3>| REC[0x8e92098]: Sent ChangeCipherSpec
|<4>| REC[0x8e92098]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<4>| REC[0x8e92098]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[128]:
ae66b9c2a926ed210333c81e128c70e9ac55523a3517a1710f60d9effcbc0bcd9892d056aee4250d2f75f0ac2f60b6954273e946fb317b36ef18079adcb0bc659d1be4b03cb460b10f764063f21e08ea061d297671d535082ac8f0001dbcf4ec38a6d27ac0952f694c85bd28e8dad07b3c8ac021018b0f2398ecf2a40e4c2c36
|<9>| INT: CLIENT RANDOM[32]:
4ca1ac45f1093f98c34ff5035ac6ab753d3c74e2e5d2d87747746c341c78ee58 |<9>| INT:
SERVER RANDOM[32]:
4ca1ac45546353c3983be7f19ee54ec13ba236289c1ac1bbf7453fb5af057ba8 |<9>| INT:
MASTER SECRET:
7033de0acd1303623adce0cfb76dd2ee34644df1aa03cf30923c6e2bc18d9407cb0bdc3d248d38a3f1f931a062e42096
|<9>| INT: KEY BLOCK[104]:
ae4bed619d78ae2f7f376553c2325dca9a9c90024df7947884e63e6454b6843c |<9>| INT:
CLIENT WRITE KEY [16]: 0b988001817dc84d08e950686542c730 |<9>| INT: SERVER WRITE
KEY [16]: a42051f0db4d07e6b4bc205262cc4b9a |<3>| HSK[0x8e92098]: Cipher Suite:
DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x8e92098]: Initializing internal [write]
cipher sessions |<3>| HSK[0x8e92098]: FINISHED was sent [16 bytes] |<4>|
REC[0x8e92098]: Sending Packet[0] Handshake(22) with length: 16 |<4>|
REC[0x8e92098]: Sent Packet[1] Handshake(22) with length: 53 |<2>| ASSERT:
ext_session_ticket.c:582
-----REPEAT-----
|<4>| REC[0x8e92098]: Expected Packet[4] Handshake(22) with length: 1
|<4>| REC[0x8e92098]: Received Packet[4] Alert(21) with length: 2
|<4>| REC[0x8e92098]: Decrypted Packet[4] Alert(21) with length: 2
|<4>| REC[0x8e92098]: Alert[2|51] - Decrypt error - was received
|<2>| ASSERT: gnutls_record.c:695
|<2>| ASSERT: gnutls_record.c:1055
|<2>| ASSERT: ext_session_ticket.c:582
|<2>| ASSERT: gnutls_handshake.c:3146
ERR:EcoreCon ecore_con_ssl.c:525 _ecore_con_ssl_server_init_gnutls() Error at
ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:525! ERR:EcoreCon
ecore_con_ssl.c:52 _gnutls_print_errors() gnutls returned with error:
GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
ERR:EcoreCon ecore_con_ssl.c:577 _ecore_con_ssl_server_init_gnutls() Also
received alert: Decrypt error ERR:EcoreCon ecore_con_ssl.c:580
_ecore_con_ssl_server_init_gnutls() last out: Finished ERR:EcoreCon
ecore_con_ssl.c:581 _ecore_con_ssl_server_init_gnutls() last in: Server hello
done |<2>| ASSERT: gnutls_record.c:262 ERR:EcoreCon ecore_con.c:1819
_ecore_con_cl_handler() ssl handshaking failed!

Included are some of the debug messages from gnutls error reporting functions.
I've spent a considerable amount of time trying to figure out the issue, but to
no success.  The relevant gnutls code is as follows, where error is a label
that prints all gnutls errors and exits the function:


#define SSL_ERROR_CHECK_GOTO_ERROR(X) \
do \
  { \
     if ((X)) \
       { \
          ERR("Error at %s:%s:%d!", __FILE__, __PRETTY_FUNCTION__, __LINE__); \
          goto error; \
       } \
  } \
while (0)

        int kx[] = { GNUTLS_KX_DHE_RSA, GNUTLS_KX_RSA, GNUTLS_KX_ANON_DH, 0 };
        int mixed_proto[] = { GNUTLS_VERSION_MAX, GNUTLS_TLS1_1, GNUTLS_TLS1_0,
        GNUTLS_SSL3, 0 }; 
        int compress[] = { GNUTLS_COMP_DEFLATE, GNUTLS_COMP_NULL, 0 }; 
        int cipher[] = { GNUTLS_CIPHER_AES_256_CBC, GNUTLS_CIPHER_AES_128_CBC,
        GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_DES_CBC, 0 };


        SSL_ERROR_CHECK_GOTO_ERROR(ret = gnutls_init(&svr->session,
        GNUTLS_CLIENT)); SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_set_default_priority(svr->session));
        SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_session_ticket_enable_client(svr->session));
        SSL_ERROR_CHECK_GOTO_ERROR(ret = gnutls_server_name_set(svr->session,
        GNUTLS_NAME_DNS, svr->name, strlen(svr->name)));

        SSL_ERROR_CHECK_GOTO_ERROR(ret = gnutls_credentials_set(svr->session,
        GNUTLS_CRD_CERTIFICATE, svr->cert)); SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_credentials_set(svr->session, GNUTLS_CRD_ANON, svr->anoncred_c));

        SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_cipher_set_priority(svr->session, cipher));
        SSL_ERROR_CHECK_GOTO_ERROR(ret = gnutls_kx_set_priority(svr->session,
        kx)); SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_protocol_set_priority(svr->session, proto));
        SSL_ERROR_CHECK_GOTO_ERROR(ret =
        gnutls_compression_set_priority(svr->session, compress));

        gnutls_dh_set_prime_bits(svr->session, 512);
        gnutls_transport_set_ptr(svr->session, (gnutls_transport_ptr_t)svr->fd);
        ret = gnutls_handshake(svr->session);


Hopefully someone will see something obvious that I have missed.
-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.



From nmav at gnutls.org  Tue Sep 28 11:30:29 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 28 Sep 2010 11:30:29 +0200
Subject: ssl connection issues
In-Reply-To: <20100928050430.31da0423@darc.ath.cx>
References: <20100928050430.31da0423@darc.ath.cx>
Message-ID: <AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>

On Tue, Sep 28, 2010 at 11:04 AM, Michael Blumenkrantz
<mike at zentific.com> wrote:
> Hi,
> I figured I would mail again since I now have more specifics of the issue I am
> experiencing as well as an easy way to replicate it.
> I have a client which uses gnutls to connect to a specified url/port. ?It
> functions fine except for certain sites which I am having issues with. ?An easy
> public example site/port would be verisign.com:443 : I receive the following
> output while trying to connect to it:

The code that you are using refers to a very old gnutls version. That
means you are messing with compatibility functions (such as the
priority functions you're using). If you cannot reproduce your problem
with gnutls-cli, as I told you before, read the examples from the
manual and base your client on those.

regards,
Nikos



From mike at zentific.com  Tue Sep 28 11:43:53 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Tue, 28 Sep 2010 05:43:53 -0400
Subject: ssl connection issues
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: <20100928054353.27e747bf@darc.ath.cx>

On Tue, 28 Sep 2010 11:30:29 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Tue, Sep 28, 2010 at 11:04 AM, Michael Blumenkrantz
> <mike at zentific.com> wrote:
> > Hi,
> > I figured I would mail again since I now have more specifics of the issue I
> > am experiencing as well as an easy way to replicate it.
> > I have a client which uses gnutls to connect to a specified url/port. ?It
> > functions fine except for certain sites which I am having issues with. ?An
> > easy public example site/port would be verisign.com:443 : I receive the
> > following output while trying to connect to it:
> 
> The code that you are using refers to a very old gnutls version. That
> means you are messing with compatibility functions (such as the
> priority functions you're using). If you cannot reproduce your problem
> with gnutls-cli, as I told you before, read the examples from the
> manual and base your client on those.
> 
> regards,
> Nikos
Which code specifically is old?  Should I be using gnutls_priority_set_direct
now instead of the other priority functions?

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



From nmav at gnutls.org  Tue Sep 28 17:56:30 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 28 Sep 2010 17:56:30 +0200
Subject: ssl connection issues
In-Reply-To: <20100928054353.27e747bf@darc.ath.cx>
References: <20100928050430.31da0423@darc.ath.cx>	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
	<20100928054353.27e747bf@darc.ath.cx>
Message-ID: <4CA2102E.9080104@gnutls.org>

On 09/28/2010 11:43 AM, Michael Blumenkrantz wrote:

> Which code specifically is old?  Should I be using gnutls_priority_set_direct
> now instead of the other priority functions?

That's what I noticed. Probably other functions as well. Check the examples.


regards,
Nikos






From mike at zentific.com  Wed Sep 29 15:15:15 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Wed, 29 Sep 2010 09:15:15 -0400
Subject: ssl connection issues
In-Reply-To: <4CA2102E.9080104@gnutls.org>
References: <20100928050430.31da0423@darc.ath.cx>
	<AANLkTiktx5+Ro6Am+28Wbm_-X6MSYyfX5p-uA3U2qKeK@mail.gmail.com>
	<20100928054353.27e747bf@darc.ath.cx> <4CA2102E.9080104@gnutls.org>
Message-ID: <20100929091515.7ab9aae2@darc.ath.cx>

On Tue, 28 Sep 2010 17:56:30 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/28/2010 11:43 AM, Michael Blumenkrantz wrote:
> 
> > Which code specifically is old?  Should I be using
> > gnutls_priority_set_direct now instead of the other priority functions?
> 
> That's what I noticed. Probably other functions as well. Check the examples.
> 
> 
> regards,
> Nikos
> 
> 
> 
I have read through the examples and tested using my code.  It functions fine,
though I took your advice and migrated to newer priority strings.  It seems
that I may have found a gnutls bug in handshaking, however, though I will
reserve judgment on that until I have investigated further.  The bug seems to
be if you are doing async connections, you cannot call gnutls_handshake with a
very small amount of data in the buffer or else the handshake will fail with an
error.  Specifically, I find this occurring while receiving data (as a client)
for a session ticket.

I have so far found this to be the case by briefly pausing execution of my
program just before the gnutls_handshake() call where it would be reading from
the file descriptor so that more data can accumulate, and then continuing.  The
handshake completes as expected, where it would have failed if running at
normal speed.

Is it possible that there is a bug like this?

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



From nmav at gnutls.org  Wed Sep 29 16:04:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 29 Sep 2010 16:04:21 +0200
Subject: ssl connection issues
In-Reply-To: <20100929091515.7ab9aae2@darc.ath.cx>
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>
Message-ID: <AANLkTinw1hesAptVEy23kgN=+fub-FXxgc=Fb760x3HS@mail.gmail.com>

On Wed, Sep 29, 2010 at 3:15 PM, Michael Blumenkrantz <mike at zentific.com> wrote:

> I have read through the examples and tested using my code. ?It functions fine,
> though I took your advice and migrated to newer priority strings. ?It seems
> that I may have found a gnutls bug in handshaking, however, though I will
> reserve judgment on that until I have investigated further. ?The bug seems to
> be if you are doing async connections, you cannot call gnutls_handshake with a
> very small amount of data in the buffer or else the handshake will fail with an
> error. ?Specifically, I find this occurring while receiving data (as a client)
> for a session ticket.
> I have so far found this to be the case by briefly pausing execution of my
> program just before the gnutls_handshake() call where it would be reading from
> the file descriptor so that more data can accumulate, and then continuing. ?The
> handshake completes as expected, where it would have failed if running at
> normal speed.

Where does handshake fail? (if you use level 2 debugging you get a
nice backtrace of the
failure).

> Is it possible that there is a bug like this?

You never know, although I think gnutls is being used in async mode quite often.

regards,
Nikos



From mike at zentific.com  Wed Sep 29 16:22:29 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Wed, 29 Sep 2010 10:22:29 -0400
Subject: ssl connection issues
In-Reply-To: <AANLkTinw1hesAptVEy23kgN=+fub-FXxgc=Fb760x3HS@mail.gmail.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>
Message-ID: <20100929102229.64224bb5@darc.ath.cx>

On Wed, 29 Sep 2010 16:04:21 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Wed, Sep 29, 2010 at 3:15 PM, Michael Blumenkrantz <mike at zentific.com>
> wrote:
> 
> > I have read through the examples and tested using my code. ?It functions
> > fine, though I took your advice and migrated to newer priority strings. ?It
> > seems that I may have found a gnutls bug in handshaking, however, though I
> > will reserve judgment on that until I have investigated further. ?The bug
> > seems to be if you are doing async connections, you cannot call
> > gnutls_handshake with a very small amount of data in the buffer or else the
> > handshake will fail with an error. ?Specifically, I find this occurring
> > while receiving data (as a client) for a session ticket.
> > I have so far found this to be the case by briefly pausing execution of my
> > program just before the gnutls_handshake() call where it would be reading
> > from the file descriptor so that more data can accumulate, and then
> > continuing. ?The handshake completes as expected, where it would have
> > failed if running at normal speed.
> 
> Where does handshake fail? (if you use level 2 debugging you get a
> nice backtrace of the
> failure).
> 
> > Is it possible that there is a bug like this?
> 
> You never know, although I think gnutls is being used in async mode quite
> often.
> 
> regards,
> Nikos

This is a log of the handshake failure while attempting to connect to verisign.com:443 using gnutls log level 2.  Additionally there is some debug info from my code which is prefixed by DBG.  Let me know if there is more information that I can provide.

DBG:EcoreCon ecore_con.c:1478 _ecore_con_cb_tcp_connect() beginning ssl handshake
DBG:EcoreCon ecore_con_ssl.c:497 _ecore_con_ssl_server_init_gnutls() calling gnutls_handshake()
|<2>| EXT[0x8d460b8]: Sending extension SERVER_NAME
|<2>| EXT[0x8d460b8]: Sending extension SAFE_RENEGOTIATION
|<2>| EXT[0x8d460b8]: Sending extension SESSION_TICKET
|<2>| ASSERT: gnutls_record.c:450
|<2>| ASSERT: gnutls_buffers.c:933
|<2>| ASSERT: gnutls_buffers.c:957
|<2>| ASSERT: gnutls_handshake.c:2772
DBG:EcoreCon ecore_con.c:1822 _ecore_con_cl_handler() Continuing ssl handshake
DBG:EcoreCon ecore_con.c:1826 _ecore_con_cl_handler() Preparing to write handshake data...
DBG:EcoreCon ecore_con_ssl.c:497 _ecore_con_ssl_server_init_gnutls() calling gnutls_handshake()
|<2>| ASSERT: gnutls_buffers.c:857
DBG:EcoreCon ecore_con.c:1822 _ecore_con_cl_handler() Continuing ssl handshake
DBG:EcoreCon ecore_con.c:1826 _ecore_con_cl_handler() Preparing to write handshake data...
DBG:EcoreCon ecore_con_ssl.c:497 _ecore_con_ssl_server_init_gnutls() calling gnutls_handshake()
---REPEAT---
|<2>| EXT[0x8d460b8]: Found extension 'SAFE_RENEGOTIATION/65281'
|<2>| EXT[0x8d460b8]: Found extension 'SESSION_TICKET/35'
|<2>| ASSERT: gnutls_handshake.c:1332
|<2>| ASSERT: ext_session_ticket.c:582
DBG:EcoreCon ecore_con.c:1822 _ecore_con_cl_handler() Continuing ssl handshake
DBG:EcoreCon ecore_con.c:1826 _ecore_con_cl_handler() Preparing to write handshake data...
DBG:EcoreCon ecore_con_ssl.c:497 _ecore_con_ssl_server_init_gnutls() calling gnutls_handshake()
---REPEAT---
|<2>| ASSERT: gnutls_record.c:695
|<2>| ASSERT: gnutls_record.c:1055
|<2>| ASSERT: ext_session_ticket.c:582
|<2>| ASSERT: gnutls_handshake.c:3146
ERR:EcoreCon ecore_con_ssl.c:499 _ecore_con_ssl_server_init_gnutls() Error at ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:499!
ERR:EcoreCon ecore_con_ssl.c:52 _gnutls_print_errors() gnutls returned with error: GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
ERR:EcoreCon ecore_con_ssl.c:551 _ecore_con_ssl_server_init_gnutls() Also received alert: Decrypt error
ERR:EcoreCon ecore_con_ssl.c:554 _ecore_con_ssl_server_init_gnutls() last out: Finished
ERR:EcoreCon ecore_con_ssl.c:555 _ecore_con_ssl_server_init_gnutls() last in: Server hello done
|<2>| ASSERT: gnutls_record.c:262


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



From nmav at gnutls.org  Wed Sep 29 16:36:19 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 29 Sep 2010 16:36:19 +0200
Subject: ssl connection issues
In-Reply-To: <20100929102229.64224bb5@darc.ath.cx>
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>
Message-ID: <4CA34EE3.1050007@gnutls.org>

On 09/29/2010 04:22 PM, Michael Blumenkrantz wrote:

> This is a log of the handshake failure while attempting to connect to verisign.com:443 using gnutls log level 2.  Additionally there is some debug info from my code which is prefixed by DBG.  Let me know if there is more information that I can provide.
> ERR:EcoreCon ecore_con_ssl.c:499 _ecore_con_ssl_server_init_gnutls() Error at ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:499!
> ERR:EcoreCon ecore_con_ssl.c:52 _gnutls_print_errors() gnutls returned with error: GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
> ERR:EcoreCon ecore_con_ssl.c:551 _ecore_con_ssl_server_init_gnutls() Also received alert: Decrypt error
> ERR:EcoreCon ecore_con_ssl.c:554 _ecore_con_ssl_server_init_gnutls() last out: Finished
> ERR:EcoreCon ecore_con_ssl.c:555 _ecore_con_ssl_server_init_gnutls() last in: Server hello done
> |<2>| ASSERT: gnutls_record.c:262

I cannot see any problem here. The peer is sending a fatal alert because
something he received was in error. Could it be an issue in your send
function?

regards,
Nikos





From mike at zentific.com  Wed Sep 29 16:48:45 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Wed, 29 Sep 2010 10:48:45 -0400
Subject: ssl connection issues
In-Reply-To: <4CA34EE3.1050007@gnutls.org>
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>
Message-ID: <20100929104845.41ec97e5@darc.ath.cx>

On Wed, 29 Sep 2010 16:36:19 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/29/2010 04:22 PM, Michael Blumenkrantz wrote:
> 
> > This is a log of the handshake failure while attempting to connect to
> > verisign.com:443 using gnutls log level 2.  Additionally there is some
> > debug info from my code which is prefixed by DBG.  Let me know if there is
> > more information that I can provide. ERR:EcoreCon ecore_con_ssl.c:499
> > _ecore_con_ssl_server_init_gnutls() Error at
> > ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:499! ERR:EcoreCon
> > ecore_con_ssl.c:52 _gnutls_print_errors() gnutls returned with error:
> > GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
> > ERR:EcoreCon ecore_con_ssl.c:551 _ecore_con_ssl_server_init_gnutls() Also
> > received alert: Decrypt error ERR:EcoreCon ecore_con_ssl.c:554
> > _ecore_con_ssl_server_init_gnutls() last out: Finished ERR:EcoreCon
> > ecore_con_ssl.c:555 _ecore_con_ssl_server_init_gnutls() last in: Server
> > hello done |<2>| ASSERT: gnutls_record.c:262
> 
> I cannot see any problem here. The peer is sending a fatal alert because
> something he received was in error. Could it be an issue in your send
> function?
> 
> regards,
> Nikos
> 
> 
If that were the case, wouldn't it also fail when I have paused execution as I
described previously?  Additionally, the only function that is sending data on
that socket during that time is gnutls_handshake.

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



From nmav at gnutls.org  Wed Sep 29 17:17:56 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 29 Sep 2010 17:17:56 +0200
Subject: ssl connection issues
In-Reply-To: <20100929104845.41ec97e5@darc.ath.cx>
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>
Message-ID: <4CA358A4.3050807@gnutls.org>

On 09/29/2010 04:48 PM, Michael Blumenkrantz wrote:

> If that were the case, wouldn't it also fail when I have paused execution as I
> described previously?  Additionally, the only function that is sending data on
> that socket during that time is gnutls_handshake.

I can only speculate as I cannot reproduce the issue. If you think you
know how to reproduce it, check mini-egain example, and see whether you
can emulate the behavior you're seeing there.

To the point. As I see the problem is not on receiving. This happens
normally as I see from your log. Check with wireshark and other ways
that the send is occuring as it should.

regards,
Nikos



From mike at zentific.com  Wed Sep 29 21:06:27 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Wed, 29 Sep 2010 15:06:27 -0400
Subject: ssl connection issues
In-Reply-To: <4CA358A4.3050807@gnutls.org>
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>
Message-ID: <20100929150627.6513899e@darc.ath.cx>

On Wed, 29 Sep 2010 17:17:56 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/29/2010 04:48 PM, Michael Blumenkrantz wrote:
> 
> > If that were the case, wouldn't it also fail when I have paused execution
> > as I described previously?  Additionally, the only function that is sending
> > data on that socket during that time is gnutls_handshake.
> 
> I can only speculate as I cannot reproduce the issue. If you think you
> know how to reproduce it, check mini-egain example, and see whether you
> can emulate the behavior you're seeing there.
> 
> To the point. As I see the problem is not on receiving. This happens
> normally as I see from your log. Check with wireshark and other ways
> that the send is occuring as it should.
> 
> regards,
> Nikos
Hmm I have spent some time working on a very tiny async app using gnutls.  It
utilizes a single callback to handshake and then disconnect from a server, as I
will describe later.  In my testing with this, however, I uncovered a larger
and previously unknown bug in pre-existing software which I have now begun the
long task of attempting to fix.  Thank you for your advice.

In thanks, I have written and documented a small test program (attached) which
performs an asynchronous remote connection to verisign.com (an easy site to
find that has an ssl certificate).  It requires eina and ecore from the
EFL/enlightenment.org to compile/run, but should serve as a good standalone
reading example to include since it is well-commented and short (11
gnutls calls, 3 ecore calls total).  Feel free to modify/redistribute if you
would like, with or without attribution.  I hope you find it useful.

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eagain-cli.c
Type: text/x-c++src
Size: 5254 bytes
Desc: not available
URL: </pipermail/attachments/20100929/51b9fbb8/attachment.cc>

From mike at zentific.com  Wed Sep 29 23:35:14 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Wed, 29 Sep 2010 17:35:14 -0400
Subject: ssl connection issues
In-Reply-To: <20100929150627.6513899e@darc.ath.cx>
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>
Message-ID: <20100929173514.20da21a3@darc.ath.cx>

On Wed, 29 Sep 2010 15:06:27 -0400
Michael Blumenkrantz <mike at zentific.com> wrote:

> On Wed, 29 Sep 2010 17:17:56 +0200
> Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> 
> > On 09/29/2010 04:48 PM, Michael Blumenkrantz wrote:
> > 
> > > If that were the case, wouldn't it also fail when I have paused execution
> > > as I described previously?  Additionally, the only function that is
> > > sending data on that socket during that time is gnutls_handshake.
> > 
> > I can only speculate as I cannot reproduce the issue. If you think you
> > know how to reproduce it, check mini-egain example, and see whether you
> > can emulate the behavior you're seeing there.
> > 
> > To the point. As I see the problem is not on receiving. This happens
> > normally as I see from your log. Check with wireshark and other ways
> > that the send is occuring as it should.
> > 
> > regards,
> > Nikos
> Hmm I have spent some time working on a very tiny async app using gnutls.  It
> utilizes a single callback to handshake and then disconnect from a server, as
> I will describe later.  In my testing with this, however, I uncovered a larger
> and previously unknown bug in pre-existing software which I have now begun the
> long task of attempting to fix.  Thank you for your advice.
> 
> In thanks, I have written and documented a small test program (attached) which
> performs an asynchronous remote connection to verisign.com (an easy site to
> find that has an ssl certificate).  It requires eina and ecore from the
> EFL/enlightenment.org to compile/run, but should serve as a good standalone
> reading example to include since it is well-commented and short (11
> gnutls calls, 3 ecore calls total).  Feel free to modify/redistribute if you
> would like, with or without attribution.  I hope you find it useful.
> 
As it turns out, in an amusing accident I sent you a "mostly finished" version
of the file which is not async.  Attached is the actual async example.

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eagain-cli.c
Type: text/x-c++src
Size: 5461 bytes
Desc: not available
URL: </pipermail/attachments/20100929/f3ccede6/attachment.cc>

From mike at zentific.com  Thu Sep 30 09:10:55 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Thu, 30 Sep 2010 03:10:55 -0400
Subject: ssl connection issues
In-Reply-To: <20100929173514.20da21a3@darc.ath.cx>
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>
Message-ID: <20100930031055.4c133304@darc.ath.cx>

On Wed, 29 Sep 2010 17:35:14 -0400
Michael Blumenkrantz <mike at zentific.com> wrote:

> On Wed, 29 Sep 2010 15:06:27 -0400
> Michael Blumenkrantz <mike at zentific.com> wrote:
> 
> > On Wed, 29 Sep 2010 17:17:56 +0200
> > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > 
> > > On 09/29/2010 04:48 PM, Michael Blumenkrantz wrote:
> > > 
> > > > If that were the case, wouldn't it also fail when I have paused
> > > > execution as I described previously?  Additionally, the only function
> > > > that is sending data on that socket during that time is
> > > > gnutls_handshake.
> > > 
> > > I can only speculate as I cannot reproduce the issue. If you think you
> > > know how to reproduce it, check mini-egain example, and see whether you
> > > can emulate the behavior you're seeing there.
> > > 
> > > To the point. As I see the problem is not on receiving. This happens
> > > normally as I see from your log. Check with wireshark and other ways
> > > that the send is occuring as it should.
> > > 
> > > regards,
> > > Nikos
> > Hmm I have spent some time working on a very tiny async app using gnutls.
> > It utilizes a single callback to handshake and then disconnect from a
> > server, as I will describe later.  In my testing with this, however, I
> > uncovered a larger and previously unknown bug in pre-existing software
> > which I have now begun the long task of attempting to fix.  Thank you for
> > your advice.
> > 
> > In thanks, I have written and documented a small test program (attached)
> > which performs an asynchronous remote connection to verisign.com (an easy
> > site to find that has an ssl certificate).  It requires eina and ecore from
> > the EFL/enlightenment.org to compile/run, but should serve as a good
> > standalone reading example to include since it is well-commented and short
> > (11 gnutls calls, 3 ecore calls total).  Feel free to modify/redistribute
> > if you would like, with or without attribution.  I hope you find it useful.
> > 
> As it turns out, in an amusing accident I sent you a "mostly finished" version
> of the file which is not async.  Attached is the actual async example.
> 
As it turns out, I have fixed the bug which I found from this but it did not
fix my gnutls problem (though it has made it easier to read the logs).  I have
uploaded the logs to avoid having a giant email message.  They can be found
here:

functioning log from example I sent to mailing list: http://www.zentific.com/files/example.log
nonfunctioning log from internal code: http://www.zentific.com/files/ecore.log

This is the internal code relevant to gnutls in the exact order that it is called:

gnutls_certificate_allocate_credentials(&svr->cert);
gnutls_anon_allocate_client_credentials(&svr->anoncred_c);
gnutls_init(&svr->session, GNUTLS_CLIENT);
gnutls_session_ticket_enable_client(svr->session);
gnutls_server_name_set(svr->session, GNUTLS_NAME_DNS, svr->name, strlen(svr->name));
gnutls_priority_set_direct(svr->session, "NONE:%VERIFY_ALLOW_X509_V1_CA_CRT:+RSA:+DHE-RSA:+DHE-DSS:+ANON-DH:+COMP-DEFLATE:+COMP-NULL:+CTYPE-X509:+SHA1:+SHA256:+SHA384:+SHA512:+AES-256-CBC:+AES-128-CBC:+3DES-CBC:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+VERS-SSL3.0", NULL);
gnutls_credentials_set(svr->session, GNUTLS_CRD_CERTIFICATE, svr->cert);
gnutls_credentials_set(svr->session, GNUTLS_CRD_ANON, svr->anoncred_c);
gnutls_dh_set_prime_bits(svr->session, 512;
gnutls_transport_set_ptr(svr->session, (gnutls_transport_ptr_t)svr->fd);

/* this is called in an event handler from select() on svr->fd */
gnutls_handshake(svr->session);


As far as I can tell, the gnutls code is the same. Wireshark reports that all the bytes supposedly sent have been sent as far as I am able to tell, though I have also uploaded wireshark logs (in wireshark reading format) for each connection attempt:

http://www.zentific.com/files/ecore_wireshark.log
http://www.zentific.com/files/example_wireshark.log

The underlying code for the version that does not work is identical as well; the socket gets the event from select() and immediately calls gnutls_handshake() again just as in the example.  As mentioned before, any type of slowdown during the execution of the ecore (nonfunctioning) code will allow it to succeed somehow, so this must be a timing issue somewhere.  Additionally, I have tested disabling O_NONBLOCK with the ecore (nonfunctioning) code and verified that it does connect correctly then.

I am out of ideas here, so I have attempted to provide as much info as possible so that perhaps someone will see something that I have missed, or at least point me in the direction to provide more information.  I am currently in the process of setting up a local apache test server to debug from the server side and attempt to pinpoint the error since it is the only course of action that I can think of.

Please help! :)
-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.



From simon at josefsson.org  Thu Sep 30 11:13:09 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 30 Sep 2010 11:13:09 +0200
Subject: GnuTLS 2.10.2 released
Message-ID: <87zkuzd26y.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.10.2.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

The project page of the library is available at:
  http://www.gnu.org/software/gnutls/

What's New
==========

** Use Libtool 2.2.10 to ease MinGW64 builds.

** libgnutls: Add new extended key usage ipsecIKE.

** libgnutls: Is now more liberal in the PEM decoding.
That is spaces and tabs are being skipped.

** libgnutls: Renamed NULL MAC to MAC-NULL to prevent clash with NULL cipher.
This prevented the usage of the TLS ciphersuites with NULL cipher.
See <http://thread.gmane.org/gmane.network.gnutls.general/2093>.

** libgnutls: The %COMPAT flag now allows larger records that violate the
TLS spec.

** libgnutls: Fix asynchronous API handling.
The code was clearing session hash data on EAGAIN.  Problem reported
by Sjoerd Simons <sjoerd.simons at collabora.co.uk> and Vivek
Dasmohapatra <vivek at collabora.co.uk>.  See
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4531>.

** gnutls-cli: Flush stdout/stderr before removing buffering.
Reported by Knut Anders Hatlen see
<http://savannah.gnu.org/support/?107481>.

** 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 (7.2MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.10.2.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2011-03-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

2704b7b86fc5e3444afcf20feb7bc9ff117d4816  gnutls-2.10.2.tar.bz2

d0a6c3f658da5dd6c74d9cf24ddf4b2b6bb4dd73c28d64c4053997c9  gnutls-2.10.2.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html
  PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The versions included
are libgpg-error v1.8, libgcrypt v1.4.6, and GnuTLS v2.10.2.

New in this release is that we have changed build environment for the
Windows builds.  We are now using MinGW-w64 from
<http://mingw-w64.sourceforge.net/> built with GCC 4.5.1.  The Windows
build scripts reside in:

  http://cvs.savannah.gnu.org/viewvc/windows-build-scripts/?root=gnutls

The Windows binary installer (16MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.exe
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.exe

The OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.exe.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.exe.sig

The checksum values for SHA-1 and SHA-224 are:

6f402bb6babb3aae591c76bde1bfd48e60d21100  gnutls-2.10.2-x86.exe

589c2fcf412836907df4057945bc4d43b6da337a62f3771121f5b31d  gnutls-2.10.2-x86.exe

A ZIP archive with Windows binaries (5.8MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.zip
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.zip

The OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.zip.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2-x86.zip.sig

The checksum values for SHA-1 and SHA-224 are:

d0dd205e4c30c04fbffe7cf1b6556a18571a5e91  gnutls-2.10.2-x86.zip

bda8bbe2a5059e2ccb452d4a8082d80944779ea3ef734fc3f43aac68  gnutls-2.10.2-x86.zip

A Debian mingw32 package is also available (5.4MB):

  ftp://ftp.gnu.org/gnu/gnutls/mingw32-gnutls_2.10.2-1_all.deb
  http://ftp.gnu.org/gnu/gnutls/mingw32-gnutls_2.10.2-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

925cdb8e1c4b0e7c462a4ad0b01a2f80f3d2537c  mingw32-gnutls_2.10.2-1_all.deb

807d26b8d3f458ac8352481c262c188d1d842573fea5b2986121c0dd  mingw32-gnutls_2.10.2-1_all.deb

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, Swedish,
and Vietnamese.  We welcome the addition of more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100930/56b6b3ae/attachment.pgp>

From nmav at gnutls.org  Thu Sep 30 11:52:00 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Sep 2010 11:52:00 +0200
Subject: ssl connection issues
In-Reply-To: <20100930031055.4c133304@darc.ath.cx>
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>
Message-ID: <AANLkTi=iO5jdd2vi7F7HS=0nK7aQJTgABRaduRS_n81K@mail.gmail.com>

On Thu, Sep 30, 2010 at 9:10 AM, Michael Blumenkrantz <mike at zentific.com> wrote:
> As it turns out, I have fixed the bug which I found from this but it did not
> fix my gnutls problem (though it has made it easier to read the logs). ?I have
> uploaded the logs to avoid having a giant email message. ?They can be found
> here:

I'll try to check it this evening. However does you problem persist
with the just released
gnutls 2.10.2? It has some fixes for asynchronous use.

regards,
Nikos



From nmav at gnutls.org  Thu Sep 30 15:37:03 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Sep 2010 15:37:03 +0200
Subject: ssl connection issues
In-Reply-To: <20100929173514.20da21a3@darc.ath.cx>
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>
Message-ID: <4CA4927F.4040500@gnutls.org>

On 09/29/2010 11:35 PM, Michael Blumenkrantz wrote:

> As it turns out, in an amusing accident I sent you a "mostly finished" version
> of the file which is not async.  Attached is the actual async example.

I'm curious what are the ecore.h and ecore calls. Is that from a library
we can use?

regards,
Nikos



From mike at zentific.com  Thu Sep 30 20:56:58 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Thu, 30 Sep 2010 14:56:58 -0400
Subject: ssl connection issues
In-Reply-To: <4CA4927F.4040500@gnutls.org>
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> <4CA4927F.4040500@gnutls.org>
Message-ID: <20100930145658.7fba2762@darc.ath.cx>

On Thu, 30 Sep 2010 15:37:03 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/29/2010 11:35 PM, Michael Blumenkrantz wrote:
> 
> > As it turns out, in an amusing accident I sent you a "mostly finished"
> > version of the file which is not async.  Attached is the actual async
> > example.
> 
> I'm curious what are the ecore.h and ecore calls. Is that from a library
> we can use?
> 
> regards,
> Nikos
Yes, it's part of the open source Enlightenment Foundation Libraries for which
I am a contributor. There is more information here:
http://enlightenment.org/p.php?p=about&l=en

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



From mike at zentific.com  Thu Sep 30 21:32:06 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Thu, 30 Sep 2010 15:32:06 -0400
Subject: ssl connection issues
In-Reply-To: <AANLkTi=iO5jdd2vi7F7HS=0nK7aQJTgABRaduRS_n81K@mail.gmail.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>
Message-ID: <20100930153206.443ef7ce@darc.ath.cx>

On Thu, 30 Sep 2010 11:52:00 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Thu, Sep 30, 2010 at 9:10 AM, Michael Blumenkrantz <mike at zentific.com>
> wrote:
> > As it turns out, I have fixed the bug which I found from this but it did not
> > fix my gnutls problem (though it has made it easier to read the logs). ?I
> > have uploaded the logs to avoid having a giant email message. ?They can be
> > found here:
> 
> I'll try to check it this evening. However does you problem persist
> with the just released
> gnutls 2.10.2? It has some fixes for asynchronous use.
> 
> regards,
> Nikos
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.

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



From nmav at gnutls.org  Thu Sep 30 22:12:54 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Sep 2010 22:12:54 +0200
Subject: ssl connection issues
In-Reply-To: <20100930153206.443ef7ce@darc.ath.cx>
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>
Message-ID: <4CA4EF46.3030907@gnutls.org>

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



From nmav at gnutls.org  Thu Sep 30 22:15:59 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Sep 2010 22:15:59 +0200
Subject: ssl connection issues
In-Reply-To: <20100930145658.7fba2762@darc.ath.cx>
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>	<4CA4927F.4040500@gnutls.org>
	<20100930145658.7fba2762@darc.ath.cx>
Message-ID: <4CA4EFFF.9020204@gnutls.org>

On 09/30/2010 08:56 PM, Michael Blumenkrantz wrote:

>> I'm curious what are the ecore.h and ecore calls. Is that from a library
>> we can use?
>>
>> regards,
>> Nikos
> Yes, it's part of the open source Enlightenment Foundation Libraries for which
> I am a contributor. There is more information here:
> http://enlightenment.org/p.php?p=about&l=en

Could it be self contained so I can include in the test applications? I
mean could it be 1-2 files from ecore we could use to make it self
contained?

regards,
Nikos





From mike at zentific.com  Thu Sep 30 22:25:46 2010
From: mike at zentific.com (Michael Blumenkrantz)
Date: Thu, 30 Sep 2010 16:25:46 -0400
Subject: ssl connection issues
In-Reply-To: <4CA4EF46.3030907@gnutls.org>
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>
Message-ID: <20100930162546.1d11130b@darc.ath.cx>

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.

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