From simon at josefsson.org  Mon Jun  1 10:04:35 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 01 Jun 2009 10:04:35 +0200
Subject: [Help-gnutls] Re: GnuTLS 2.8.0
In-Reply-To: <1243833993.4273.1.camel@mvp> (Jeff Cai's message of "Mon, 01 Jun
	2009 13:26:33 +0800")
References: <878wkhabs7.fsf@mocca.josefsson.org> <1243833993.4273.1.camel@mvp>
Message-ID: <87my8ss7l8.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> I can not find the COPYING.LIB in the source tarball. 

It is in lib/COPYING.

/Simon




From simon at josefsson.org  Mon Jun  1 11:15:15 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 01 Jun 2009 11:15:15 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <4A2194AE.4040006@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Sat, 30 May 2009 16:18:54 -0400")
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
Message-ID: <87ws7wqpr0.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 05/30/2009 03:03 PM, Roland Winkler wrote:
>> I am sorry for my ignorance. Is this something I can do locally, or
>> is this a command that I need to run on the remote SMTP server I am
>> trying to contact? If I can run this command locally, how do I
>> specify the remote server? Is there anything else I can do locally?
>> (I've made gnutls-cli more verbose and it gave me a lot of
>> information, though in the end nothing appeared useful to me to
>> resolve this problem.)
>
> You can try this:
>
> echo QUIT | gnutls-cli --print-cert --starttls --port 25 foo.bar.com
>
>
> If that doesn't work (i'm having difficulty getting it to behave as i
> would expect right now)

gnutls-cli doesn't understand SMTP, so you would have to do:

gnutls-cli --print-cert --starttls --port 25 foo.bar.com
...
STARTTLS
^D
...

Where ^D is control-d (i.e., EOF).  On Windows, it is ^Z.

/Simon




From simon at josefsson.org  Mon Jun  1 11:18:07 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 01 Jun 2009 11:18:07 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <18978.40674.253965.602796@tfkp07.physik.uni-erlangen.de> (Roland
	Winkler's message of "Sun, 31 May 2009 17:14:42 +0200")
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
	<20090531083922.1725e860@nmav-eee>
	<18978.40674.253965.602796@tfkp07.physik.uni-erlangen.de>
Message-ID: <87skikqpm8.fsf@mocca.josefsson.org>

"Roland Winkler" <Roland.Winkler at physik.uni-erlangen.de> writes:

>> By misconfiguration however the server allows you to connect with
>> a ciphersuite that violates this usage and that's why gnutls-cli
>> fails to connect.
>
> Is this a misconfiguration of the server that its sysadmins can fix?

Yes.  They can chose between:

1) Disable DHE ciphersuite, because their certificate doesn't permit
those.

2) Re-generate the certificate and add the sign key usage, which allows
use of the certificate together with DHE.

> Is it a part of the communication protocol between server and client
> that the server should tell the client the allowed usage of its
> certificate? I mean, the server knows the allowed usage of its
> certificate. So I would guess that in an ideal world (that we don't
> have...) no extra configuration of the server was necessary.

Right.  The server software could also detect that the certificate does
not support signing, and then disable all DHE/EXPORT ciphersuites.

/Simon




From Roland.Winkler at physik.uni-erlangen.de  Mon Jun  1 17:46:37 2009
From: Roland.Winkler at physik.uni-erlangen.de (Roland Winkler)
Date: Mon, 1 Jun 2009 17:46:37 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <87skikqpm8.fsf@mocca.josefsson.org>
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
	<20090531083922.1725e860@nmav-eee>
	<18978.40674.253965.602796@tfkp07.physik.uni-erlangen.de>
	<87skikqpm8.fsf@mocca.josefsson.org>
Message-ID: <18979.63453.56283.250929@tfkp07.physik.uni-erlangen.de>

On Mon Jun 1 2009 Simon Josefsson wrote:
> Yes.  They can chose between:
> 
> 1) Disable DHE ciphersuite, because their certificate doesn't permit
> those.
> 
> 2) Re-generate the certificate and add the sign key usage, which allows
> use of the certificate together with DHE.
> 
> > Is it a part of the communication protocol between server and client
> > that the server should tell the client the allowed usage of its
> > certificate? I mean, the server knows the allowed usage of its
> > certificate. So I would guess that in an ideal world (that we don't
> > have...) no extra configuration of the server was necessary.
> 
> Right.  The server software could also detect that the certificate does
> not support signing, and then disable all DHE/EXPORT ciphersuites.


Thanks for the clarifications!

Roland




From dkg at fifthhorseman.net  Mon Jun  1 19:10:45 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Jun 2009 13:10:45 -0400
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <87ws7wqpr0.fsf@mocca.josefsson.org>
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>	<4A2171F4.4010800@gnutls.org>	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>	<4A2194AE.4040006@fifthhorseman.net>
	<87ws7wqpr0.fsf@mocca.josefsson.org>
Message-ID: <4A240B95.2080205@fifthhorseman.net>

On 06/01/2009 05:15 AM, Simon Josefsson wrote:
> gnutls-cli doesn't understand SMTP, so you would have to do:
> 
> gnutls-cli --print-cert --starttls --port 25 foo.bar.com
> ...
> STARTTLS
> ^D
> ...
> 
> Where ^D is control-d (i.e., EOF).  On Windows, it is ^Z.

Thanks for the clarification, Simon.  This works for me, and i'd never
gotten around to figuring it out.  Very useful!

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090601/27758fed/attachment.pgp>

From dkg at fifthhorseman.net  Mon Jun  1 22:41:37 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Jun 2009 16:41:37 -0400
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>	<4A2171F4.4010800@gnutls.org>	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
Message-ID: <4A243D01.6020309@fifthhorseman.net>

On 05/30/2009 07:05 PM, Roland Winkler wrote:

> 		Unknown extension 2.16.840.1.113730.1.13 (not critical):
> 			ASCII: .!YaST Generated Server Certificate
> 			Hexdump: 1621596153542047656e65726174656420536572766572204365727469666963617465
 [...]
> 		Key Usage (not critical):
> 			Key encipherment.

this looks to have been created by YaST, and it seems to be set up
oddly: RFC 5280 suggests that the keyUsage extension SHOULD be critical,
and if the service was configured (maybe also by YaST), it should maybe
have been configured to match.

I've opened https://bugzilla.novell.com/show_bug.cgi?id=508844 to
suggest that YaST should behave differently.  Roland, if you can follow
up there with more details about how the cert in question was created
and how the service was configured, we might be able to prevent this
from tripping up other folks in the future.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090601/8db664a6/attachment.pgp>

From tomas.kukosa at siemens-enterprise.com  Wed Jun  3 08:35:43 2009
From: tomas.kukosa at siemens-enterprise.com (Kukosa, Tomas)
Date: Wed, 3 Jun 2009 08:35:43 +0200
Subject: [Help-gnutls] PKCS#8 incompatibility? between OpenSSL and GnuTLS
Message-ID: <3E4278088AD82C48B4663DDFE762CEF306835F93@prga004a.ww300.siemens.net>

Hi,
 
I have recived PKCS#12 file created with OpenSSL 0.9.7e which I can not
read in GnuTLS 2.7.12 but I still can read it in any OpenSSL.

When I extracted essential problem which seems to be
decryption/encryption of PKCS#8 I came to the following result:

There are fixed RSA private key key01.pem and password "123456".

Let's encrypt it with OpenSSL (tested with 0.9.7e and 0.9.8k)
>openssl pkcs8 -topk8 -in key01.pem -passout pass:123456 -out
.\data\x_NNNN.pem -v1 PBE-SHA1-3DES

Then let's decrypt it with GnuTLS (tested with 2.7.12)
>certtool -k --password 123456 --infile .\data\x_NNNN.pem --outfile
.\data\y_NNN.pem

It can be usuallay decrypted without any problem. But if you try it more
times (tested 90000 times with OpenSSL 0.9.7e and 9000 times with
0.9.8k) it can not be decrypted in about 0,8% of all cases.
It fails during decryption:
>certtool.exe -d 9 -k --password 123456 --infile .\data\x_9607.pem
Setting log level to 9
|<2>| ASSERT: ../../../src/gnutls-2.8.0/lib/x509_b64.c:452
|<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
|<2>| ASSERT: ../../../src/gnutls-2.8.0/lib/x509_b64.c:452
|<2>| Could not find '-----BEGIN DSA PRIVATE KEY'
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey.c:373
|<2>| ASSERT: ../../../src/gnutls-2.8.0/lib/x509_b64.c:452
|<2>| Could not find '-----BEGIN PRIVATE KEY'
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey_pkcs8.c:972
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey_pkcs8.c:1118
|<2>| ASSERT: ../../../src/gnutls-2.8.0/lib/x509_b64.c:452
|<2>| Could not find '-----BEGIN PRIVATE KEY'
|<9>| salt.size: 8
|<9>| iterationCount: 2048
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey_pkcs8.c:972
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey_pkcs8.c:836
|<2>| ASSERT: ../../../../src/gnutls-2.8.0/lib/x509/privkey_pkcs8.c:1118
certtool.exe: import error: Decryption has failed.

Those erroneous keys still can be decrypted with OpenSSL.

The attached file contains all test scripts and few encrypted PKCS#8
files.
Files x_9607.pem, x_9671.pem, x_9926.pem, x_9931.txt contain erroneous
keys.

How to find whether it is bug in OpenSSL or GnuTLS?

BTW 0,8% is near to 1/128 or to 1/120 but it could be just random :-)

Any ideas are welcome!

Best regards,
  Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-with-openssl-0.9.8k.zip
Type: application/x-zip-compressed
Size: 26973 bytes
Desc: test-with-openssl-0.9.8k.zip
URL: </pipermail/attachments/20090603/5e8738ca/attachment.bin>

From simon at josefsson.org  Wed Jun  3 15:25:16 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 03 Jun 2009 15:25:16 +0200
Subject: [Help-gnutls] Re: PKCS#8 incompatibility? between OpenSSL and GnuTLS
In-Reply-To: <3E4278088AD82C48B4663DDFE762CEF306835F93@prga004a.ww300.siemens.net>
	(Tomas Kukosa's message of "Wed, 3 Jun 2009 08:35:43 +0200")
References: <3E4278088AD82C48B4663DDFE762CEF306835F93@prga004a.ww300.siemens.net>
Message-ID: <87eiu1la9v.fsf@mocca.josefsson.org>

"Kukosa, Tomas" <tomas.kukosa at siemens-enterprise.com> writes:

> Hi,
>  
> I have recived PKCS#12 file created with OpenSSL 0.9.7e which I can not
> read in GnuTLS 2.7.12 but I still can read it in any OpenSSL.

Hi!  Interesting report, I'm debugging it now.

> BTW 0,8% is near to 1/128 or to 1/120 but it could be just random :-)

This suggests some parsing problem, maybe in the PKCS#12 string2key
function.  The 3DES keys for three of the four PEM's happened to start
with 00.  The fourth PEM didn't start with 00, but the IV is also
derived using the string2key function, so maybe there is a similar
problem there.  Could be some DES parity bit issue as well.

I'll instrument openssl to print the decryption keys it compute, if
there is a mismatch I've confirmed the theory.

/Simon




From simon at josefsson.org  Wed Jun  3 16:30:08 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 03 Jun 2009 16:30:08 +0200
Subject: [Help-gnutls] Re: PKCS#8 incompatibility? between OpenSSL and GnuTLS
In-Reply-To: <87eiu1la9v.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 03 Jun 2009 15:25:16 +0200")
References: <3E4278088AD82C48B4663DDFE762CEF306835F93@prga004a.ww300.siemens.net>
	<87eiu1la9v.fsf@mocca.josefsson.org>
Message-ID: <87ab4pl79r.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> "Kukosa, Tomas" <tomas.kukosa at siemens-enterprise.com> writes:
>
>> Hi,
>>  
>> I have recived PKCS#12 file created with OpenSSL 0.9.7e which I can not
>> read in GnuTLS 2.7.12 but I still can read it in any OpenSSL.
>
> Hi!  Interesting report, I'm debugging it now.
>
>> BTW 0,8% is near to 1/128 or to 1/120 but it could be just random :-)
>
> This suggests some parsing problem, maybe in the PKCS#12 string2key
> function.  The 3DES keys for three of the four PEM's happened to start
> with 00.  The fourth PEM didn't start with 00, but the IV is also
> derived using the string2key function, so maybe there is a similar
> problem there.  Could be some DES parity bit issue as well.
>
> I'll instrument openssl to print the decryption keys it compute, if
> there is a mismatch I've confirmed the theory.

Indeed, the outputs from the PKCS#12 string2key functions differs (for
the same inputs) between GnuTLS and OpenSSL in some corner cases.  I
wonder which is standards compliant, there seems to be no PKCS#12 test
vectors around.

I suggest you use a more modern string2key algorithm than PKCS#12. ;)

We should fix this, though.  Thanks for reporting this with sufficient
information to reproduce it.

/Simon




From Roland.Winkler at physik.uni-erlangen.de  Fri Jun  5 07:35:52 2009
From: Roland.Winkler at physik.uni-erlangen.de (Roland Winkler)
Date: Fri, 5 Jun 2009 07:35:52 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <4A243D01.6020309@fifthhorseman.net>
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
	<4A243D01.6020309@fifthhorseman.net>
Message-ID: <18984.44728.226806.335932@tfkp07.physik.uni-erlangen.de>

On Mon Jun 1 2009 Daniel Kahn Gillmor wrote:
> I've opened https://bugzilla.novell.com/show_bug.cgi?id=508844 to
> suggest that YaST should behave differently.  Roland, if you can follow
> up there with more details about how the cert in question was created
> and how the service was configured, we might be able to prevent this
> from tripping up other folks in the future.

It's a bit difficult to reconstruct the details.

The certificate was created via YaST on an Open Enterprise Server
(OES) SP2. The sysadmin told me that these certificates are mainly
intended for https connections and secure communication of Novell's
eDirectory service. They are not specifically designed for secure
SMTP connections that triggered the "key usage violation" problem.

Daniel, I don't have an account to update your YaST bug report.
Could you please add the above paragraph?

Thanks,

Roland




From simon at josefsson.org  Fri Jun  5 13:42:17 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 05 Jun 2009 13:42:17 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <18984.44728.226806.335932@tfkp07.physik.uni-erlangen.de> (Roland
	Winkler's message of "Fri, 5 Jun 2009 07:35:52 +0200")
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
	<4A243D01.6020309@fifthhorseman.net>
	<18984.44728.226806.335932@tfkp07.physik.uni-erlangen.de>
Message-ID: <87bpp2rjom.fsf@mocca.josefsson.org>

"Roland Winkler" <Roland.Winkler at physik.uni-erlangen.de> writes:

> On Mon Jun 1 2009 Daniel Kahn Gillmor wrote:
>> I've opened https://bugzilla.novell.com/show_bug.cgi?id=508844 to
>> suggest that YaST should behave differently.  Roland, if you can follow
>> up there with more details about how the cert in question was created
>> and how the service was configured, we might be able to prevent this
>> from tripping up other folks in the future.
>
> It's a bit difficult to reconstruct the details.
>
> The certificate was created via YaST on an Open Enterprise Server
> (OES) SP2. The sysadmin told me that these certificates are mainly
> intended for https connections and secure communication of Novell's
> eDirectory service. They are not specifically designed for secure
> SMTP connections that triggered the "key usage violation" problem.

The same concerns applies to https/ldaps: if the KeySign key usage isn't
permitted, you can't use DHE ciphersuites.  That seems sub-optimal, but
could be intentional for some strange reason.

/Simon




From carolin.latze at unifr.ch  Fri Jun  5 16:32:16 2009
From: carolin.latze at unifr.ch (Carolin Latze)
Date: Fri, 5 Jun 2009 16:32:16 +0200
Subject: [Help-gnutls] Still replacing OpenSSL function with GnuTLS
Message-ID: <4A292C70.5060806@unifr.ch>

Hi all,

it's me again. Replacing OpenSSL with GnuTLS in an application is a lot 
more complicated than I thought :) I have more questions regarding 
certain functions:

1) Is there a method to set a message callback similar to 
SSL_set_msg_callback. I didn't find any but it seems that I need it :-/

2) Is it the right way to replace SSL_set_accept_state with 
gnutls_init(&session,GNUTLS_SERVER)? From my understandings, it makes 
sense... what do you think?

3) In OpenSSL there is a method to check whether a handshake has 
finished: SSL_is_init_finished. Is there an equivalent in GnuTLS? I 
didn't find one so far but I have the impression that it cannot be too 
complicated to write one (so perhaps there is already one I didn't find?)

Any hints are appreciated.

Regards
Carolin




From dkg at fifthhorseman.net  Fri Jun  5 17:51:55 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 05 Jun 2009 11:51:55 -0400
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <87bpp2rjom.fsf@mocca.josefsson.org>
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>	<4A2171F4.4010800@gnutls.org>	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>	<4A2194AE.4040006@fifthhorseman.net>	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>	<4A243D01.6020309@fifthhorseman.net>	<18984.44728.226806.335932@tfkp07.physik.uni-erlangen.de>
	<87bpp2rjom.fsf@mocca.josefsson.org>
Message-ID: <4A293F1B.8030907@fifthhorseman.net>

On 06/05/2009 07:42 AM, Simon Josefsson wrote:
> The same concerns applies to https/ldaps: if the KeySign key usage isn't
> permitted, you can't use DHE ciphersuites.  That seems sub-optimal, but
> could be intentional for some strange reason.

if eDirectory is just ldaps then i totally agree with you -- i'm afraid
i didn't bother to learn more about eDirectory or YaST or whatever, as
i'm not generally a novell or suse user.

it's also weird that they do not set the critical flag on their keyUsage
extension (CA=FALSE), contravening a SHOULD in the RFC.  it's not
completely outrageous, but it seems like they'd want to have a good
justification for deviating from the SHOULD, particularly because of the
semantics of that extension (you really don't want any software to
mistakenly treat an EE cert as a CA cert).

anyway, i don't know much detail about SuSE bug reporting mechanisms --
i'm hoping that  https://bugzilla.novell.com/show_bug.cgi?id=508844 will
be enough to get someone to poke the YaST devs about it, and maybe they
can follow up here if they have more questions about their use of X.509.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090605/b0b2737b/attachment.pgp>

From tobias-lists at 23.gs  Mon Jun  8 19:54:12 2009
From: tobias-lists at 23.gs (Tobias Gruetzmacher)
Date: Mon, 8 Jun 2009 19:54:12 +0200
Subject: [Help-gnutls] Strange problem with SVN and mod_gnutls
Message-ID: <20090608175411.GA7074@23.gs>

Hi,

I have a very strange problem with gnutls on both ends of the
communication, maybe someone on this list knows how to fix this:

Software configuration:

Server:
Apache2 (prefork)      2.2.9-10+lenny2
mod_gnutls             0.5.4
GnuTLS                 2.4.2-6+lenny1

Client:
Subversion             1.5.6dfsg-1
LibNeon                0.28.4-2
GnuTLS                 2.6.6-1

When trying to check out the repository with Subversion, I get this
error:

svn: OPTIONS of 'https://XXX/svn': Could not read chunk size: SSL error:
Too many empty record packets have been received. (https://XXX)

The only workaround I have found so far: Switching the Subversion client
to libserf, which is linked against OpenSSL... But I don't like that
solution, since I don't want to instruct every user to change his client
config... Is there anything I can do on the server side?

Greetings, Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090608/7da1cfbd/attachment.pgp>

From simon at josefsson.org  Tue Jun  9 09:34:14 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 09 Jun 2009 09:34:14 +0200
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <20090608175411.GA7074@23.gs> (Tobias Gruetzmacher's message of
	"Mon, 8 Jun 2009 19:54:12 +0200")
References: <20090608175411.GA7074@23.gs>
Message-ID: <873aa9kgi1.fsf@mocca.josefsson.org>

Tobias Gruetzmacher <tobias-lists at 23.gs> writes:

> Hi,
>
> I have a very strange problem with gnutls on both ends of the
> communication, maybe someone on this list knows how to fix this:
>
> Software configuration:
>
> Server:
> Apache2 (prefork)      2.2.9-10+lenny2
> mod_gnutls             0.5.4
> GnuTLS                 2.4.2-6+lenny1
>
> Client:
> Subversion             1.5.6dfsg-1
> LibNeon                0.28.4-2
> GnuTLS                 2.6.6-1
>
> When trying to check out the repository with Subversion, I get this
> error:
>
> svn: OPTIONS of 'https://XXX/svn': Could not read chunk size: SSL error:
> Too many empty record packets have been received. (https://XXX)
>
> The only workaround I have found so far: Switching the Subversion client
> to libserf, which is linked against OpenSSL... But I don't like that
> solution, since I don't want to instruct every user to change his client
> config... Is there anything I can do on the server side?

Interesting!

I wonder what triggers the empty packets.  Can you enable GnuTLS
debugging in the client and post the debug log?

/Simon




From tobias-lists at 23.gs  Tue Jun  9 19:48:11 2009
From: tobias-lists at 23.gs (Tobias Gruetzmacher)
Date: Tue, 9 Jun 2009 19:48:11 +0200
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <873aa9kgi1.fsf@mocca.josefsson.org>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
Message-ID: <20090609174811.GA5601@23.gs>

Hi,

On Tue, Jun 09, 2009 at 09:34:14AM +0200, Simon Josefsson wrote:
> Tobias Gruetzmacher <tobias-lists at 23.gs> writes:
> > svn: OPTIONS of 'https://XXX/svn': Could not read chunk size: SSL error:
> > Too many empty record packets have been received. (https://XXX)
> >
> > The only workaround I have found so far: Switching the Subversion client
> > to libserf, which is linked against OpenSSL... But I don't like that
> > solution, since I don't want to instruct every user to change his client
> > config... Is there anything I can do on the server side?
> 
> Interesting!
> 
> I wonder what triggers the empty packets.  Can you enable GnuTLS
> debugging in the client and post the debug log?

I build libneon with some debugging instructions and put the resulting
log on my server: http://23.gs/svn-gnutls-debug.log ...

Greetings, Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090609/66849d4f/attachment.pgp>

From simon at josefsson.org  Wed Jun 10 16:24:12 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Jun 2009 16:24:12 +0200
Subject: [Help-gnutls] Re: PKCS#8 incompatibility? between OpenSSL and GnuTLS
In-Reply-To: <87ab4pl79r.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 03 Jun 2009 16:30:08 +0200")
References: <3E4278088AD82C48B4663DDFE762CEF306835F93@prga004a.ww300.siemens.net>
	<87eiu1la9v.fsf@mocca.josefsson.org>
	<87ab4pl79r.fsf@mocca.josefsson.org>
Message-ID: <87ski8b20j.fsf@mocca.josefsson.org>

Hi Tomas.  I identified the problem, and it happens when an addition in
the PKCS#12 string-to-key algorithm results in a small result due to MSB
being 00, which happens on average for 1 out of 128 random inputs -- not
1 out of 256 because the code is run in a loop that does two iterations,
so the problem is triggered if the MSB is 00 in either loop.

See patch:
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=dc901197329570394d75d82a5e9d82f17f56106a

This patch will be part of the soon to be released v2.8.1.

Thanks again for the good bug report of an interesting problem.

/Simon




From simon at josefsson.org  Wed Jun 10 18:52:05 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Jun 2009 18:52:05 +0200
Subject: [Help-gnutls] GnuTLS 2.8.1
Message-ID: <87ocsw9glm.fsf@mocca.josefsson.org>

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

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
==========

** libgnutls: Fix crash in gnutls_global_init after earlier init/deinit cycle.
Forwarded by Martin von Gagern <Martin.vGagern at gmx.net> from
<http://bugs.gentoo.org/272388>.

** libgnutls: Fix PKCS#12 decryption from password.
The encryption key derived from the password was incorrect for (on
average) 1 in every 128 input for random inputs.  Reported by "Kukosa,
Tomas" <tomas.kukosa at siemens-enterprise.com> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1663>.

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

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.1.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.1.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.8.1.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: 2010-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21]

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:

b5fd364848709393d05def7e926caddd27169525  gnutls-2.8.1.tar.bz2

8d94ffd6d37d0251778718933a63848521ab64c4700588455bcaa372  gnutls-2.8.1.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:

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

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 installer uses
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.2, and GnuTLS v2.8.1.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.8.1.exe (15MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.1.exe.sig

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

3ac9beb22da8b0301c432861a74717d319f28020  gnutls-2.8.1.exe

b40ec214c8f251c9384ddbb3fb2c4d8ea9e746140414aa76b2793791  gnutls-2.8.1.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.8.1.zip (5.3MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.1.zip.sig

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.1-1_all.deb (4.8MB)

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

e34a20b91fc8e35c3a04ae8089d73fa45bb62fa4  mingw32-gnutls_2.8.1-1_all.deb

fc15cf1c37e7711d718e4b84739807d3498e3c0045c2cf9ce4bbdc23  mingw32-gnutls_2.8.1-1_all.deb

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

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Malay, Polish, 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: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090610/2ad43486/attachment.pgp>

From nmav at gnutls.org  Sat Jun 13 09:38:43 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jun 2009 10:38:43 +0300
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <20090609174811.GA5601@23.gs>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
	<20090609174811.GA5601@23.gs>
Message-ID: <4A335783.407@gnutls.org>

Tobias Gruetzmacher wrote:
> Hi,
> 
> On Tue, Jun 09, 2009 at 09:34:14AM +0200, Simon Josefsson wrote:
>> Tobias Gruetzmacher <tobias-lists at 23.gs> writes:
>>> svn: OPTIONS of 'https://XXX/svn': Could not read chunk size: SSL error:
>>> Too many empty record packets have been received. (https://XXX)
>>>
>>> The only workaround I have found so far: Switching the Subversion client
>>> to libserf, which is linked against OpenSSL... But I don't like that
>>> solution, since I don't want to instruct every user to change his client
>>> config... Is there anything I can do on the server side?
>> Interesting!
>>
>> I wonder what triggers the empty packets.  Can you enable GnuTLS
>> debugging in the client and post the debug log?
> 
> I build libneon with some debugging instructions and put the resulting
> log on my server: http://23.gs/svn-gnutls-debug.log ...

Hello,

For some reason the server sends some packets without any contents and
the client believes that this is a denial of service. Is there some
application that produces those packets or this is just a file transfer?

regards,
Nikos




From nmav at gnutls.org  Sat Jun 13 09:44:08 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jun 2009 10:44:08 +0300
Subject: [Help-gnutls] Still replacing OpenSSL function with GnuTLS
In-Reply-To: <4A292C70.5060806@unifr.ch>
References: <4A292C70.5060806@unifr.ch>
Message-ID: <4A3358C8.1010702@gnutls.org>

Carolin Latze wrote:

Hello,
 In general you shouldn't try to map gnutls functions to openssl or vice
versa. They both work different and there is no such 1-1 mapping. Just
check the gnutls manual to see what kind of server/client you are
implementing and try to apply it to your program.

> it's me again. Replacing OpenSSL with GnuTLS in an application is a lot
> more complicated than I thought :) I have more questions regarding
> certain functions:
> 
> 1) Is there a method to set a message callback similar to
> SSL_set_msg_callback. I didn't find any but it seems that I need it :-/

No. But normally you shouldn't need it. What is the reason you want to
use it?

> 2) Is it the right way to replace SSL_set_accept_state with
> gnutls_init(&session,GNUTLS_SERVER)? From my understandings, it makes
> sense... what do you think?

Really depends on the context. We don't have a function similar to that.

> 3) In OpenSSL there is a method to check whether a handshake has
> finished: SSL_is_init_finished. Is there an equivalent in GnuTLS? I
> didn't find one so far but I have the impression that it cannot be too
> complicated to write one (so perhaps there is already one I didn't find?)

No we don't have such a function. when gnutls_handshake() returns the
handshake is over.

regards,
Nikos




From tobias-lists at 23.gs  Sat Jun 13 12:56:18 2009
From: tobias-lists at 23.gs (Tobias Gruetzmacher)
Date: Sat, 13 Jun 2009 12:56:18 +0200
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <4A335783.407@gnutls.org>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
	<20090609174811.GA5601@23.gs> <4A335783.407@gnutls.org>
Message-ID: <20090613105617.GA4435@23.gs>

Hi,

On Sat, Jun 13, 2009 at 10:38:43AM +0300, Nikos Mavrogiannopoulos wrote:
> > I build libneon with some debugging instructions and put the resulting
> > log on my server: http://23.gs/svn-gnutls-debug.log ...
> 
> For some reason the server sends some packets without any contents and
> the client believes that this is a denial of service. Is there some
> application that produces those packets or this is just a file transfer?

This is just a "svn checkout" - The request can be seen in the first
lines of the log file. Unfortunatly I can't reproduce this error with
gnutls-cli or socat... On the server side just plain Apache with
mod_gnutls and the SVN webdav modules. Running on a vserver behind a
NAT, if that matters...

Greetings, Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090613/bbae3e56/attachment.pgp>

From nmav at gnutls.org  Sat Jun 13 14:55:55 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jun 2009 15:55:55 +0300
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <20090613105617.GA4435@23.gs>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
	<20090609174811.GA5601@23.gs> <4A335783.407@gnutls.org>
	<20090613105617.GA4435@23.gs>
Message-ID: <4A33A1DB.4090907@gnutls.org>

Tobias Gruetzmacher wrote:
> Hi,
> 
> On Sat, Jun 13, 2009 at 10:38:43AM +0300, Nikos Mavrogiannopoulos wrote:
>>> I build libneon with some debugging instructions and put the resulting
>>> log on my server: http://23.gs/svn-gnutls-debug.log ...
>> For some reason the server sends some packets without any contents and
>> the client believes that this is a denial of service. Is there some
>> application that produces those packets or this is just a file transfer?
> 
> This is just a "svn checkout" - The request can be seen in the first
> lines of the log file. Unfortunatly I can't reproduce this error with
> gnutls-cli or socat... On the server side just plain Apache with
> mod_gnutls and the SVN webdav modules. Running on a vserver behind a
> NAT, if that matters...

I suppose that there is no proxy HTTPS server in between and you have
direct communication with mod_gnutls. If this is the case could you try
if the following patch for mod_gnutls fixes the issue for you? Otherwise
could you provide debugging output of mod_gnutls (you can do that by
changing in include/mod_gnutls.h.in the MOD_GNUTLS_DEBUG definition to 1
and then run ./configure and make again).

regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_gnutls-non-zero.patch
Type: text/x-patch
Size: 1956 bytes
Desc: not available
URL: </pipermail/attachments/20090613/fe26afc8/attachment.bin>

From tobias-lists at 23.gs  Sat Jun 13 16:15:10 2009
From: tobias-lists at 23.gs (Tobias Gruetzmacher)
Date: Sat, 13 Jun 2009 16:15:10 +0200
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <4A33A1DB.4090907@gnutls.org>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
	<20090609174811.GA5601@23.gs> <4A335783.407@gnutls.org>
	<20090613105617.GA4435@23.gs> <4A33A1DB.4090907@gnutls.org>
Message-ID: <20090613141509.GB19854@23.gs>

Hi,

On Sat, Jun 13, 2009 at 03:55:55PM +0300, Nikos Mavrogiannopoulos wrote:
> Tobias Gruetzmacher wrote:
> > This is just a "svn checkout" - The request can be seen in the first
> > lines of the log file. Unfortunatly I can't reproduce this error with
> > gnutls-cli or socat... On the server side just plain Apache with
> > mod_gnutls and the SVN webdav modules. Running on a vserver behind a
> > NAT, if that matters...
> 
> I suppose that there is no proxy HTTPS server in between and you have
> direct communication with mod_gnutls. If this is the case could you try
> if the following patch for mod_gnutls fixes the issue for you? Otherwise
> could you provide debugging output of mod_gnutls (you can do that by
> changing in include/mod_gnutls.h.in the MOD_GNUTLS_DEBUG definition to 1
> and then run ./configure and make again).

Awesome, that fixed it! Thank you very much!

Yes, there is no proxy inbetween.

Greetings, Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090613/f9dc4aff/attachment.pgp>

From nmav at gnutls.org  Sat Jun 13 17:35:23 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jun 2009 18:35:23 +0300
Subject: [Help-gnutls] Re: Strange problem with SVN and mod_gnutls
In-Reply-To: <20090613135020.GA19854@23.gs>
References: <20090608175411.GA7074@23.gs> <873aa9kgi1.fsf@mocca.josefsson.org>
	<20090609174811.GA5601@23.gs> <4A335783.407@gnutls.org>
	<20090613105617.GA4435@23.gs> <4A33A1DB.4090907@gnutls.org>
	<20090613135020.GA19854@23.gs>
Message-ID: <4A33C73B.50008@gnutls.org>

Tobias Gruetzmacher wrote:
> Hi,
> 
> On Sat, Jun 13, 2009 at 03:55:55PM +0300, Nikos Mavrogiannopoulos wrote:
>> Tobias Gruetzmacher wrote:
>>> This is just a "svn checkout" - The request can be seen in the first
>>> lines of the log file. Unfortunatly I can't reproduce this error with
>>> gnutls-cli or socat... On the server side just plain Apache with
>>> mod_gnutls and the SVN webdav modules. Running on a vserver behind a
>>> NAT, if that matters...
>> I suppose that there is no proxy HTTPS server in between and you have
>> direct communication with mod_gnutls. If this is the case could you try
>> if the following patch for mod_gnutls fixes the issue for you? Otherwise
>> could you provide debugging output of mod_gnutls (you can do that by
>> changing in include/mod_gnutls.h.in the MOD_GNUTLS_DEBUG definition to 1
>> and then run ./configure and make again).
> 
> Awesome, that fixed it! Thank you very much!

I've released mod_gnutls 0.5.5 that includes that fix.

regards,
Nikos




From simon at josefsson.org  Sun Jun 14 10:13:03 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 14 Jun 2009 10:13:03 +0200
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <4A293F1B.8030907@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Fri, 05 Jun 2009 11:51:55 -0400")
References: <18977.25644.672665.705939@tfkp07.physik.uni-erlangen.de>
	<4A2171F4.4010800@gnutls.org>
	<18977.33554.217818.177800@tfkp07.physik.uni-erlangen.de>
	<4A2194AE.4040006@fifthhorseman.net>
	<18977.48061.604507.486413@tfkp07.physik.uni-erlangen.de>
	<4A243D01.6020309@fifthhorseman.net>
	<18984.44728.226806.335932@tfkp07.physik.uni-erlangen.de>
	<87bpp2rjom.fsf@mocca.josefsson.org>
	<4A293F1B.8030907@fifthhorseman.net>
Message-ID: <87k53fnshc.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> anyway, i don't know much detail about SuSE bug reporting mechanisms --
> i'm hoping that  https://bugzilla.novell.com/show_bug.cgi?id=508844 will
> be enough to get someone to poke the YaST devs about it, and maybe they
> can follow up here if they have more questions about their use of X.509.

Yes, I hope that is sufficient.

/Simon




From bortzmeyer at nic.fr  Tue Jun 16 08:53:37 2009
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Tue, 16 Jun 2009 08:53:37 +0200
Subject: [Help-gnutls] Re: GNU DTLS?
In-Reply-To: <87vdul3nen.fsf@mocca.josefsson.org>
References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local>
	<873ahxtiye.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local>
	<873ahwowkq.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local>
	<87r65e37s4.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local>
	<87k5b4zzkx.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A78604374@yugi.mocana.local>
	<87vdul3nen.fsf@mocca.josefsson.org>
Message-ID: <20090616065337.GA7900@nic.fr>

On Tue, Nov 18, 2008 at 01:09:36AM +0100,
 Simon Josefsson <simon at josefsson.org> wrote 
 a message of 24 lines which said:

> > Can you please let me know if there is a way to check if GNU DTLS is turned on?
> 
> GnuTLS doesn't support DTLS.

Any plans to add it?




From simon at josefsson.org  Tue Jun 16 09:03:29 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jun 2009 09:03:29 +0200
Subject: [Help-gnutls] Re: GNU DTLS?
In-Reply-To: <20090616065337.GA7900@nic.fr> (Stephane Bortzmeyer's message of
	"Tue, 16 Jun 2009 08:53:37 +0200")
References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local>
	<873ahxtiye.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local>
	<873ahwowkq.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local>
	<87r65e37s4.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local>
	<87k5b4zzkx.fsf@mocca.josefsson.org>
	<50DADDE6B33B1B47904E685AAFDC18241A78604374@yugi.mocana.local>
	<87vdul3nen.fsf@mocca.josefsson.org> <20090616065337.GA7900@nic.fr>
Message-ID: <87ski0k6da.fsf@mocca.josefsson.org>

Stephane Bortzmeyer <bortzmeyer at nic.fr> writes:

> On Tue, Nov 18, 2008 at 01:09:36AM +0100,
>  Simon Josefsson <simon at josefsson.org> wrote 
>  a message of 24 lines which said:
>
>> > Can you please let me know if there is a way to check if GNU DTLS is turned on?
>> 
>> GnuTLS doesn't support DTLS.
>
> Any plans to add it?

Nobody is working on this now, alas.  DTLS is somewhat different than
TLS, so maybe it should be a separate library, gnudtls.  Or maybe it
could be a "sub"-library of GnuTLS, such as libgnutls-dtls.  Last time
Nikos looked into it, I think he thought it would take quite some work
to re-factor the GnuTLS code so it worked with DTLS as well.

It would be great if someone was interested in working on implementing
on DTLS in GnuTLS.

/Simon




From carolin.latze at unifr.ch  Wed Jun 17 11:04:01 2009
From: carolin.latze at unifr.ch (Carolin Latze)
Date: Wed, 17 Jun 2009 11:04:01 +0200
Subject: [Help-gnutls] Still replacing OpenSSL function with GnuTLS
In-Reply-To: <4A3358C8.1010702@gnutls.org>
References: <4A292C70.5060806@unifr.ch> <4A3358C8.1010702@gnutls.org>
Message-ID: <4A38B181.6080707@unifr.ch>

Hi Nikos,

>
> Hello,
>  In general you shouldn't try to map gnutls functions to openssl or vice
> versa. They both work different and there is no such 1-1 mapping. Just
> check the gnutls manual to see what kind of server/client you are
> implementing and try to apply it to your program.
I totally agree with you, but I am trying to port the FreeRADIUS EAP-TLS 
module to GnuTLS and that would require to implement it again from the 
scratch. As I am unable to do that, I tried to replace the OpenSSL calls 
instead. Meanwhile I also got the impression, that it might have been 
easier to write a complete new module instead... I have time until the 
end of June to get it running. Not sure, I?ll be able to do it :)

Carolin




From simon at josefsson.org  Wed Jun 17 14:18:41 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 17 Jun 2009 14:18:41 +0200
Subject: [Help-gnutls] Re: Still replacing OpenSSL function with GnuTLS
In-Reply-To: <4A38B181.6080707@unifr.ch> (Carolin Latze's message of "Wed, 17
	Jun 2009 11:04:01 +0200")
References: <4A292C70.5060806@unifr.ch> <4A3358C8.1010702@gnutls.org>
	<4A38B181.6080707@unifr.ch>
Message-ID: <878wjraw9q.fsf@mocca.josefsson.org>

Carolin Latze <carolin.latze at unifr.ch> writes:

> Hi Nikos,
>
>>
>> Hello,
>>  In general you shouldn't try to map gnutls functions to openssl or vice
>> versa. They both work different and there is no such 1-1 mapping. Just
>> check the gnutls manual to see what kind of server/client you are
>> implementing and try to apply it to your program.
> I totally agree with you, but I am trying to port the FreeRADIUS
> EAP-TLS module to GnuTLS and that would require to implement it again
> from the scratch. As I am unable to do that, I tried to replace the
> OpenSSL calls instead. Meanwhile I also got the impression, that it
> might have been easier to write a complete new module instead... I
> have time until the end of June to get it running. Not sure, I?ll be
> able to do it :)

Replacing calls-by-calls can be a good first step towards making it
work, then when you get something that works, it is only a small matter
of cleaning up the code. ;)

Using GnuTLS in more EAP environments would be good, it has seen too
little testing there.

Anyway, good luck.

/Simon




From jkmalinen at gmail.com  Wed Jun 17 20:23:54 2009
From: jkmalinen at gmail.com (Jouni Malinen)
Date: Wed, 17 Jun 2009 21:23:54 +0300
Subject: [Help-gnutls] Re: Still replacing OpenSSL function with GnuTLS
In-Reply-To: <878wjraw9q.fsf@mocca.josefsson.org>
References: <4A292C70.5060806@unifr.ch> <4A3358C8.1010702@gnutls.org>
	<4A38B181.6080707@unifr.ch> <878wjraw9q.fsf@mocca.josefsson.org>
Message-ID: <e785a1360906171123w6b6d15eagd4df89423603de6f@mail.gmail.com>

On Wed, Jun 17, 2009 at 3:18 PM, Simon Josefsson<simon at josefsson.org> wrote:
> Using GnuTLS in more EAP environments would be good, it has seen too
> little testing there.

Talking of which..  Are there any plans on adding support for TLS
Session Ticket (RFC 5077) into GnuTLS? It (or well, a bit modified
version of it) would be needed to be able to implement EAP-FAST. I
finally got the needed patch to do this into OpenSSL, but if I've
understood correctly, this functionality is missing from GnuTLS and
consequently, no EAP-FAST support with it is currently possible. By
the way, http://www.gnu.org/software/gnutls/comparison.html could be
updated to say that OpenSSL does support session tickets if seeing
GnuTLS as the only row with red here would motivate someone to work on
this ;-).

wpa_supplicant and hostapd can be used with GnuTLS to implement EAP
peer and server functionality for EAP-TLS, EAP-PEAP, and EAP-TTLS.
Some Linux distros may even build these by default with GnuTLS, but I
would assume that OpenSSL is used in most cases. It might even be
possible to use the FreeRADIUS eap2 module and link that with the EAP
server code from hostapd built with GnuTLS if someone is looking for
an odd hack of using GnuTLS with FreeRADIUS.

- Jouni




From simon at josefsson.org  Thu Jun 18 08:32:28 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 18 Jun 2009 08:32:28 +0200
Subject: [Help-gnutls] Re: Still replacing OpenSSL function with GnuTLS
In-Reply-To: <e785a1360906171123w6b6d15eagd4df89423603de6f@mail.gmail.com>
	(Jouni Malinen's message of "Wed, 17 Jun 2009 21:23:54 +0300")
References: <4A292C70.5060806@unifr.ch> <4A3358C8.1010702@gnutls.org>
	<4A38B181.6080707@unifr.ch> <878wjraw9q.fsf@mocca.josefsson.org>
	<e785a1360906171123w6b6d15eagd4df89423603de6f@mail.gmail.com>
Message-ID: <87r5xi6ohv.fsf@mocca.josefsson.org>

Jouni Malinen <jkmalinen at gmail.com> writes:

> On Wed, Jun 17, 2009 at 3:18 PM, Simon Josefsson<simon at josefsson.org> wrote:
>> Using GnuTLS in more EAP environments would be good, it has seen too
>> little testing there.
>
> Talking of which..  Are there any plans on adding support for TLS
> Session Ticket (RFC 5077) into GnuTLS?

It would be fun to do it, although my time is limited right now.  I'll
look into it.

The hard part appears to be the section 4 recommended ticket
construction.  Is this something you need?  I could easily see some
environments using completely different tickets.

> It (or well, a bit modified version of it) would be needed to be able
> to implement EAP-FAST.

Do you have some pointers one what modifications are required?

> I finally got the needed patch to do this into OpenSSL, but if I've
> understood correctly, this functionality is missing from GnuTLS and
> consequently, no EAP-FAST support with it is currently possible.

Right, GnuTLS does not support it right now.

> By the way, http://www.gnu.org/software/gnutls/comparison.html could
> be updated to say that OpenSSL does support session tickets if seeing
> GnuTLS as the only row with red here would motivate someone to work on
> this ;-).

Indeed.  I fixed the webpage.

/Simon




From hs at schlittermann.de  Fri Jun 19 15:29:21 2009
From: hs at schlittermann.de (Heiko Schlittermann)
Date: Fri, 19 Jun 2009 15:29:21 +0200
Subject: [Help-gnutls] Exim + (GNU)TLS + Outlook + tls_try_verify_hosts
Message-ID: <20090619132921.GD12725@jumper.schlittermann.de>

Hello,

I'll post my question already sent to exim-user, because I think, the
mentioned problem is more related to GNUTLS than to exim.

About the mentioned library version I'm not sure for 100%, but ldd
reports libgnutls.so.26.

----- Forwarded message from Heiko Schlittermann <hs at schlittermann.de> -----

Date: Fri, 19 Jun 2009 13:59:20 +0200
From: Heiko Schlittermann <hs at schlittermann.de>
To: Exim Users List <exim-users at exim.org>
Sender: exim-users-bounces at exim.org
Subject: [exim] Exim + (GNU)TLS + Outlook + tls_try_verify_hosts

Hello,

after resolving the issues with certs not verified by GNUTLS (because of
the wrong signature algorithm) we experience some other problem:

Whenever requesting a client certificate (tls_try_verify_hosts), the
client (Outlook Express) does not successfully connect. Without
requesting a certificate, TLS/SSL works.

On the server: Exim4 4.69 + GNUTLS 2.6(.4), on the client side some
Outlook (currently OE 6.0, but I think the version is not important
here). The servers options are

   tls_advertise_hosts = *
   tls_certificate = /etc/ssl/certs/ssl.schlittermann.de.crt
   tls_on_connect_ports = 465
   tls_privatekey = /etc/ssl/private/ssl.schlittermann.de.key
   tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
   tls_try_verify_hosts = *?
   tls_verify_hosts = 

?) I need this, because some (verified) certs are used for
   authentication.

Other TLS relevant options are not set.

The client complains with error code 0x800CCC0F (it seems to be quite
generic...)

With older versions of GNUTLS (used on some other server with Exim 4.68
+ GNUTLS 1.3.x) it works. Clients other than outlook connect.

When I switch off the exim and simulate a server using "openssl s_server
...", I can successfully simulate the session, attempting the same with 
"gnutls-serv ..." hangs after "sending CERTIFICATE REQUEST" to the
client.

My questions:

    * does anybody else experience this problem? (I found something
      using google, but nothing related to outlook and GNUTLS)?

    * do I really have to link exim agains the OpenSSL libs? (I do not
      like it, because of the maintenance issue)

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann HS12-RIPE -----------------------------------------
 gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
 gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B -



-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090619/6a1d3078/attachment.pgp>

From dg at orbhost.net  Fri Jun 19 21:19:08 2009
From: dg at orbhost.net (Didier Godefroy)
Date: Fri, 19 Jun 2009 21:19:08 +0200
Subject: [Help-gnutls] Building on tru64 5.1b
Message-ID: <C661B14C.23054%dg@orbhost.net>

Hello list,

Trying to build gnutls on tru64 5.1b with the native compilers.

I tried 2.8.1 and then 2.6.6 and 2.6.1 to see if those errors were recent or
not.

I get the following errors with all these versions of gnutls, at different
line numbers, but same errors:


gmake[6]: Entering directory `/usr/local/gnutls/gnutls-2.8.1/lib/gl'

.....

libtool: compile:  cc -pthread -DHAVE_CONFIG_H -I. -I.. -I../intl
-I/usr/sw/include -O4 -g3 -w -I../includes -c -MD close-hook.c  -DPIC -o
.libs/close-hook.o
cc: Error: ../includes/gnutls/crypto.h, line 54: Missing identifier.
(parnoident)
  int (*init) (gnutls_cipher_algorithm_t, void **ctx);
------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 66: Missing identifier.
(parnoident)
  int (*init) (gnutls_mac_algorithm_t, void **ctx);
---------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 220: Error parsing parameter
list. Found "*" when expecting one of: ",", ")". (notexpecting)
  int (*encrypt) (gnutls_pk_algorithm_t, gnutls_datum_t * ciphertext,
--------------------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 223: Error parsing parameter
list. Found "*" when expecting one of: ",", ")". (notexpecting)
  int (*decrypt) (gnutls_pk_algorithm_t, gnutls_datum_t * plaintext,
--------------------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 227: Error parsing parameter
list. Found "*" when expecting one of: ",", ")". (notexpecting)
  int (*sign) (gnutls_pk_algorithm_t, gnutls_datum_t * signature,
-----------------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 230: Missing identifier.
(parnoident)
  int (*verify) (gnutls_pk_algorithm_t, const gnutls_datum_t * data,
----------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 234: Missing identifier.
(parnoident)
  int (*generate) (gnutls_pk_algorithm_t, unsigned int level /*bits */ ,
------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 240: Error parsing parameter
list. Found "*" when expecting one of: ",", ")". (notexpecting)
                  gnutls_pk_params_st *);
------------------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 257: In this parameter list,
"gnutls_cipher_algorithm_t" must either be a type or must be followed by a
",". (badparseparam)
int gnutls_crypto_single_cipher_register2 (gnutls_cipher_algorithm_t
algorithm,
-------------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 260: In this parameter list,
"gnutls_mac_algorithm_t" must either be a type or must be followed by a ",".
(badparseparam)
int gnutls_crypto_single_mac_register2 (gnutls_mac_algorithm_t algorithm,
----------------------------------------^
cc: Error: ../includes/gnutls/crypto.h, line 263: In this parameter list,
"gnutls_digest_algorithm_t" must either be a type or must be followed by a
",". (badparseparam)
int gnutls_crypto_single_digest_register2 (gnutls_digest_algorithm_t
algorithm,
-------------------------------------------^


I guess noone using tru64 has reported those problems over time and they
haven't been fixed.
I had gnutls 2.2.3 compiling on that system before, although a few features
had to be disabled to work around compile issues already.

Perhaps it's time to fix this...

What can I provide to help track this down??


Thanks all,


-- 
Didier Godefroy
mailto:dg at ulysium.net
Support anti-Spam legislation.
Join the fight http://www.cauce.org/






From cononet at gmail.com  Wed Jun 24 13:24:05 2009
From: cononet at gmail.com (John D)
Date: Wed, 24 Jun 2009 14:24:05 +0300
Subject: [Help-gnutls] GCRY_THREAD_OPTION_PTHREAD_IMPL!
Message-ID: <419cd9410906240424j4098236bo6a4f6022affc0161@mail.gmail.com>

Hello

This:

 #include <gnutls.h>
 #include <gcrypt.h>
 #include <errno.h>
 #include <pthread.h>
GCRY_THREAD_OPTION_PTHREAD_IMPL;

          int main()
          {
             /* The order matters.
              */
             gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
             gnutls_global_init();
          }


Compiles flawlessly on debian 5 64bit..

However, on Cent OS 5 64 bit..
With an identical setup and gcc produces:

[root at localhost code]# gcc -lpthread test.cpp -O -lgnutls -lssl -lcurl
-pthread
test.cpp: In function int gcry_pthread_mutex_init(void**):
test.cpp:5: error: malloc was not declared in this scope
test.cpp:5: error: free was not declared in this scope
test.cpp: In function int gcry_pthread_mutex_destroy(void**):
test.cpp:5: error: invalid conversion from void* to pthread_mutex_t*
test.cpp:5: error:   initializing argument 1 of int
pthread_mutex_destroy(pthread_mutex_t*)
test.cpp:5: error: free was not declared in this scope
test.cpp: In function int gcry_pthread_mutex_lock(void**):
test.cpp:5: error: invalid conversion from void* to pthread_mutex_t*
test.cpp:5: error:   initializing argument 1 of int
pthread_mutex_lock(pthread_mutex_t*)
test.cpp: In function int gcry_pthread_mutex_unlock(void**):
test.cpp:5: error: invalid conversion from void* to pthread_mutex_t*
test.cpp:5: error:   initializing argument 1 of int
pthread_mutex_unlock(pthread_mutex_t*)
[root at localhost code]#

Might anyone be able to shed any light on what and why,
I need to get this rectified.

Thanks a million,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090624/f7e9e231/attachment.htm>

From nmav at gnutls.org  Thu Jun 25 20:56:45 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 25 Jun 2009 21:56:45 +0300
Subject: [Help-gnutls] GCRY_THREAD_OPTION_PTHREAD_IMPL!
In-Reply-To: <419cd9410906240424j4098236bo6a4f6022affc0161@mail.gmail.com>
References: <419cd9410906240424j4098236bo6a4f6022affc0161@mail.gmail.com>
Message-ID: <4A43C86D.8090702@gnutls.org>

John D wrote:
> Hello
> 
> This:
> 
>  #include <gnutls.h>
>  #include <gcrypt.h>
>  #include <errno.h>
>  #include <pthread.h>
> GCRY_THREAD_OPTION_PTHREAD_IMPL;
> 
>           int main()
>           {
>              /* The order matters.
>               */
>              gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
>              gnutls_global_init();
>           }
> 
> 
> Compiles flawlessly on debian 5 64bit..
> 
> However, on Cent OS 5 64 bit..
> With an identical setup and gcc produces:

It seems your compiler treats the .cpp file as C++. Try including stdio
and stdlib.

regards,
Nikos