From rgerhards at gmail.com  Mon May  5 09:35:55 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 5 May 2008 09:35:55 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
In-Reply-To: <87od7ss5n9.fsf@mocca.josefsson.org>
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	<87od7ss5n9.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>

Thanks for the quick response .. and sorry for me replying just now. I
somehow missed the message :)

On Tue, Apr 29, 2008 at 11:38 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>  > Hi all,
>  >
>  > [working on Fedora 8 with GCC]
>  >
>  > I have a minor nit. The root cause is probably not in GnuTLS but in me
>  > overlooking something...
>  >
>  > I supply the int fd I got from socket() to gnutls_transport_set_ptr().
>  > However, when I do so, I receive the following GCC warning:
>  >
>  > cast to pointer from integer of different size
>  >
>  > This is annoying during the build process, but of course tolerable. I
>  > would prefer to see this warning go away, but I do not like to reduce
>  > GCCs warning level. Any advise would be appreciated.
>
>  Try to use a cast when calling the function, such as:
>
>   gnutls_transport_set_ptr (session, (gnutls_transport_ptr) sockfd);

This is what I am doing. A snapshot of the actual code is here:

http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/nsd_gtls.c;h=b1713240399448e042a27d22caf5a2f044fd65a1;hb=tls

(e.g. in line 364).

I replaced this with

int ii = 6;
gnutls_transport_set_ptr(pNew->sess, (gnutls_transport_ptr) ii);

But I still get the same warning message. I am a bit puzzled,
especially as this seems to be unusual...

Rainer




From simon at josefsson.org  Mon May  5 13:34:04 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 May 2008 13:34:04 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
In-Reply-To: <dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>
	(Rainer Gerhards's message of "Mon, 5 May 2008 09:35:55 +0200")
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	<87od7ss5n9.fsf@mocca.josefsson.org>
	<dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>
Message-ID: <87ve1tyogj.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Thanks for the quick response .. and sorry for me replying just now. I
> somehow missed the message :)
>
> On Tue, Apr 29, 2008 at 11:38 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
>>  > Hi all,
>>  >
>>  > [working on Fedora 8 with GCC]
>>  >
>>  > I have a minor nit. The root cause is probably not in GnuTLS but in me
>>  > overlooking something...
>>  >
>>  > I supply the int fd I got from socket() to gnutls_transport_set_ptr().
>>  > However, when I do so, I receive the following GCC warning:
>>  >
>>  > cast to pointer from integer of different size
>>  >
>>  > This is annoying during the build process, but of course tolerable. I
>>  > would prefer to see this warning go away, but I do not like to reduce
>>  > GCCs warning level. Any advise would be appreciated.
>>
>>  Try to use a cast when calling the function, such as:
>>
>>   gnutls_transport_set_ptr (session, (gnutls_transport_ptr) sockfd);
>
> This is what I am doing. A snapshot of the actual code is here:
>
> http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/nsd_gtls.c;h=b1713240399448e042a27d22caf5a2f044fd65a1;hb=tls
>
> (e.g. in line 364).
>
> I replaced this with
>
> int ii = 6;
> gnutls_transport_set_ptr(pNew->sess, (gnutls_transport_ptr) ii);
>
> But I still get the same warning message. I am a bit puzzled,
> especially as this seems to be unusual...

Hm, could it be that you should add a trailing '_t'?  That's the new
type name.  However, there is a #define from the old name to the new
name in compat.h, which is always included, so I'm not sure it will
help.  It is the Right Thing though.

Which compiler flags do you use?  Maybe you could cut'n'paste the entire
command line that compiles the file and the warning messages.  Maybe
some earlier message helps understand this.

Generally, this casting is a bit ugly, and it can generate warnings.
Internally in gnutls, there is the GNUTLS_POINTER_TO_INT_CAST #define to
work around this, and similar stuff can also be found in glib.  I'm not
sure what the best solution is here.  Possibly we should have required
that the socket integer is passed to that function as a pointer instead
of as the value itself, but it is a bit late to fix that now.  Thoughts?

/Simon




From rgerhards at gmail.com  Mon May  5 14:54:37 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 5 May 2008 14:54:37 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
In-Reply-To: <87ve1tyogj.fsf@mocca.josefsson.org>
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	<87od7ss5n9.fsf@mocca.josefsson.org>
	<dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>
	<87ve1tyogj.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805050554i72d1b5d4ha677004a9bd791ce@mail.gmail.com>

Hi Simon,

thanks for your help. I changed the type, but, as you expected, that
didn't change anything.

Here is the relevant part from the build log:

make[2]: Entering directory `/home/rger/proj/rsyslog/runtime'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I..  -pthread -I../runtime -I..    -g -O2 -W -Wall -Wformat-security
-Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g -MT
lmnsd_gtls_la-nsd_gtls.lo -MD -MP -MF .deps/lmnsd_gtls_la-nsd_gtls.Tpo
-c -o lmnsd_gtls_la-nsd_gtls.lo `test -f 'nsd_gtls.c' || echo
'./'`nsd_gtls.c
 gcc -DHAVE_CONFIG_H -I. -I.. -pthread -I../runtime -I.. -g -O2 -W -Wall
-Wformat-security -Wshadow -Wcast-align -Wpointer-arith
-Wmissing-format-attribute -g -MT lmnsd_gtls_la-nsd_gtls.lo -MD -MP
-MF .deps/lmnsd_gtls_la-nsd_gtls.Tpo -c nsd_gtls.c  -fPIC -DPIC
-o .libs/lmnsd_gtls_la-nsd_gtls.o
nsd_gtls.c: In function 'AcceptConnReq':
nsd_gtls.c:380: warning: cast to pointer from integer of different size
nsd_gtls.c: In function 'Rcv':
nsd_gtls.c:419: warning: unused variable 'gnuRet'
nsd_gtls.c: In function 'Connect':
nsd_gtls.c:512: warning: cast to pointer from integer of different size
mv -f .deps/lmnsd_gtls_la-nsd_gtls.Tpo .deps/lmnsd_gtls_la-nsd_gtls.Plo

[this is an autotools-generated Makefile]. The code compiled was this version:

http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/nsd_gtls.c;h=20de772a867f1c4605fc9c2a9f8ebbf6557620df;hb=tls

The warning in line 419 is expected and correct. The other two stem
back to GnuTLS.

I wonder if I am the only one seeing this warnings. Please let me
re-iterate that I am compiling with 1.6, because I need to life with
what usually is on the system (begin the syslogd I need to be very
careful on what I require). I compiled under Fedora 8 with GCC 4.1.2
20070925 (Red Hat 4.1.2-33).

Let me know if you could need any more information.

Thanks, Rainer


On Mon, May 5, 2008 at 1:34 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>  > Thanks for the quick response .. and sorry for me replying just now. I
>  > somehow missed the message :)
>  >
>  > On Tue, Apr 29, 2008 at 11:38 PM, Simon Josefsson <simon at josefsson.org> wrote:
>  >> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>  >>
>  >>  > Hi all,
>  >>  >
>  >>  > [working on Fedora 8 with GCC]
>  >>  >
>  >>  > I have a minor nit. The root cause is probably not in GnuTLS but in me
>  >>  > overlooking something...
>  >>  >
>  >>  > I supply the int fd I got from socket() to gnutls_transport_set_ptr().
>  >>  > However, when I do so, I receive the following GCC warning:
>  >>  >
>  >>  > cast to pointer from integer of different size
>  >>  >
>  >>  > This is annoying during the build process, but of course tolerable. I
>  >>  > would prefer to see this warning go away, but I do not like to reduce
>  >>  > GCCs warning level. Any advise would be appreciated.
>  >>
>  >>  Try to use a cast when calling the function, such as:
>  >>
>  >>   gnutls_transport_set_ptr (session, (gnutls_transport_ptr) sockfd);
>  >
>  > This is what I am doing. A snapshot of the actual code is here:
>  >
>  > http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/nsd_gtls.c;h=b1713240399448e042a27d22caf5a2f044fd65a1;hb=tls
>  >
>  > (e.g. in line 364).
>  >
>  > I replaced this with
>  >
>  > int ii = 6;
>  > gnutls_transport_set_ptr(pNew->sess, (gnutls_transport_ptr) ii);
>  >
>  > But I still get the same warning message. I am a bit puzzled,
>  > especially as this seems to be unusual...
>
>  Hm, could it be that you should add a trailing '_t'?  That's the new
>  type name.  However, there is a #define from the old name to the new
>  name in compat.h, which is always included, so I'm not sure it will
>  help.  It is the Right Thing though.
>
>  Which compiler flags do you use?  Maybe you could cut'n'paste the entire
>  command line that compiles the file and the warning messages.  Maybe
>  some earlier message helps understand this.
>
>  Generally, this casting is a bit ugly, and it can generate warnings.
>  Internally in gnutls, there is the GNUTLS_POINTER_TO_INT_CAST #define to
>  work around this, and similar stuff can also be found in glib.  I'm not
>  sure what the best solution is here.  Possibly we should have required
>  that the socket integer is passed to that function as a pointer instead
>  of as the value itself, but it is a bit late to fix that now.  Thoughts?
>
>  /Simon
>




From ludo at gnu.org  Mon May  5 15:23:44 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 05 May 2008 15:23:44 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	<87od7ss5n9.fsf@mocca.josefsson.org>
	<dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>
Message-ID: <87hcdc995r.fsf@gnu.org>

Hi,

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> int ii = 6;
> gnutls_transport_set_ptr(pNew->sess, (gnutls_transport_ptr) ii);
>
> But I still get the same warning message. I am a bit puzzled,
> especially as this seems to be unusual...

I suppose it just means that sizeof (void *) != sizeof (int), as might
be the case on some 64-bit architectures.

Thanks,
Ludovic.





From rgerhards at gmail.com  Mon May  5 15:45:26 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 5 May 2008 15:45:26 +0200
Subject: [Help-gnutls] Re: gnutls_transport_ptr and int fd's
In-Reply-To: <87hcdc995r.fsf@gnu.org>
References: <dc67eef70804180819n3b01b5b3of322f9af1a634f9c@mail.gmail.com>
	<87od7ss5n9.fsf@mocca.josefsson.org>
	<dc67eef70805050035l32a36711t9a99b2240d0f6ecb@mail.gmail.com>
	<87hcdc995r.fsf@gnu.org>
Message-ID: <dc67eef70805050645id744023s91f25b0da2886b8a@mail.gmail.com>

Hi Ludovic,

thanks for your reply.

On Mon, May 5, 2008 at 3:23 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>  I suppose it just means that sizeof (void *) != sizeof (int), as might
>  be the case on some 64-bit architectures.

Yes, I think this is the case. As I wrote in my initial post, the
warning is quite acceptable, but anoying (especially if user's begin
to ask "what is wrong?" ;)). I can of course disable GCC's warnings
completely, but that, too, isn't very appealing.

And if a void* is treated as an int, it may even bring some
(portability) problems (and how about C99) in the future. So it may be
worth looking into it. ...but: as I said: nothing really pressing. If
there is a solution, that's fine, if not, that's fine too.

Rainer




From simon at josefsson.org  Tue May  6 14:40:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 May 2008 14:40:59 +0200
Subject: [Help-gnutls] GnuTLS 2.2.3
Message-ID: <87abj361wk.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.2.3.

GnuTLS is a modern C library that implement 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 core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO compression,
the OpenSSL compatibility library -- and the self tests and command line
tools are distributed under the GNU General Public License version 3.0
(or later).  The manual is distributed under the GNU Free Documentation
License version 1.2 (or later).

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

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

* Version 2.2.3 (released 2008-05-06)

** Increase default handshake packet size limit to 48kb.
The old limit was 16kb and some servers send huge list of trusted CAs,
thus running into the limit.  FYI, applications can further increase
this limit using gnutls_handshake_set_max_packet_length.  Thanks to
Marc Haber <mh+debian-bugs at zugschlus.de> and "Marc F. Clemente"
<marc at mclemente.net> for reporting and providing test servers.

** Fix compilation error related to __FUNCTION__ on some systems.
Reported by Tim Mooney, see
<https://savannah.gnu.org/support/?106267>.

** Documented the --priority option to gnutls-cli and gnutls-serv.

** Fix fopen file descriptor leak in PSK server code.
Thanks to Laurence Withers <l at lwithers.me.uk>, see
<http://lists.gnu.org/archive/html/gnutls-devel/2008-04/msg00002.html>.

** Build Guile code with -fgnu89-inline only when supported.
Reported by Kris Karas <ktk at enterprise.bidmc.harvard.edu> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2708>.

** Make Camellia encryption work.
Reported by Yoshisato YANAGISAWA <yanagisawa at csg.is.titech.ac.jp> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2746>.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.3.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.2.3.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.3.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.3.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.2.3.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: 2008-06-30]
      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>

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:

285346586fa67c97c8c3d6f8a6bc22a55b188f76  gnutls-2.2.3.tar.bz2

05aad4b90b89fbd3aa22966dc4f08539ba3e579fd0fef9f10c0d32d0  gnutls-2.2.3.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-devel 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 consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.3.

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

The Windows binary installer and OpenPGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.2.3.exe (13MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.3.exe.sig

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.3.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.3.zip.sig

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

e86df96993f5ef6017036c9e7db52992f38abedc  gnutls-2.2.3.exe
0c077a6cd8de514393d8a70d9c9648326277155970c693fc260e50f5  gnutls-2.2.3.exe

aba154fa97b35ea9844dc792f4ec53553e1bccf6  gnutls-2.2.3.zip
035b0a32413dd321f8fde749dfb1383e7962c81c0832bec1d26cbd76  gnutls-2.2.3.zip

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

GnuTLS messages have been translated into Dutch, German, Malay, Polish
and Swedish.  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, 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/20080506/a16c613c/attachment.pgp>

From nagsvijay at rediffmail.com  Wed May 14 06:54:28 2008
From: nagsvijay at rediffmail.com (Nagarajan M)
Date: 14 May 2008 04:54:28 -0000
Subject: [Help-gnutls] Client Handshake error
Message-ID: <20080514045428.23864.qmail@f4mail-235-230.rediffmail.com>


I have generated certificates as mentioned in the site.But am using a client C++ code where am unable to verfiy the certificate,what may be the problemSSL certificate problem, verify that the CA cert is OK. Details:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080514/da4b4f7f/attachment.htm>

From simon at josefsson.org  Wed May 14 11:32:30 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 14 May 2008 11:32:30 +0200
Subject: [Help-gnutls] Re: Client Handshake error
In-Reply-To: <20080514045428.23864.qmail@f4mail-235-230.rediffmail.com>
	(Nagarajan M.'s message of "14 May 2008 04:54:28 -0000")
References: <20080514045428.23864.qmail@f4mail-235-230.rediffmail.com>
Message-ID: <87bq395iz5.fsf@mocca.josefsson.org>

"Nagarajan M" <nagsvijay at rediffmail.com> writes:

> I have generated certificates as mentioned in the site.But am using a
> client C++ code where am unable to verfiy the certificate,what may be
> the problemSSL certificate problem, verify that the CA cert is
> OK. Details:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

You'll have to give more information here, such as the certificate you
are using, describe what purpose you are using it for (SSL client, SSL
server), and more verbose error message.  The error looks like an
openssl error message to me...

/Simon




From preeti.shandilya at aricent.com  Fri May 16 12:18:35 2008
From: preeti.shandilya at aricent.com (preeti.shandilya)
Date: Fri, 16 May 2008 15:48:35 +0530
Subject: [Help-gnutls] libgcrypt
Message-ID: <F907CB6DCEB7FB4AB922043EFC489884058F984366@GUREXMB01.ASIAN.AD.ARICENT.COM>

Hi!

I am facing core dump in libgcypt library on Solaris, during TLS handshake
Following are the library versions.


 1.  libgpg-error-1.5
 2.  libgcrypt-1.4.1
 3.  gnutls-1.6.3 and tried with gnutls-2.2.3 also

Pl find the back trace.

#0  0xfea28598 in do_decrypt (ctx=0xfe37b5f8,
    bx=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
    ax=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:261
#1  0xfea28b34 in rijndael_decrypt (context=0xfe37b5f8,
    b=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
    a=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:679
#2  0xfea28d0c in rijndael_setkey (context=0xa1c6e0,
    key=0xa15868 "???g[0?? ??7\020?\221\237", keylen=16) at rijndael.c:833
#3  0xfea13de4 in _gcry_cipher_ctl (h=0xa1c678, cmd=1, buffer=0xa15868,
    buflen=16) at cipher.c:831
#4  0xfeb4a07c in gc_cipher_setkey (handle=0xa1c678, keylen=16,
    key=0xa15868 "???g[0?? ??7\020?\221\237") at gc-libgcrypt.c:190
#5  0xfeb2884c in _gnutls_cipher_init (cipher=GNUTLS_CIPHER_AES_128_CBC,
    key=0xa1aa44, iv=0xa1aa34) at gnutls_cipher_int.c:83
#6  0xfeb34080 in _gnutls_write_connection_state_init (session=0xa1a6d8)
    at gnutls_constate.c:820
#7  0xfeb1e6a0 in _gnutls_send_handshake_final (session=0xa1a6d8, init=1)
    at gnutls_handshake.c:2438
#8  0xfeb22964 in _gnutls_handshake_common (session=0xa1a6d8)
    at gnutls_handshake.c:2651
#9  0xfeb22bec in gnutls_handshake (session=0xa1a6d8)
    at gnutls_handshake.c:2255
#10 0x0010d4cc in AAATLSWrapper::performHandshake (this=0x9b7330, socketFd=9)

Pl suggest the solution if anybody has faced this problem. I have a multithreaded application.

Regards
Preeti

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080516/e3e7c708/attachment.htm>

From nmav at gnutls.org  Fri May 16 19:05:02 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 16 May 2008 20:05:02 +0300
Subject: [Help-gnutls] libgcrypt
In-Reply-To: <F907CB6DCEB7FB4AB922043EFC489884058F984366@GUREXMB01.ASIAN.AD.ARICENT.COM>
References: <F907CB6DCEB7FB4AB922043EFC489884058F984366@GUREXMB01.ASIAN.AD.ARICENT.COM>
Message-ID: <482DBEBE.2070502@gnutls.org>

preeti.shandilya wrote:
> Hi!
> 
> I am facing core dump in libgcypt library on Solaris, during TLS handshake
> Following are the library versions.

It could be an alignment problem. What kind of hardware is this? I CC
the gcrypt mailing list since this is relevant to libgcrypt mostly.

regards,
Nikos

PS. Does the make check in libgcrypt succeed?

> 
>  1.  libgpg-error-1.5
>  2.  libgcrypt-1.4.1
>  3.  gnutls-1.6.3 and tried with gnutls-2.2.3 also
> 
> Pl find the back trace.
> 
> #0  0xfea28598 in do_decrypt (ctx=0xfe37b5f8,
>     bx=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
>     ax=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:261
> #1  0xfea28b34 in rijndael_decrypt (context=0xfe37b5f8,
>     b=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
>     a=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:679
> #2  0xfea28d0c in rijndael_setkey (context=0xa1c6e0,
>     key=0xa15868 "???g[0?? ??7\020?\221\237", keylen=16) at rijndael.c:833
> #3  0xfea13de4 in _gcry_cipher_ctl (h=0xa1c678, cmd=1, buffer=0xa15868,
>     buflen=16) at cipher.c:831
> #4  0xfeb4a07c in gc_cipher_setkey (handle=0xa1c678, keylen=16,
>     key=0xa15868 "???g[0?? ??7\020?\221\237") at gc-libgcrypt.c:190
> #5  0xfeb2884c in _gnutls_cipher_init (cipher=GNUTLS_CIPHER_AES_128_CBC,
>     key=0xa1aa44, iv=0xa1aa34) at gnutls_cipher_int.c:83
> #6  0xfeb34080 in _gnutls_write_connection_state_init (session=0xa1a6d8)
>     at gnutls_constate.c:820
> #7  0xfeb1e6a0 in _gnutls_send_handshake_final (session=0xa1a6d8, init=1)
>     at gnutls_handshake.c:2438
> #8  0xfeb22964 in _gnutls_handshake_common (session=0xa1a6d8)
>     at gnutls_handshake.c:2651
> #9  0xfeb22bec in gnutls_handshake (session=0xa1a6d8)
>     at gnutls_handshake.c:2255
> #10 0x0010d4cc in AAATLSWrapper::performHandshake (this=0x9b7330, socketFd=9)
> 
> Pl suggest the solution if anybody has faced this problem. I have a multithreaded application.
> 
> Regards
> Preeti




From preeti.shandilya at aricent.com  Mon May 19 10:13:40 2008
From: preeti.shandilya at aricent.com (preeti.shandilya)
Date: Mon, 19 May 2008 13:43:40 +0530
Subject: [Help-gnutls] libgcrypt
In-Reply-To: <482DBEBE.2070502@gnutls.org>
References: <F907CB6DCEB7FB4AB922043EFC489884058F984366@GUREXMB01.ASIAN.AD.ARICENT.COM>
	<482DBEBE.2070502@gnutls.org>
Message-ID: <F907CB6DCEB7FB4AB922043EFC489884058F9E5650@GUREXMB01.ASIAN.AD.ARICENT.COM>

Hi !

Make check is not successful
2 checks out of 16 are failing

Attached is the err file

Spec of the machine is as follows (uname -a)

SunOS topaz 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-1500

Let me know if there is any possible way of removing the error

Regards
Preeti

-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos
Sent: Friday, May 16, 2008 10:35 PM
To: Preeti Shandilya
Cc: help-gnutls at gnu.org; Nimish Bhargava; gcrypt-devel at gnupg.org
Subject: Re: [Help-gnutls] libgcrypt

preeti.shandilya wrote:
> Hi!
>
> I am facing core dump in libgcypt library on Solaris, during TLS handshake
> Following are the library versions.

It could be an alignment problem. What kind of hardware is this? I CC
the gcrypt mailing list since this is relevant to libgcrypt mostly.

regards,
Nikos

PS. Does the make check in libgcrypt succeed?

>
>  1.  libgpg-error-1.5
>  2.  libgcrypt-1.4.1
>  3.  gnutls-1.6.3 and tried with gnutls-2.2.3 also
>
> Pl find the back trace.
>
> #0  0xfea28598 in do_decrypt (ctx=0xfe37b5f8,
>     bx=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
>     ax=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:261
> #1  0xfea28b34 in rijndael_decrypt (context=0xfe37b5f8,
>     b=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?",
>     a=0xfe37b5e8 "gC??Q\232???\232x?\t?\021?") at rijndael.c:679
> #2  0xfea28d0c in rijndael_setkey (context=0xa1c6e0,
>     key=0xa15868 "???g[0?? ??7\020?\221\237", keylen=16) at rijndael.c:833
> #3  0xfea13de4 in _gcry_cipher_ctl (h=0xa1c678, cmd=1, buffer=0xa15868,
>     buflen=16) at cipher.c:831
> #4  0xfeb4a07c in gc_cipher_setkey (handle=0xa1c678, keylen=16,
>     key=0xa15868 "???g[0?? ??7\020?\221\237") at gc-libgcrypt.c:190
> #5  0xfeb2884c in _gnutls_cipher_init (cipher=GNUTLS_CIPHER_AES_128_CBC,
>     key=0xa1aa44, iv=0xa1aa34) at gnutls_cipher_int.c:83
> #6  0xfeb34080 in _gnutls_write_connection_state_init (session=0xa1a6d8)
>     at gnutls_constate.c:820
> #7  0xfeb1e6a0 in _gnutls_send_handshake_final (session=0xa1a6d8, init=1)
>     at gnutls_handshake.c:2438
> #8  0xfeb22964 in _gnutls_handshake_common (session=0xa1a6d8)
>     at gnutls_handshake.c:2651
> #9  0xfeb22bec in gnutls_handshake (session=0xa1a6d8)
>     at gnutls_handshake.c:2255
> #10 0x0010d4cc in AAATLSWrapper::performHandshake (this=0x9b7330, socketFd=9)
>
> Pl suggest the solution if anybody has faced this problem. I have a multithreaded application.
>
> Regards
> Preeti

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility forloss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: err
Type: application/octet-stream
Size: 1064 bytes
Desc: err
URL: </pipermail/attachments/20080519/f83c5acf/attachment.obj>

From simon at josefsson.org  Mon May 19 14:00:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 14:00:43 +0200
Subject: [Help-gnutls] GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
Message-ID: <87ve1a4i6s.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.2.4.

This release fixes three serious bugs that can crash the GnuTLS library.
We invite more detailed analysis of the problem, following our general
security advisory approach explained on:

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

Particularly, it would be useful to answer the question of whether these
bugs can be exploited remotely to execute arbitrary code.  It is
certainly possible to cause the server to crash.  We don't have
resources to investigate this problem more ourselves currently.

Please send your analysis to gnutls-dev at gnupg.org and I'll update the
security advisory web page pointing to it.  Be sure to check the web
page first to get updates on what has been done so far.

Below is attached our own security advisory and patch.  The file has
been verified to apply to the latest stable release of the recent stable
branches: version 1.4.5, 1.6.3, 2.0.4, and 2.2.3.  The patch will also
work with version 1.2.11 but you will need to apply it manually.  The
patch also apply to the latest development version 2.3.9 but keep in
mind that this version is not intended for production systems.

GnuTLS is a modern C library that implement 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 core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO compression,
the OpenSSL compatibility library -- and the self tests and command line
tools are distributed under the GNU General Public License version 3.0
(or later).  The manual is distributed under the GNU Free Documentation
License version 1.2 (or later).

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

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

* Version 2.2.4 (released 2008-05-19)

** Fix three security vulnerabilities.  [GNUTLS-SA-2008-1]
Thanks to CERT-FI for finding the bugs and providing detailed reports,
which allowed the bugs to be reproduced and fixed easily.  Patches
developed by Simon Josefsson and Nikos Mavrogiannopoulos.  Any updates
with more details about these vulnerabilities will be added to
<http://www.gnu.org/software/gnutls/security.html>

*** [GNUTLS-SA-2008-1-1]
*** libgnutls: Fix crash when sending invalid server name.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to store more session resumption data than what was
allocated for, thus overwriting unallocated memory.

*** [GNUTLS-SA-2008-1-2]
*** libgnutls: Fix crash when sending repeated client hellos.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
triggers a null-pointer dereference.

*** [GNUTLS-SA-2008-1-3]
*** libgnutls: Fix crash in cipher padding decoding for invalid record lengths.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to read memory beyond the end of the received record.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnu.org/pub/gnutls/gnutls-2.2.4.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.2.4.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/pub/gnutls/gnutls-2.2.4.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.4.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.2.4.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: 2008-06-30]
      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>

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:

3b5d8138e3ce78b3a25f8d0491da438bb8ef6a4e  gnutls-2.2.4.tar.bz2

85b29eab286bb55d48d1454bfcf5bebba63581159c9dd0850a32a4c3  gnutls-2.2.4.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-devel 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 consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.4.

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

The Windows binary installer and OpenPGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.2.4.exe (13MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.4.exe.sig

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.4.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.4.zip.sig

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

331a70b9cb64954d3187c880c1bb6994b4511775  gnutls-2.2.4.exe
9d1a58db1683673f92d1ed1611b4dfd416b0d447a1d393993cf4b494 gnutls-2.2.4.exe

df7478d51ce338844496b2bb1a888c4931e3e88f  gnutls-2.2.4.zip
c7c4bf3ea70ab24c070ee50a4497d403a44dada2b52b80d6bb413b49  gnutls-2.2.4.zip

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

GnuTLS messages have been translated into Dutch, German, Malay, Polish
and Swedish.  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, 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/20080519/ca52caaf/attachment.pgp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-sa-2008-01.txt.asc
URL: </pipermail/attachments/20080519/ca52caaf/attachment.asc>

From simon at josefsson.org  Mon May 19 14:42:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 14:42:03 +0200
Subject: [Help-gnutls] Re: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87ve1a4i6s.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 19 May 2008 14:00:43 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
Message-ID: <87r6byv52c.fsf@mocca.josefsson.org>

Two silly typos in the announcement:

> Please send your analysis to gnutls-dev at gnupg.org and I'll update the

Of course, that should be gnutls-devel at gnu.org.

> lead to a Daniel of Service attack to disable the server.  The bug

That would be 'Denial of Service'... thanks Daniel for noticing this! :)

/Simon




From ludo at gnu.org  Mon May 19 14:47:06 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 19 May 2008 14:47:06 +0200
Subject: [Help-gnutls] Re: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
Message-ID: <87hccu8nqt.fsf@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> writes:

> Here are the BZIP2 compressed sources (4.8MB):
>
>   ftp://ftp.gnu.org/pub/gnutls/gnutls-2.2.4.tar.bz2

This should read:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.2.4.tar.bz2

BTW, it might be worth posting to `info-gnu' as well?

Thanks,
Ludovic.





From bgoldsbury at gleim.com  Mon May 19 16:05:04 2008
From: bgoldsbury at gleim.com (Ben Goldsbury)
Date: Mon, 19 May 2008 10:05:04 -0400
Subject: [Help-gnutls] Wildcard Certificate Woes
Message-ID: <1211205904.13328.65.camel@bengoldsbury>

?Hello,

I have a valid wildcard certificate purchased from Godaddy.  This
certificate has the normal cert/key and an issuing certificate.  The
issuing certificate is actually a chain of 3 certificates.

I'm using Debian Etch.

Using openssl's tools, I am able to create a valid server/client
relationship.

Using gnutls's tools (and programs built on them), I am not able to get
the client to validate the server's certificate.


Here's what I'm doing...

On machine1.teamgleim.com:
gnutls-serv \
        --x509keyfile /etc/ssl/my_ssl/server.key \
        --x509certfile /etc/ssl/my_ssl/server.crt \
        --x509cafile /etc/ssl/my_ssl/ca.crt

Output:
Processed 3 CA certificate(s).
Echo Server ready. Listening to port '5556'.


On machine2.teamgleim.com:
gnutls-cli \
        --x509certfile /etc/ssl/my_ssl/server.crt \
        --x509cafile /etc/ssl/certs/ca-certificates.crt \
        machine1.teamgleim.com -p 5556

Output:
Processed 102 CA certificate(s).
Resolving 'machine1.teamgleim.com'...
Connecting to '172.17.1.19:5556'...
- Successfully sent 0 certificate(s) to server.
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches '?machine1.teamgleim.com'.
 # valid since: Tue Nov 20 12:03:29 EST 2007
 # expires at: Sun Jan 11 13:59:39 EST 2009
 # fingerprint: 20:FA:52:70:69:57:6A:B9:38:BD:60:C8:72:D6:37:23
 # Subject's DN: O=*.teamgleim.com,OU=Domain Control
Validated,CN=*.teamgleim.com
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\,
Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure
Certification Authority,serialNumber=<number>


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS 1.1
- Key Exchange: RSA
- Cipher: AES 128 CBC
- MAC: SHA
- Compression: DEFLATE
*** Verifying server certificate failed...


It seems like the server is not sending the full ca.crt to the client.
My ca.crt is actually a combination of 3 certificates (as I understand
it):

1: Godaddy's certificate for signing my wildcard
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc.,
OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure
Certification Authority/serialNumber=<some number>

2: Godaddy's certificate from Valicert
Subject: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2
Certification Authority

3: Valicert's root certificate
Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert
Class 2 Policy Validation Authority,
CN=http://www.valicert.com//emailAddress=info at valicert.com



Also, if I run the client with the ca certificate specified, as shown
below, everything works correctly.  This leads me to believe that gnutls
understands my ca.crt correctly:
gnutls-cli \
        --x509certfile /etc/ssl/my_ssl/server.crt ?\
        --x509cafile /etc/ssl/my_ssl/ca.crt \
        machine1.teamgleim.com -p 5556 

Output:
Processed 3 CA certificate(s).
Resolving 'machine1.teamgleim.com'...
Connecting to '172.17.1.19:5556'...
- Successfully sent 0 certificate(s) to server.
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'machine1.teamgleim.com'.
 # valid since: Tue Nov 20 12:03:29 EST 2007
 # expires at: Sun Jan 11 13:59:39 EST 2009
 # fingerprint: 20:FA:52:70:69:57:6A:B9:38:BD:60:C8:72:D6:37:23
 # Subject's DN: O=*.teamgleim.com,OU=Domain Control
Validated,CN=*.teamgleim.com
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\,
Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure
Certification Authority,serialNumber=<some number>


- Peer's certificate is trusted
- Version: TLS 1.1
- Key Exchange: RSA
- Cipher: AES 128 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed


Certificates used:

ca.crt:
-----BEGIN CERTIFICATE-----
MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28g
RGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExMTYw
MTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
QXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWRkeS5j
b20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTtwY6vj3D3H
KrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqVTr9vcyOdQm
VZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aLGbqGmu75RpR
SgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo7RJlbmr2EkRT
cDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgWJCJjPOq8lh8BJ
6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAwEAAaOCATIwggEu
MB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVHSMEGDAWgBTSxLDS
kdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEB
BCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wRgYDVR0f
BD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBv
c2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVHSAAMDgwNgYIKwYBBQUH
AgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTAO
BgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBANKGwOy9+aG2Z+5mC6IG
OgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPIUyIXvJxwqoJKSQ3kbTJSMU
A2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL5CkKSkB2XIsKd83ASe8T+5o
0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9p0iRFEUOOjZv2kWzRaJBydTX
RE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsxuxN89txJx9OjxUUAiKEngHUuH
qDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZEjYx8WnM25sgVjOuH0aBsXBTWV
U+4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Zh
bGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIElu
Yy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24g
QXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAe
BgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDYyMFoX
DTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZSBHbyBE
YWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgMiBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC
ggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCAPVYYYwhv
2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6wwdhFJ2+q
N1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXiEqITLdiO
r18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMYavx4A6lN
f4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+YihfukEH
U1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ4EFgQU0sSw0pHU
TBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBuzEkMCIGA1UEBxMb
VmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwg
SW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2xpY3kgVmFsaWRhdGlv
biBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudmFsaWNlcnQuY29tLzEg
MB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CAQEwDwYDVR0TAQH/BAUw
AwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmdv
ZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jZXJ0aWZpY2F0ZXMu
Z29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybDBLBgNVHSAERDBCMEAGBFUd
IAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNv
bS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQC1
QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+Sn1eocSxI0YGyeR+sBjUZsE4O
WBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgMQLARzLrUc+cb53S8wGd9D0Vmsf
SxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j09VZw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0
IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAz
BgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9y
aXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG
9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE5MDYy
NjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29y
azEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENs
YXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRw
Oi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNl
cnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5avIWZJV16vY
dA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zfN1SLUzm1NZ9
WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwbP7RfZHM047QS
v4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADt/UG9v
UJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQC1u+mNr0HZDzTu
IYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMMj4QssxsodyamEwC
W/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd
-----END CERTIFICATE-----

server.crt:
-----BEGIN CERTIFICATE-----
MIIE8DCCA9igAwIBAgIDQcJRMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzExMjAxNzAzMjlaFw0wOTAxMTExODU5MzlaMFcxGDAWBgNVBAoTDyoudGVh
bWdsZWltLmNvbTEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgw
FgYDVQQDEw8qLnRlYW1nbGVpbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAK0OZ2DaHF6K4OMnSR36FHfb2Dx0Hy13oyS4O4X1+rJfygXHQ03a0lY4Rlwq
eMQJYQyvuFABqfoi/hwH9bFqYvFSqtG2Rt9OUuTOaQji4Mh3pmmPty1Im4w0u4vE
ivWgbAldo0MFGj2YkEQjlnxgZLjQKJDPDmDVmPjxxYW3l5ZNAgMBAAGjggHTMIIB
zzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwVgYDVR0fBE8wTTBLoEmgR4ZFaHR0cDovL2NlcnRpZmljYXRlcy5n
b2RhZGR5LmNvbS9yZXBvc2l0b3J5L2dvZGFkZHlleHRlbmRlZGlzc3VpbmcuY3Js
MFIGA1UdIARLMEkwRwYLYIZIAYb9bQEHFwEwODA2BggrBgEFBQcCARYqaHR0cDov
L2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MH8GCCsGAQUFBwEB
BHMwcTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wSgYIKwYB
BQUHMAKGPmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9y
eS9nZF9pbnRlcm1lZGlhdGUuY3J0MB0GA1UdDgQWBBR+JFYO++zzHbFsMjF81Fj5
Y+NZMzAfBgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zApBgNVHREEIjAg
gg8qLnRlYW1nbGVpbS5jb22CDXRlYW1nbGVpbS5jb20wDQYJKoZIhvcNAQEFBQAD
ggEBACWach3p2jotheD785XJXnyrB6FbTD9oMoGqTVnIGttmpeZY1uXg1fZkAwdG
TqIFawPNlfoTtzeeuMAKI92mQtu+84QyFgs3yGszZtdE8CGk5CVoFUPuzt+eJ87W
SQBKcUAvHDG9X/nmB6EC7TGLwgjvtJGar7a7IgFnofbKI8fN3sKRlU1zRBOvU/mh
QIXKH6nb1aLekYXCvxJ6HBRocdHbG/VkraB0zKdDN/NA7vUPNbw5Js+WGgrpUh4E
4ceIsVU+g4GZ+ZZ9mFEbf5hevtOTK/WT0eYBYk5iWBwi7qegyM8lHRpmIvu5EZWq
2pdyIqMBajb1r8JsLdzuhjt1N1g=
-----END CERTIFICATE-----

/?etc/ssl/certs/ca-certificates.crt:
Debian package containing valid root certificates. Contains a copy of
the Valicert Class 2 Root Cert that also exists in ca.crt.


I'm at a loss here and I don't know enough about SSL to debug much
further.  Anyone able to provide any help?  

Is this a problem with what I'm doing or a bug with GnuTLS?

Reproducible on gnutls 1.4.4, 2.2.1, and 2.3.9.

Thank you.






From dkg-debian.org at fifthhorseman.net  Mon May 19 16:41:46 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 19 May 2008 10:41:46 -0400
Subject: [Help-gnutls] Chained Certificate Woes [was: Re: Wildcard
	Certificate Woes]
In-Reply-To: <1211205904.13328.65.camel@bengoldsbury> (Ben Goldsbury's message
	of "Mon\, 19 May 2008 10\:05\:04 -0400")
References: <1211205904.13328.65.camel@bengoldsbury>
Message-ID: <87k5hq2w5x.fsf@squeak.fifthhorseman.net>

On Mon 2008-05-19 10:05:04 -0400, Ben Goldsbury wrote:

> I have a valid wildcard certificate purchased from Godaddy.  This
> certificate has the normal cert/key and an issuing certificate.  The
> issuing certificate is actually a chain of 3 certificates.

I haven't had a chance to test this myself, but it sounds to me like
you're having a problem with certificate chaining, not with the
wildcard itself.  In particular, it sounds like your gnutls-cli
instance can't complete the trust path from the offered certificate to
one of its trusted CAs because it lacks information about the
intermediate CAs.

> Using openssl's tools, I am able to create a valid server/client
> relationship.

Could you post an example of openssl commands you used which
succeeded?

I suspect what you'll need to do is to add the intermediate
certificates to server.crt (i dunno if they should go above or below
the host's certificate) before invoking gnutls-serv, so that they'll
be offered to complete the trust path.

the --x509cafile option for gnutls-serv is there to verify client
certificates, and (afaik) isn't used to select intermediate certs to
send on during the server certificate validation phase of connection
negotiation.

hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080519/f2617810/attachment.pgp>

From bgoldsbury at gleim.com  Mon May 19 17:00:29 2008
From: bgoldsbury at gleim.com (Ben Goldsbury)
Date: Mon, 19 May 2008 11:00:29 -0400
Subject: [Help-gnutls] Re: Chained Certificate Woes [was: Re: Wildcard
	Certificate Woes]
In-Reply-To: <87k5hq2w5x.fsf@squeak.fifthhorseman.net>
References: <1211205904.13328.65.camel@bengoldsbury>
	<87k5hq2w5x.fsf@squeak.fifthhorseman.net>
Message-ID: <1211209229.16975.5.camel@bengoldsbury>

Dan,

Thanks for your help.  I was able to fix the problem with your advice.

For reference, I used the order of "my cert" -> "goddady cert" ->
"valicert cert" (or least -> most trusted) to create my new server.crt.

I realized after the fact that my openssl s_client/s_server setup was
invalid and giving me bad data.

I owe you a box of cookies.

Thanks again.

On Mon, 2008-05-19 at 10:41 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2008-05-19 10:05:04 -0400, Ben Goldsbury wrote:
> 
> > I have a valid wildcard certificate purchased from Godaddy.  This
> > certificate has the normal cert/key and an issuing certificate.  The
> > issuing certificate is actually a chain of 3 certificates.
> 
> I haven't had a chance to test this myself, but it sounds to me like
> you're having a problem with certificate chaining, not with the
> wildcard itself.  In particular, it sounds like your gnutls-cli
> instance can't complete the trust path from the offered certificate to
> one of its trusted CAs because it lacks information about the
> intermediate CAs.
> 
> > Using openssl's tools, I am able to create a valid server/client
> > relationship.
> 
> Could you post an example of openssl commands you used which
> succeeded?
> 
> I suspect what you'll need to do is to add the intermediate
> certificates to server.crt (i dunno if they should go above or below
> the host's certificate) before invoking gnutls-serv, so that they'll
> be offered to complete the trust path.
> 
> the --x509cafile option for gnutls-serv is there to verify client
> certificates, and (afaik) isn't used to select intermediate certs to
> send on during the server certificate validation phase of connection
> negotiation.
> 
> hth,
> 
>         --dkg





From rgerhards at gmail.com  Mon May 19 20:38:13 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 19 May 2008 20:38:13 +0200
Subject: [Help-gnutls] Authentication during Handshake
Message-ID: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>

Hi,

I am implementing an upcoming IETF standard ( syslog over TLS,
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-12.txt
). As part of that standard, clients and server need to do mutual
authentication, which can either happen via subject names OR via
fingerprints of the certificates.

I would like to do the mutual authentication as part of the handshake,
so that the handshake does not complete successfully if the server can
not successfully authenticate the client or the client not
successfully authenticate the server. Is this possible with GnuTLS? If
so, could you give me a clue on what I need to provide to get it
working.

Any feedback is deeply appreciated.

Thanks,
Rainer




From simon at josefsson.org  Mon May 19 22:17:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 22:17:14 +0200
Subject: [Help-gnutls] Re: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87hccu8nqt.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon, 19
	May 2008 14:47:06 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org> <87hccu8nqt.fsf@gnu.org>
Message-ID: <87d4ni122d.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hello,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Here are the BZIP2 compressed sources (4.8MB):
>>
>>   ftp://ftp.gnu.org/pub/gnutls/gnutls-2.2.4.tar.bz2
>
> This should read:
>
>   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.2.4.tar.bz2

Ah, right.  I'll fix this for the 2.2.5 release.. ;)

> BTW, it might be worth posting to `info-gnu' as well?

That should have been the case.

/Simon




From simon at josefsson.org  Mon May 19 22:21:33 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 22:21:33 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	(Rainer Gerhards's message of "Mon, 19 May 2008 20:38:13 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
Message-ID: <878wy611v6.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi,
>
> I am implementing an upcoming IETF standard ( syslog over TLS,
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-12.txt
> ). As part of that standard, clients and server need to do mutual
> authentication, which can either happen via subject names OR via
> fingerprints of the certificates.
>
> I would like to do the mutual authentication as part of the handshake,
> so that the handshake does not complete successfully if the server can
> not successfully authenticate the client or the client not
> successfully authenticate the server. Is this possible with GnuTLS? If
> so, could you give me a clue on what I need to provide to get it
> working.
>
> Any feedback is deeply appreciated.

If I understand correctly, you want to implement TLS client
authentication, i.e. when the client also uses a key+certificate.  Are
you working on the client or server side, or both?  In any case, check
the gnutls examples, there should be examples for this.

/Simon




From rgerhards at gmail.com  Mon May 19 22:38:15 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 19 May 2008 22:38:15 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <878wy611v6.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>

Hi Simon,

I am working on both the client and server sides.

What gives me most problems is the fingerprint authentication. In
essence, each peer has a list of valid (remote peer's) certificate
fingerprints. If the actual cert's fingerprint is in this list, the
remote peer is succesfully authenticated. this is an alternate auth
mode that does not require pki.

I do not find samples of such and i have gotten the impression that
something like this is not supported.

In essence, I am looking for something like a callback that is called
during handshake with the remote cert and that can reply with auth
success/failure - all while in the handshaking porcess.

Does that make any sense?

Rainer

On 5/19/08, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>> Hi,
>>
>> I am implementing an upcoming IETF standard ( syslog over TLS,
>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-12.txt
>> ). As part of that standard, clients and server need to do mutual
>> authentication, which can either happen via subject names OR via
>> fingerprints of the certificates.
>>
>> I would like to do the mutual authentication as part of the handshake,
>> so that the handshake does not complete successfully if the server can
>> not successfully authenticate the client or the client not
>> successfully authenticate the server. Is this possible with GnuTLS? If
>> so, could you give me a clue on what I need to provide to get it
>> working.
>>
>> Any feedback is deeply appreciated.
>
> If I understand correctly, you want to implement TLS client
> authentication, i.e. when the client also uses a key+certificate.  Are
> you working on the client or server side, or both?  In any case, check
> the gnutls examples, there should be examples for this.
>
> /Simon
>




From simon at josefsson.org  Mon May 19 22:53:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 22:53:16 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	(Rainer Gerhards's message of "Mon, 19 May 2008 22:38:15 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
Message-ID: <87wslqyq0z.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi Simon,

Hi Rainer!

> I am working on both the client and server sides.

Ok.

> What gives me most problems is the fingerprint authentication. In
> essence, each peer has a list of valid (remote peer's) certificate
> fingerprints. If the actual cert's fingerprint is in this list, the
> remote peer is succesfully authenticated. this is an alternate auth
> mode that does not require pki.
>
> I do not find samples of such and i have gotten the impression that
> something like this is not supported.

Ah, I thought you wanted to implement the normal client PKI mutual auth
approach.  This is the normal way you do authentication using TLS
libraries, and it should be relatively straightforward.

> In essence, I am looking for something like a callback that is called
> during handshake with the remote cert and that can reply with auth
> success/failure - all while in the handshaking porcess.
>
> Does that make any sense?

Yes, although I'm not sure it is a good idea to do it as part of the
handshake: until the handshake is over, you don't know whether there is
a man in the middle attacker present.  I suggest completing the
handshake as normal, and then compare fingerprints.  If fingerprint
comparisons fails, shut down the TLS session.

Ideally, I think the IETF draft should discuss some of these details.
It is easy to implement ssh-style leap-of-faith authentication
incorrectly.

/Simon

>
> Rainer
>
> On 5/19/08, Simon Josefsson <simon at josefsson.org> wrote:
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
>>> Hi,
>>>
>>> I am implementing an upcoming IETF standard ( syslog over TLS,
>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-12.txt
>>> ). As part of that standard, clients and server need to do mutual
>>> authentication, which can either happen via subject names OR via
>>> fingerprints of the certificates.
>>>
>>> I would like to do the mutual authentication as part of the handshake,
>>> so that the handshake does not complete successfully if the server can
>>> not successfully authenticate the client or the client not
>>> successfully authenticate the server. Is this possible with GnuTLS? If
>>> so, could you give me a clue on what I need to provide to get it
>>> working.
>>>
>>> Any feedback is deeply appreciated.
>>
>> If I understand correctly, you want to implement TLS client
>> authentication, i.e. when the client also uses a key+certificate.  Are
>> you working on the client or server side, or both?  In any case, check
>> the gnutls examples, there should be examples for this.
>>
>> /Simon
>>




From simon at josefsson.org  Mon May 19 22:54:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 22:54:43 +0200
Subject: [Help-gnutls] GnuTLS 2.2.5 - Brown paper bag release
Message-ID: <87ve1aypyk.fsf@mocca.josefsson.org>

We are embarrassed to announce a new stable GnuTLS release: Version 2.2.5.

This release fixes a flaw in the patch for one of the security problems
fixed by version 2.2.4.  The updated advisory is included below.  As
always, further updates will be posted on:

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

I'd also like to take the opportunity to correct another mistake made
the announcement for v2.2.4: please send security analysis to
gnutls-devel at gnu.org and not to any other address.

GnuTLS is a modern C library that implement 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 core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO compression,
the OpenSSL compatibility library -- and the self tests and command line
tools are distributed under the GNU General Public License version 3.0
(or later).  The manual is distributed under the GNU Free Documentation
License version 1.2 (or later).

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

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

* Version 2.2.5 (released 2008-05-19)

** Fix flaw in fix for GNUTLS-SA-2008-1-3.
The flaw would result in incorrectly terminated sessions with the
error "Decryption has failed" when the server sends a small packet
(typically when the session is closed).  Reported by Andreas Metzler
<ametzler at downhill.at.eu.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2807>.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.5.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.2.5.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.5.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.5.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.2.5.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: 2008-06-30]
      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>

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:

7620d092c790f0a5ac5486c3563786ca8777083d  gnutls-2.2.5.tar.bz2

d1cee353902a404a4b02fd0da981e8164c8b60356917abfc781b066c  gnutls-2.2.5.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-devel 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 consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.5.

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

The Windows binary installer and OpenPGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.2.5.exe (13MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.5.exe.sig

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.5.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.5.zip.sig

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

02a84f3844b9376f65edfbb6f6cc377a239a6264  gnutls-2.2.5.exe
1bff90ec17ad99bbf369d65719a1f25fa6d16cbe  gnutls-2.2.5.zip

0a1b1687d7b542e3c41abaa9c321946db32487f936b45ec7bdb0d563  gnutls-2.2.5.exe
8c07ceed8183efb561f99d393bcac6faf669a9c3936df5d5397686fe  gnutls-2.2.5.zip

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

GnuTLS messages have been translated into Dutch, German, Malay, Polish
and Swedish.  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, 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/20080519/2756016f/attachment.pgp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-sa-2008-01.txt.asc
URL: </pipermail/attachments/20080519/2756016f/attachment.asc>

From nmav at gnutls.org  Tue May 20 01:53:10 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 20 May 2008 02:53:10 +0300
Subject: Fwd: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <c331d99a0805191552w36e18d45h32504de49f6d16c0@mail.gmail.com>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<c331d99a0805191552w36e18d45h32504de49f6d16c0@mail.gmail.com>
Message-ID: <c331d99a0805191653s2d662d0br4eb01ab399cde2ed@mail.gmail.com>

On Mon, May 19, 2008 at 11:38 PM, Rainer Gerhards <rgerhards at gmail.com> wrote:
> Hi Simon,
>
> I am working on both the client and server sides.
>
> What gives me most problems is the fingerprint authentication. In
> essence, each peer has a list of valid (remote peer's) certificate
> fingerprints. If the actual cert's fingerprint is in this list, the
> remote peer is succesfully authenticated. this is an alternate auth
> mode that does not require pki.

Actually this is a hack. As far as I remember there was no standard
way to fingerprint a certificate. MD5 was widely used for this but it
is broken now.

The alternative modes of TLS/SSL that do not require PKI are TLS-SRP
(rfc5054) and TLS-PSK (preshared keys - rfc 4279). These are the
straightforward ways to use TLS without PKI (certificates). Then it is
obvious to everybody how to perform the TLS handshake - if the shared
keys do not match it fails.  Gnutls supports both of these modes.

Please suggest these to the authors of the protocol you're referencing.


regards,
Nikos




From rgerhards at gmail.com  Tue May 20 08:39:23 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Tue, 20 May 2008 08:39:23 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <c331d99a0805191552w36e18d45h32504de49f6d16c0@mail.gmail.com>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<c331d99a0805191552w36e18d45h32504de49f6d16c0@mail.gmail.com>
Message-ID: <dc67eef70805192339i1560416clab0451849285dcad@mail.gmail.com>

On Tue, May 20, 2008 at 12:52 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Mon, May 19, 2008 at 11:38 PM, Rainer Gerhards <rgerhards at gmail.com> wrote:
>> Hi Simon,
>>
>> I am working on both the client and server sides.
>>
>> What gives me most problems is the fingerprint authentication. In
>> essence, each peer has a list of valid (remote peer's) certificate
>> fingerprints. If the actual cert's fingerprint is in this list, the
>> remote peer is succesfully authenticated. this is an alternate auth
>> mode that does not require pki.
>
> Actually this is a hack. As far as I remember there was no standard
> way to fingerprint a certificate. MD5 was widely used for this but it
> is broken now.

SHA1 is now suggested.

> The alternative modes of TLS/SSL that do not require PKI are TLS-SRP
> (rfc5054) and TLS-PSK (preshared keys - rfc 4279). These are the
> straightforward ways to use TLS without PKI (certificates). Then it is
> obvious to everybody how to perform the TLS handshake - if the shared
> keys do not match it fails.  Gnutls supports both of these modes.
>
> Please suggest these to the authors of the protocol you're referencing.

I will, but please be aware that I will try to fully implement the
current version first - so that I can provide valid implementor's
suggestion. The syslog WG does not have a really good track record in
reaching its goals and, based on recent discussion, it may not be
useful to suggest anything without very solid evidence. This is also
the reason why I am trying hard to fully understand all implications.

Thanks again for all help, this is extremely valuable.

Rainer




From rgerhards at gmail.com  Tue May 20 08:56:10 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Tue, 20 May 2008 08:56:10 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <87wslqyq0z.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>

On Mon, May 19, 2008 at 10:53 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
[snip]

>> In essence, I am looking for something like a callback that is called
>> during handshake with the remote cert and that can reply with auth
>> success/failure - all while in the handshaking porcess.
>>
>> Does that make any sense?
>
> Yes, although I'm not sure it is a good idea to do it as part of the
> handshake: until the handshake is over, you don't know whether there is
> a man in the middle attacker present.

I am (obviously;)) not a TLS expert. I thought that when I receive a
certificate during the handshake, I can validly assume that it
reflects the remote peer's identity. Could you enlighten me why there
is a man-in-the-middle attack possible? I would like to get this right
because I may need to bring it up inside the IETF discussion (and
obviously I want to be correct then ;)).

>I suggest completing the
> handshake as normal, and then compare fingerprints.  If fingerprint
> comparisons fails, shut down the TLS session.

Actually, this is what I am currently doing. BUT... the syslog story
is even worse ;) Syslog is simplex communication and the syslog TLS
internet draft in question maps this simplex nature onto a TCP stream
WITHOUT acknowledgments (except for the TCP ack, of course). While
this sounds quite strange, there are some good reasons for doing so (I
do not elaborate, because it would end up at a veeeeery long off-topic
post).

Of course, there are inherent problems. One is that after the
handshake completes, the sender  assumes it may send syslog messages.
When the server then drops the connection, some of these messages are
lost, but the sender can not detect which ones exactly. This is NOT
theoretical, I experience that in my lab. It was the reason I asked
the initial question. If you would like to dig deeper into that
problem, you can find a good description in a blog post I wrote a
while ago: http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html

The only solution to this problem is to have the fingerprint
authentication carried out during the handshake procedure - so that
the server does NOT need to drop the connection after the handshake
(at least not for authentication reasons).

> Ideally, I think the IETF draft should discuss some of these details.
> It is easy to implement ssh-style leap-of-faith authentication
> incorrectly.

I have also posted a question on the IETF list when exactly the
fingerprint authentication must happen. In my current understanding
(which may be wrong), the draft actually specifies it must happen
during handshake (which, as I said, would be the right thing here). I
have not yet received a reply. If you are interested, you may follow
the discussion here in the mailing list archive:
http://www.ietf.org/mail-archive/web/syslog/current/msg01910.html

Thanks again for your help.

Rainer




From simon at josefsson.org  Tue May 20 10:31:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 10:31:58 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	(Rainer Gerhards's message of "Tue, 20 May 2008 08:56:10 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
Message-ID: <87prrh8jgh.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> On Mon, May 19, 2008 at 10:53 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
> [snip]
>
>>> In essence, I am looking for something like a callback that is called
>>> during handshake with the remote cert and that can reply with auth
>>> success/failure - all while in the handshaking porcess.
>>>
>>> Does that make any sense?
>>
>> Yes, although I'm not sure it is a good idea to do it as part of the
>> handshake: until the handshake is over, you don't know whether there is
>> a man in the middle attacker present.
>
> I am (obviously;)) not a TLS expert. I thought that when I receive a
> certificate during the handshake, I can validly assume that it
> reflects the remote peer's identity. Could you enlighten me why there
> is a man-in-the-middle attack possible? I would like to get this right
> because I may need to bring it up inside the IETF discussion (and
> obviously I want to be correct then ;)).

Until the TLS handshake has finished, the TLS protocol doesn't protect
against people in the middle.  It is not until the TLS Finished message
(which marks the end of the TLS handshake) that you can tell whether the
other end holds the private key corresponding to the certificate.

>>I suggest completing the
>> handshake as normal, and then compare fingerprints.  If fingerprint
>> comparisons fails, shut down the TLS session.
>
> Actually, this is what I am currently doing. BUT... the syslog story
> is even worse ;) Syslog is simplex communication and the syslog TLS
> internet draft in question maps this simplex nature onto a TCP stream
> WITHOUT acknowledgments (except for the TCP ack, of course). While
> this sounds quite strange, there are some good reasons for doing so (I
> do not elaborate, because it would end up at a veeeeery long off-topic
> post).
>
> Of course, there are inherent problems. One is that after the
> handshake completes, the sender  assumes it may send syslog messages.
> When the server then drops the connection, some of these messages are
> lost, but the sender can not detect which ones exactly. This is NOT
> theoretical, I experience that in my lab. It was the reason I asked
> the initial question. If you would like to dig deeper into that
> problem, you can find a good description in a blog post I wrote a
> while ago: http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html
>
> The only solution to this problem is to have the fingerprint
> authentication carried out during the handshake procedure - so that
> the server does NOT need to drop the connection after the handshake
> (at least not for authentication reasons).

I understand.  I think this problem is one reason why the fingerprint
mechanism is considered a hack.

If you verify the fingerprint during the TLS handshake, you open up for
a man in the middle that can cause authentication failures to occur
without that being possible to detect.  Read that again carefully to
understand it -- it does not enable man in the middle attackers to read
any traffic, just that they can simulate a failed fingerprint
authentication.  If this moves forward in the IETF, that should be in
the security considerations.

Another problem this causes is hash agility: how can the protocol to
handle when SHA-1 is publicly broken and one needs to change to another
hash?  OpenPGP has a similar problem with key fingerprints, I think, and
I don't know of any simple solutions.

>> Ideally, I think the IETF draft should discuss some of these details.
>> It is easy to implement ssh-style leap-of-faith authentication
>> incorrectly.
>
> I have also posted a question on the IETF list when exactly the
> fingerprint authentication must happen. In my current understanding
> (which may be wrong), the draft actually specifies it must happen
> during handshake (which, as I said, would be the right thing here). I
> have not yet received a reply. If you are interested, you may follow
> the discussion here in the mailing list archive:
> http://www.ietf.org/mail-archive/web/syslog/current/msg01910.html

Thanks,
Simon




From rgerhards at gmail.com  Tue May 20 11:19:35 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Tue, 20 May 2008 11:19:35 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <87prrh8jgh.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>

On Tue, May 20, 2008 at 10:31 AM, Simon Josefsson <simon at josefsson.org> wrote:

[snip]

>> I am (obviously;)) not a TLS expert. I thought that when I receive a
>> certificate during the handshake, I can validly assume that it
>> reflects the remote peer's identity. Could you enlighten me why there
>> is a man-in-the-middle attack possible? I would like to get this right
>> because I may need to bring it up inside the IETF discussion (and
>> obviously I want to be correct then ;)).
>
> Until the TLS handshake has finished, the TLS protocol doesn't protect
> against people in the middle.  It is not until the TLS Finished message
> (which marks the end of the TLS handshake) that you can tell whether the
> other end holds the private key corresponding to the certificate.

Please bear with me, I am trying to fully understand it ;) Doesn't
that mean that authentication can never happen as part of the TLS
handshake? As you said, as long as I do not know thzat the remote peer
holds the correct private key, I can not trust anything. If that is
known only after the handshake, how can I authenticate the remote end
during the handshake? I have to admit that I was under the impression
that TLS handshake included the authentication. For example, GnuTLS
doc states in section 3.5 (first sentence):

The Handshake protocol is responsible for the ciphersuite negotiation,
the initial key exchange, and the ****authentication of the two
peers****.

Digging further down in the doc, however, the samples seem to do the
actual authentication only after the handshake. What, of course, makes
sense if you can't trust the cert during the handshake. ... but I have
to admit I am puzzled now ;)

>
>>>I suggest completing the
>>> handshake as normal, and then compare fingerprints.  If fingerprint
>>> comparisons fails, shut down the TLS session.
>>
>> Actually, this is what I am currently doing. BUT... the syslog story
>> is even worse ;) Syslog is simplex communication and the syslog TLS
>> internet draft in question maps this simplex nature onto a TCP stream
>> WITHOUT acknowledgments (except for the TCP ack, of course). While
>> this sounds quite strange, there are some good reasons for doing so (I
>> do not elaborate, because it would end up at a veeeeery long off-topic
>> post).
>>
>> Of course, there are inherent problems. One is that after the
>> handshake completes, the sender  assumes it may send syslog messages.
>> When the server then drops the connection, some of these messages are
>> lost, but the sender can not detect which ones exactly. This is NOT
>> theoretical, I experience that in my lab. It was the reason I asked
>> the initial question. If you would like to dig deeper into that
>> problem, you can find a good description in a blog post I wrote a
>> while ago: http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html
>>
>> The only solution to this problem is to have the fingerprint
>> authentication carried out during the handshake procedure - so that
>> the server does NOT need to drop the connection after the handshake
>> (at least not for authentication reasons).
>
> I understand.  I think this problem is one reason why the fingerprint
> mechanism is considered a hack.
>
> If you verify the fingerprint during the TLS handshake, you open up for
> a man in the middle that can cause authentication failures to occur
> without that being possible to detect.  Read that again carefully to
> understand it -- it does not enable man in the middle attackers to read
> any traffic, just that they can simulate a failed fingerprint
> authentication.  If this moves forward in the IETF, that should be in
> the security considerations.

I understood and I will propose to mention it in the security
considerations section.

> Another problem this causes is hash agility: how can the protocol to
> handle when SHA-1 is publicly broken and one needs to change to another
> hash?  OpenPGP has a similar problem with key fingerprints, I think, and
> I don't know of any simple solutions.

This is actually handled: the fingerprint comes along with an
identification of the algorithm that was used the generate the
fingerprint. So it is possible, in a migration period, to support both
weak and strong algos. Applications implementing the draft need to
have capabilities to display the fingerprint. For the time being, my
initial implementation will support just SHA1, but once I have the
initial set done, I'll provision for additional algorithms. Of course,
they require actual implementation once they are defined. But that's a
different story...

Rainer




From simon at josefsson.org  Tue May 20 11:28:32 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 11:28:32 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	(Rainer Gerhards's message of "Tue, 20 May 2008 11:19:35 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
Message-ID: <87hcctqq7z.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> On Tue, May 20, 2008 at 10:31 AM, Simon Josefsson <simon at josefsson.org> wrote:
>
> [snip]
>
>>> I am (obviously;)) not a TLS expert. I thought that when I receive a
>>> certificate during the handshake, I can validly assume that it
>>> reflects the remote peer's identity. Could you enlighten me why there
>>> is a man-in-the-middle attack possible? I would like to get this right
>>> because I may need to bring it up inside the IETF discussion (and
>>> obviously I want to be correct then ;)).
>>
>> Until the TLS handshake has finished, the TLS protocol doesn't protect
>> against people in the middle.  It is not until the TLS Finished message
>> (which marks the end of the TLS handshake) that you can tell whether the
>> other end holds the private key corresponding to the certificate.
>
> Please bear with me, I am trying to fully understand it ;) Doesn't
> that mean that authentication can never happen as part of the TLS
> handshake? As you said, as long as I do not know thzat the remote peer
> holds the correct private key, I can not trust anything. If that is
> known only after the handshake, how can I authenticate the remote end
> during the handshake? I have to admit that I was under the impression
> that TLS handshake included the authentication. For example, GnuTLS
> doc states in section 3.5 (first sentence):
>
> The Handshake protocol is responsible for the ciphersuite negotiation,
> the initial key exchange, and the ****authentication of the two
> peers****.

Heh.  The key to understanding this is that the TLS finish message acts
as the final check to make sure everything agreed on earlier in the
handshake is correct.  So if the finish message arrives and is decrypted
correctly, the authentication has worked fine.  Before that has happened
you only know that it may work out fine, but don't know for sure.  The
TLS handshake includes the TLS finished message, so if that worked fine,
you indeed have authenticated successfully.

> Digging further down in the doc, however, the samples seem to do the
> actual authentication only after the handshake. What, of course, makes
> sense if you can't trust the cert during the handshake. ... but I have
> to admit I am puzzled now ;)

Hm, that sounds strange.  Which example?  GnuTLS should verify the
certificate during the handshake (the CA is set before starting the
handshake), but the examples may be printing the data in the
certificates after the handshake.

>> I understand.  I think this problem is one reason why the fingerprint
>> mechanism is considered a hack.
>>
>> If you verify the fingerprint during the TLS handshake, you open up for
>> a man in the middle that can cause authentication failures to occur
>> without that being possible to detect.  Read that again carefully to
>> understand it -- it does not enable man in the middle attackers to read
>> any traffic, just that they can simulate a failed fingerprint
>> authentication.  If this moves forward in the IETF, that should be in
>> the security considerations.
>
> I understood and I will propose to mention it in the security
> considerations section.

I believe that would be a good idea.

>> Another problem this causes is hash agility: how can the protocol to
>> handle when SHA-1 is publicly broken and one needs to change to another
>> hash?  OpenPGP has a similar problem with key fingerprints, I think, and
>> I don't know of any simple solutions.
>
> This is actually handled: the fingerprint comes along with an
> identification of the algorithm that was used the generate the
> fingerprint. So it is possible, in a migration period, to support both
> weak and strong algos. Applications implementing the draft need to
> have capabilities to display the fingerprint. For the time being, my
> initial implementation will support just SHA1, but once I have the
> initial set done, I'll provision for additional algorithms. Of course,
> they require actual implementation once they are defined. But that's a
> different story...

Ok, that is as good as it is going to get with the fingerprint approach,
I think.

/Simon




From rgerhards at gmail.com  Tue May 20 12:09:02 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Tue, 20 May 2008 12:09:02 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <87hcctqq7z.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>

On Tue, May 20, 2008 at 11:28 AM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>> On Tue, May 20, 2008 at 10:31 AM, Simon Josefsson <simon at josefsson.org> wrote:
>>
>> [snip]
>>
>>>> I am (obviously;)) not a TLS expert. I thought that when I receive a
>>>> certificate during the handshake, I can validly assume that it
>>>> reflects the remote peer's identity. Could you enlighten me why there
>>>> is a man-in-the-middle attack possible? I would like to get this right
>>>> because I may need to bring it up inside the IETF discussion (and
>>>> obviously I want to be correct then ;)).
>>>
>>> Until the TLS handshake has finished, the TLS protocol doesn't protect
>>> against people in the middle.  It is not until the TLS Finished message
>>> (which marks the end of the TLS handshake) that you can tell whether the
>>> other end holds the private key corresponding to the certificate.
>>
>> Please bear with me, I am trying to fully understand it ;) Doesn't
>> that mean that authentication can never happen as part of the TLS
>> handshake? As you said, as long as I do not know thzat the remote peer
>> holds the correct private key, I can not trust anything. If that is
>> known only after the handshake, how can I authenticate the remote end
>> during the handshake? I have to admit that I was under the impression
>> that TLS handshake included the authentication. For example, GnuTLS
>> doc states in section 3.5 (first sentence):
>>
>> The Handshake protocol is responsible for the ciphersuite negotiation,
>> the initial key exchange, and the ****authentication of the two
>> peers****.
>
> Heh.  The key to understanding this is that the TLS finish message acts
> as the final check to make sure everything agreed on earlier in the
> handshake is correct.  So if the finish message arrives and is decrypted
> correctly, the authentication has worked fine.  Before that has happened
> you only know that it may work out fine, but don't know for sure.  The
> TLS handshake includes the TLS finished message, so if that worked fine,
> you indeed have authenticated successfully.

Thanks for your persistence. I think I at least begin to understand (I
am also reading RFC 4346 in parallel, but that's a lot to grasp at
once ;)). Let me sum up to see if I got it right:

I may check the remote peer's identity during the handshake, but it is
not guaranteed that the identity presented is the real identity. The
threat is that a man-in-the-middle may pretend to be someone else and
I may base a decision on this wrong identity. If I permit access, that
is not a problem, because the MITM would not be able to decrypt
(provided cert's pub key is used by me and the original entities
private key is not breached). However, the MITM may try to force me to
use lower security by providing a wrong identity. However, that would
result in no message flow at all in the syslog scenario. So the worst
case would be a denial of service, which could be created even without
authentication if the MITM simply steals the port and does not accept
connections.

I still would see a lot of benefit in being able to check the remote
peers identity BEFORE the Finished message is sent. That way, I could
block access to not permitted peers at the risk of the DoS outlined
above. Am I still overlooking something?

>> Digging further down in the doc, however, the samples seem to do the
>> actual authentication only after the handshake. What, of course, makes
>> sense if you can't trust the cert during the handshake. ... but I have
>> to admit I am puzzled now ;)
>
> Hm, that sounds strange.  Which example?

For example the example in section 7.3.4:

------
7.3.4 Verifying Peer's Certificate

A TLS session is not secure just after the handshake procedure has
finished. It must be considered secure, only after the peer's
certificate and identity have been verified. That is, you have to
verify the signature in peer's certificate, the hostname in the
certificate, and expiration dates. Just after this step you should
treat the connection as being a secure one.
------

>  GnuTLS should verify the
> certificate during the handshake (the CA is set before starting the
> handshake), but the examples may be printing the data in the
> certificates after the handshake.

Does it really *verify* the certificate or validate it in regard to
cert chain, expiration date etc?

[snip]

Rainer




From simon at josefsson.org  Tue May 20 12:51:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 12:51:41 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	(Rainer Gerhards's message of "Tue, 20 May 2008 12:09:02 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<878wy611v6.fsf@mocca.josefsson.org>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
Message-ID: <87skwdjlj6.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Thanks for your persistence. I think I at least begin to understand (I
> am also reading RFC 4346 in parallel, but that's a lot to grasp at
> once ;)). Let me sum up to see if I got it right:
>
> I may check the remote peer's identity during the handshake, but it is
> not guaranteed that the identity presented is the real identity. The
> threat is that a man-in-the-middle may pretend to be someone else and
> I may base a decision on this wrong identity. If I permit access, that
> is not a problem, because the MITM would not be able to decrypt
> (provided cert's pub key is used by me and the original entities
> private key is not breached). However, the MITM may try to force me to
> use lower security by providing a wrong identity. However, that would
> result in no message flow at all in the syslog scenario. So the worst
> case would be a denial of service, which could be created even without
> authentication if the MITM simply steals the port and does not accept
> connections.
>
> I still would see a lot of benefit in being able to check the remote
> peers identity BEFORE the Finished message is sent. That way, I could
> block access to not permitted peers at the risk of the DoS outlined
> above. Am I still overlooking something?

No, I think that is correct.  Nikos, any thoughts?  You added some
callbacks during the handshake earlier, are any of those useful here?

>>> Digging further down in the doc, however, the samples seem to do the
>>> actual authentication only after the handshake. What, of course, makes
>>> sense if you can't trust the cert during the handshake. ... but I have
>>> to admit I am puzzled now ;)
>>
>> Hm, that sounds strange.  Which example?
>
> For example the example in section 7.3.4:
>
> ------
> 7.3.4 Verifying Peer's Certificate
>
> A TLS session is not secure just after the handshake procedure has
> finished. It must be considered secure, only after the peer's
> certificate and identity have been verified. That is, you have to
> verify the signature in peer's certificate, the hostname in the
> certificate, and expiration dates. Just after this step you should
> treat the connection as being a secure one.
> ------

Ah, ok, what gnutls does in the handshake is the first step of the
authentication -- so that you know that the other end is the certificate
owner.  The rest above is mostly about authorization decisions.

>>  GnuTLS should verify the
>> certificate during the handshake (the CA is set before starting the
>> handshake), but the examples may be printing the data in the
>> certificates after the handshake.
>
> Does it really *verify* the certificate or validate it in regard to
> cert chain, expiration date etc?

No, that are authorization decisions that you need to do manually.  The
TLS handshake doesn't care whether the provided certificate is
untrusted.

/Simon




From simon at josefsson.org  Tue May 20 15:42:55 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 15:42:55 +0200
Subject: [Help-gnutls] Re: trac.gnutls.org
In-Reply-To: <87bq4kw5i8.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 08 Apr 2008 14:44:47 -0400")
References: <87fxu5dlkj.fsf@squeak.fifthhorseman.net>
	<87od8slggm.fsf@mocca.josefsson.org>
	<87fxu4yxiy.fsf@squeak.fifthhorseman.net>
	<87wsnf9q4l.fsf_-_@mocca.josefsson.org>
	<87bq4kw5i8.fsf@squeak.fifthhorseman.net>
Message-ID: <874p8t2isg.fsf@mocca.josefsson.org>

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

> On Thu 2008-04-03 06:42:02 -0400, Simon Josefsson wrote:
>
>> We definitely could use help with trac.gnutls.org.  Btw, do you know
>> a good way to deal with trac-spam?  Right now I remove it manually
>> when I noticed it but that doesn't scale well, and I'm pretty sure I
>> fail to catch some spam.
>
> Sigh.  Spammers suck.

Indeed, and now they have found trac.gnutls.org big time.  Sigh.  Would
you (or anyone else on this list) have time to help administrate a trac
installation?  Can anyone sponsor a xen instance to host this?

Or if we can collect funds to buy a commercial VPS.  I can get a fixed
IP debian 128MB/5GB instance with 50GB/month network from glesys.se for
79 SEK (around 9 EUR or 14 USD).  I have good experience with them.
Anyone knows of better deals with good uptime etc?

> smtp_always_cc = gnutls-devel at gnu.org

Thanks for configuration hints...

>> Do you know a trac hosting site, so that someone else takes care of
>> the low-level trac administration?  I'd ideally want to find someone
>> else to host or co-maintain trac.gnutls.org because it steals my
>> time from more important things.  The reason we aren't using
>> savannah for everything is that I need a gnutls-related wiki.
>> Savannah doesn't have roadmap or timeline pages either, as far as I
>> understand.  And I kind of like the simplicity of the trac
>> interface.
>
> Understood.  The trac interface is one of the cleaner ones out there.
>
> I collaborate with May First/People Link [2], which is a membership
> organization that assists its members with internet work.  There has
> been some discussion at MF/PL recently about making it simpler to
> support members' use of trac [3].  If gnutls.org was a member of
> MF/PL, it could get the support of that organization, which at the
> moment includes trac 0.11b1, fwict.
>
> Alternately, i can take a look at your current trac setup -- i can't
> promise to offer long-term support right now, but it looks like an
> environment i'm comfortable with, if my snooping is correct: it's
> hosted on kniv, which appears (from the ssh greeting string and the
> Server: HTTP response headers) to be running debian etch.  If you'd
> like me to poke around and see what makes sense, please let me know.
>
> Perhaps most simply, if you want me to help monitor trac.gnutls.org
> for spam, i'd just need a trac login with privileges to be able to
> delete suspect comments or revert wiki edits.  I dunno how yer giving
> those out, but i figure since i'm following the RSS feed anyway, i
> could make myself useful if you want me to.

Thanks for your offer!  Right now kniv runs some unrelated stuff that I
don't want to expose, so the first step would be to find a better host
for this where we can give people accounts.

/Simon




From simon at josefsson.org  Tue May 20 15:45:11 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 15:45:11 +0200
Subject: [Help-gnutls] Re: Setting OpenPGP private key MPI components
In-Reply-To: <873apww3il.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 08 Apr 2008 15:27:46 -0400")
References: <873apww3il.fsf@squeak.fifthhorseman.net>
Message-ID: <87zlql1448.fsf@mocca.josefsson.org>

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

> Hey folks--
>
> I opened a ticket about being able to explicitly set the MPI
> components of an OpenPGP private key:
>
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/24
>
> This would be really useful for me (and a step toward OpenPGP key
> generation in GnuTLS, if that's desired), and i was wondering what
> might be needed to get this functionality added.
>
> I've done a brief review of the source of gnutls and opencdk to see if
> there was an obvious way to add the function.  But either i don't
> understand the libraries well enough (quite possible!) or there are
> enough architectural pieces missing to make the solution non-obvious
> to me.
>
> Any thoughts about if this is something that seems possible in the
> current framework?  I'm happy to take a crack at adding a function
> named something like gnutls_openpgp_privkey_import_rsa_raw() (and
> offering a patch for review) if one of the more experienced developers
> thinks it's both desirable and possible, and is up for pointing me in
> the right direction.

Thanks for submitting the ticket, I agree it would be useful
functionality.  My TLS OpenPGP fu is weak so I think you know more about
it than me..  hopefully Nikos will have time to answer.

/Simon




From simon at josefsson.org  Tue May 20 15:46:21 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 15:46:21 +0200
Subject: [Help-gnutls] Re: segfaults using certtool --pgp-certificate-info
In-Reply-To: <87ej9fc1rc.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 08 Apr 2008 20:25:59 -0400")
References: <87ej9fc1rc.fsf@squeak.fifthhorseman.net>
Message-ID: <87ve19142a.fsf@mocca.josefsson.org>

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

> Hey GnuTLS people--
>
> I've opened two tickets about segfaults when using certtool with the
> --pgp-certificate-info flag:
>
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/26
>  http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/27
>
> Just wanted to give a heads-up.
>
> Thanks for all your work on this project,

Seems to have been fixed, thanks for head-ups to the list.

/Simon




From rgerhards at gmail.com  Tue May 20 18:24:31 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Tue, 20 May 2008 18:24:31 +0200
Subject: [Help-gnutls] client certificate not provided when no common root ca
Message-ID: <dc67eef70805200924k33f3d45doc180d925d609df03@mail.gmail.com>

Hi list,

me again ;) I have a server and client, both with self-signed
certificates and no common root CA. My server requests the client's
certificate. However, it does not receive one when there is no common
root CA. If I add a common root CA to both client and server (but
still have self-signed certs NOT signed by the common CA), I receive
the client certificate.

Is this desired behavior (I think I read it is, but can no longer find
the doc page where it is described). If so, is there any way around it
(e.g. via the certificate retrieve functions)?

Feedback is appreciated.

Thanks,
Rainer




From rgerhards at gmail.com  Wed May 21 11:58:32 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Wed, 21 May 2008 11:58:32 +0200
Subject: [Help-gnutls] adding trusted CAs
Message-ID: <dc67eef70805210258n5f0e5c1v63c51a10b383b25d@mail.gmail.com>

Hi all,

this is probably an exceptionally dumb question, but... ;)

I would like to ship a number of trusted roots with the default
rsyslog install - much like web browsers do. The idea is that I would
like to be able to automatically verify certificates that have been
obtained by one of those well-known CA.

Question now: how do I do that? Do I simply add the certificate blocks
into a single big .pem file? Or do I need to supply multiple files.

Also (the probably really dumb one ;)): how do I obtain these
certificates? Ask the CAs? Or export them from the browser (I've not
found this option in Firefox).

Advise is appreciated.

Rainer




From nmav at gnutls.org  Wed May 21 13:35:33 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 May 2008 14:35:33 +0300
Subject: [Help-gnutls] client certificate not provided when no common
	root ca
In-Reply-To: <dc67eef70805200924k33f3d45doc180d925d609df03@mail.gmail.com>
References: <dc67eef70805200924k33f3d45doc180d925d609df03@mail.gmail.com>
Message-ID: <48340905.2030901@gnutls.org>

Rainer Gerhards wrote:
> Hi list,
> 
> me again ;) I have a server and client, both with self-signed
> certificates and no common root CA. My server requests the client's
> certificate. However, it does not receive one when there is no common
> root CA. If I add a common root CA to both client and server (but
> still have self-signed certs NOT signed by the common CA), I receive
> the client certificate.
> Is this desired behavior (I think I read it is, but can no longer find
> the doc page where it is described). 

Yes this is the desired behavior. That is because the server requests
certificates only from the CAs he trusts.

> If so, is there any way around it
> (e.g. via the certificate retrieve functions)?

1. Include the client CA certificate into  the server trusted CA list

2. (hack)
You should use the callback functions in client so that you can send any
certificate that you like regardless of what the server requests (check
gnutls-cli code).

regards,
Nikos




From nmav at gnutls.org  Wed May 21 13:37:39 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 May 2008 14:37:39 +0300
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <87skwdjlj6.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>	<878wy611v6.fsf@mocca.josefsson.org>	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>	<87wslqyq0z.fsf@mocca.josefsson.org>	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>	<87prrh8jgh.fsf@mocca.josefsson.org>	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>	<87hcctqq7z.fsf@mocca.josefsson.org>	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org>
Message-ID: <48340983.5070500@gnutls.org>

Simon Josefsson wrote:

>> I still would see a lot of benefit in being able to check the remote
>> peers identity BEFORE the Finished message is sent. That way, I could
>> block access to not permitted peers at the risk of the DoS outlined
>> above. Am I still overlooking something?
> 
> No, I think that is correct.  Nikos, any thoughts?  You added some
> callbacks during the handshake earlier, are any of those useful here?

No unfortunately not. The callbacks I added are called after client
hello is received. The callbacks you discuss need to be called after the
certificate message is received.

regards,
Nikos




From rgerhards at gmail.com  Wed May 21 13:42:14 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Wed, 21 May 2008 13:42:14 +0200
Subject: [Help-gnutls] client certificate not provided when no common root
	ca
In-Reply-To: <48340905.2030901@gnutls.org>
References: <dc67eef70805200924k33f3d45doc180d925d609df03@mail.gmail.com>
	<48340905.2030901@gnutls.org>
Message-ID: <dc67eef70805210442h5482598fp8aaf1d1aae68498a@mail.gmail.com>

Hi Nikos,

inline...

On Wed, May 21, 2008 at 1:35 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> Rainer Gerhards wrote:
>> Hi list,
>>
>> me again ;) I have a server and client, both with self-signed
>> certificates and no common root CA. My server requests the client's
>> certificate. However, it does not receive one when there is no common
>> root CA. If I add a common root CA to both client and server (but
>> still have self-signed certs NOT signed by the common CA), I receive
>> the client certificate.
>> Is this desired behavior (I think I read it is, but can no longer find
>> the doc page where it is described).
>
> Yes this is the desired behavior. That is because the server requests
> certificates only from the CAs he trusts.

That makes an awful lot of sense ;)

>
>> If so, is there any way around it
>> (e.g. via the certificate retrieve functions)?
>
> 1. Include the client CA certificate into  the server trusted CA list
>
> 2. (hack)
> You should use the callback functions in client so that you can send any
> certificate that you like regardless of what the server requests (check
> gnutls-cli code).

I'll go for 2, as I need to support self-signed certs (again, the
fingerprint issue).

Thanks again for your help,
Rainer




From rgerhards at gmail.com  Wed May 21 13:44:19 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Wed, 21 May 2008 13:44:19 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <483402CA.9020601@gmail.com>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>
	<87wslqyq0z.fsf@mocca.josefsson.org>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
Message-ID: <dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>

Hi Nikos,

On Wed, May 21, 2008 at 1:08 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> Simon Josefsson wrote:
>
>>> I still would see a lot of benefit in being able to check the remote
>>> peers identity BEFORE the Finished message is sent. That way, I could
>>> block access to not permitted peers at the risk of the DoS outlined
>>> above. Am I still overlooking something?
>>
>> No, I think that is correct.  Nikos, any thoughts?  You added some
>> callbacks during the handshake earlier, are any of those useful here?
>
> No unfortunately not. The callbacks I added are called after client
> hello is received. The callbacks you discuss need to be called after the
> certificate message is received.

Could you point me to the file where processing the certificate
message is done? I would be interested to see if I could add a
callback, and may it even just be to know how it is done ;)

Thanks,
Rainer




From nmav at gnutls.org  Wed May 21 13:53:13 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 21 May 2008 14:53:13 +0300
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>	
	<dc67eef70805191338h18ff664sc724353dc0a9c0db@mail.gmail.com>	
	<87wslqyq0z.fsf@mocca.josefsson.org>	
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>	
	<87prrh8jgh.fsf@mocca.josefsson.org>	
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>	
	<87hcctqq7z.fsf@mocca.josefsson.org>	
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>	
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
Message-ID: <48340D29.2050708@gnutls.org>

Rainer Gerhards wrote:
> Hi Nikos,
> 
> On Wed, May 21, 2008 at 1:08 PM, Nikos Mavrogiannopoulos
> <n.mavrogiannopoulos at gmail.com> wrote:
>> Simon Josefsson wrote:
>>
>>>> I still would see a lot of benefit in being able to check the remote
>>>> peers identity BEFORE the Finished message is sent. That way, I could
>>>> block access to not permitted peers at the risk of the DoS outlined
>>>> above. Am I still overlooking something?
>>> No, I think that is correct.  Nikos, any thoughts?  You added some
>>> callbacks during the handshake earlier, are any of those useful here?
>> No unfortunately not. The callbacks I added are called after client
>> hello is received. The callbacks you discuss need to be called after the
>> certificate message is received.
> 
> Could you point me to the file where processing the certificate
> message is done? I would be interested to see if I could add a
> callback, and may it even just be to know how it is done ;)

The file is gnutls_handshake.c. The functions you're interested in are
_gnutls_handshake_client, _gnutls_handshake_server (if you're doing it
for both of them).

A similar callback is _gnutls_user_hello_func which is the post_hello
callback.

I'd glad to review and commit and patches for this issue.

regards,
Nikos




From rgerhards at gmail.com  Mon May 26 14:16:33 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 26 May 2008 14:16:33 +0200
Subject: [Help-gnutls] gnutls_certificate_get_peers() and expired certs
Message-ID: <dc67eef70805260516v55d46468y167e56edcc7c4dd4@mail.gmail.com>

Hi list,

I have used  gnutls_certificate_get_peers() with expired certificates.
The validation check returned successfully. From the documentation it
looks like this is expected behavior and I always must check this
manually. Please let me know if my assumption is correct (I would like
to implement in the best possible way and not use customer code where
I can rely on the library itself).

Thanks,
Rainer




From simon at josefsson.org  Mon May 26 14:27:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 14:27:07 +0200
Subject: [Help-gnutls] Re: gnutls_certificate_get_peers() and expired certs
In-Reply-To: <dc67eef70805260516v55d46468y167e56edcc7c4dd4@mail.gmail.com>
	(Rainer Gerhards's message of "Mon, 26 May 2008 14:16:33 +0200")
References: <dc67eef70805260516v55d46468y167e56edcc7c4dd4@mail.gmail.com>
Message-ID: <87prr9tfms.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi list,
>
> I have used  gnutls_certificate_get_peers() with expired certificates.
> The validation check returned successfully. From the documentation it
> looks like this is expected behavior and I always must check this
> manually. Please let me know if my assumption is correct (I would like
> to implement in the best possible way and not use customer code where
> I can rely on the library itself).

Hi, yes, you need to check expiration dates yourself.  See the examples
on how to do this:

http://www.gnu.org/software/gnutls/manual/html_node/Verifying-peer_0027s-certificate.html

/Simon




From rgerhards at gmail.com  Mon May 26 18:42:39 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 26 May 2008 18:42:39 +0200
Subject: [Help-gnutls] gnutls_certificate_client_set_retrieve_function() and
	application "cookies"
Message-ID: <dc67eef70805260942g77c13703y98c4a7ec7e4b6a23@mail.gmail.com>

Hi,

me again ;) I have (potentially) different certificate stores for
different sessions. I do not (yet) have a readily accessible list of
session identifiers. Is there any way to pass a void* pointer to
GnuTLS that will be passed back to me when the callback is called? I
see that there is no direct way to do it, but can I store this pointer
e.g. somehow inside the GnuTLS session data structure?

If I am not able to do that, I need to go long (and inefficient!) ways
to look up my session information based on the GnuTLS session handle I
receive. I hope I can avoid this.

Feedback is deeply appreciated.

Thanks,
Rainer




From rgerhards at gmail.com  Mon May 26 22:39:03 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Mon, 26 May 2008 22:39:03 +0200
Subject: [Help-gnutls] gnutls_certificate_client_set_retrieve_function()
	and application "cookies"
In-Reply-To: <c331d99a0805261327g623ac780pa5f8978426a64822@mail.gmail.com>
References: <dc67eef70805260942g77c13703y98c4a7ec7e4b6a23@mail.gmail.com>
	<c331d99a0805261327g623ac780pa5f8978426a64822@mail.gmail.com>
Message-ID: <dc67eef70805261339g4770f46fwe2397b8c10ffd6ff@mail.gmail.com>

excellent, many thanks. This was exactly what I was looking for. It
looks like I can finally finish the initial full implementation of the
most recent syslog tls Internet draft.

Thanks a lot again for all your help.

Rainer
On Mon, May 26, 2008 at 10:27 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> Check gnutls_session_set_ptr() and gnutls_session_get_ptr().
>
> On Mon, May 26, 2008 at 7:42 PM, Rainer Gerhards <rgerhards at gmail.com> wrote:
>> Hi,
>>
>> me again ;) I have (potentially) different certificate stores for
>> different sessions. I do not (yet) have a readily accessible list of
>> session identifiers. Is there any way to pass a void* pointer to
>> GnuTLS that will be passed back to me when the callback is called? I
>> see that there is no direct way to do it, but can I store this pointer
>> e.g. somehow inside the GnuTLS session data structure?
>>
>> If I am not able to do that, I need to go long (and inefficient!) ways
>> to look up my session information based on the GnuTLS session handle I
>> receive. I hope I can avoid this.
>>
>> Feedback is deeply appreciated.
>>
>> Thanks,
>> Rainer
>>
>>
>> _______________________________________________
>> Help-gnutls mailing list
>> Help-gnutls at gnu.org
>> http://lists.gnu.org/mailman/listinfo/help-gnutls
>>
>




From rgerhards at gmail.com  Wed May 28 10:13:39 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Wed, 28 May 2008 10:13:39 +0200
Subject: [Help-gnutls] [OT] a big thanks - GnuTLS now driving world's first
	syslog-transport-tls implementation
Message-ID: <dc67eef70805280113m9aa132eheb1892a504916240@mail.gmail.com>

Hi folks,

I would like to say a big thank you! Thanks to your excellent help
(and well-designed API), I have been able to complete the world's
first implementation of ietf-syslog-transport-tls-12. There is one
thing dangling, and that is the callback I would like to have for
certificate validation during the handshake. However, I will look into
providing a patch if that turns out to become a real problem.

Please note that I have chosen GnuTLS over NSS because of its much
better documentation (at least for non-Netscape stand alone projects).
What I did not know at the time I made the decision was the ultra-fast
speed with which you provided support on the mailing list. This is an
even better feature :)

I know all of this is quite off-topic, but I thought it should still be said ;)

If you are interested, you may have a look at my implementation report:

http://blog.gerhards.net/2008/05/syslog-transport-tls-12-implementation.html

Keep up the good work :)
Rainer




From simon at josefsson.org  Wed May 28 18:43:33 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 May 2008 18:43:33 +0200
Subject: [Help-gnutls] Re: [OT] a big thanks - GnuTLS now driving world's
	first syslog-transport-tls implementation
In-Reply-To: <dc67eef70805280113m9aa132eheb1892a504916240@mail.gmail.com>
	(Rainer Gerhards's message of "Wed, 28 May 2008 10:13:39 +0200")
References: <dc67eef70805280113m9aa132eheb1892a504916240@mail.gmail.com>
Message-ID: <87hcci2xca.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Hi folks,
>
> I would like to say a big thank you! Thanks to your excellent help
> (and well-designed API), I have been able to complete the world's
> first implementation of ietf-syslog-transport-tls-12.

Cool!  I've added a link to rsyslog at:

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

> There is one thing dangling, and that is the callback I would like to
> have for certificate validation during the handshake. However, I will
> look into providing a patch if that turns out to become a real
> problem.

Thanks.  If other protocols turn out to use leap-of-faith
fingerprint-validation in the TLS handshake, we should provide a
callback for this.  However, there are some tricky issues here, and I'd
like to see this vetted by the IETF process somewhat more.  If nobody
believes that using TLS in this way is problematic, I guess we should
support that mode.

> Please note that I have chosen GnuTLS over NSS because of its much
> better documentation (at least for non-Netscape stand alone projects).
> What I did not know at the time I made the decision was the ultra-fast
> speed with which you provided support on the mailing list. This is an
> even better feature :)

Heh. :)

Btw, NSS is not widely ported to various embedded platforms (e.g.,
openwrt), and rsyslog with the TLS transport seems rather appropriate to
use on such devices.

> I know all of this is quite off-topic, but I thought it should still
> be said ;)

Thanks for your kind words, it helps when I need to find motivation for
continuing.

> If you are interested, you may have a look at my implementation report:
>
> http://blog.gerhards.net/2008/05/syslog-transport-tls-12-implementation.html

Interesting.

Thanks,
Simon




From marlam at marlam.de  Wed May 28 22:01:03 2008
From: marlam at marlam.de (Martin Lambers)
Date: Wed, 28 May 2008 22:01:03 +0200
Subject: [Help-gnutls] How to check if a certificate is revoked
Message-ID: <20080528200103.GA32595@wile.lambers.home>

Hi all,

how do I check if a certificate is revoked?

I created a test CA, signed a certificate, revoked it, and created a CRL
file with this information.

Then I use gnutls_certificate_set_x509_crl_file() in the client program 
to set the CRL file. The function returns 1, as expected.
After calling gnutls_certificate_verify_peers2(), I check if the status
contains GNUTLS_CERT_REVOKED, but this is not the case.

Neither openssl s_client nor gnutls-cli seem to support CRL files, so I
was not able to double check that my test setup is correct.

Martin




From alex at samad.com.au  Thu May 29 06:35:15 2008
From: alex at samad.com.au (Alex Samad)
Date: Thu, 29 May 2008 14:35:15 +1000
Subject: [Help-gnutls] Encrypted private keys
Message-ID: <001201c8c145$655bfa50$fd08a8c0@asiapacific.hpqcorp.net>

Hi

I am a debian user and use gnutls library indirectly, previously I used
openssl, but debian has made a move over to gnutls.

Previously with openssl I had setup ldapsearch to use x509 certs to identify
myself, I encrypted my private certs with a password. Since the move to
gnutls I have been unable to use encrypted private keys.

I thought maybe it was a config difference between gnutls and openssl, but
with all the reading I have done of certtool documentation I can't find any
place to setup a encrypted private key.

I have raised a bug report against the maintainers of ldap-utils, this is
the package that has ldapsearch ( and other ldap-commands), but they are a
bit low on resources now.

So I thought I would come to the list and find out 

1) is it true that the libraries can't handle encrypted private keys
2) If not how do you handle encrypted private keys
3) if it is true, what do other users do to protect their private keys ?

Thanks
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080529/1d1ba13d/attachment.htm>

From simon at josefsson.org  Thu May 29 15:58:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 May 2008 15:58:50 +0200
Subject: [Help-gnutls] Re: Encrypted private keys
In-Reply-To: <001201c8c145$655bfa50$fd08a8c0@asiapacific.hpqcorp.net> (Alex
	Samad's message of "Thu, 29 May 2008 14:35:15 +1000")
References: <001201c8c145$655bfa50$fd08a8c0@asiapacific.hpqcorp.net>
Message-ID: <877iddb49x.fsf@mocca.josefsson.org>

"Alex Samad" <alex at samad.com.au> writes:

> Hi
>
> I am a debian user and use gnutls library indirectly, previously I used
> openssl, but debian has made a move over to gnutls.
>
> Previously with openssl I had setup ldapsearch to use x509 certs to identify
> myself, I encrypted my private certs with a password. Since the move to
> gnutls I have been unable to use encrypted private keys.
>
> I thought maybe it was a config difference between gnutls and openssl, but
> with all the reading I have done of certtool documentation I can't find any
> place to setup a encrypted private key.
>
> I have raised a bug report against the maintainers of ldap-utils, this is
> the package that has ldapsearch ( and other ldap-commands), but they are a
> bit low on resources now.
>
> So I thought I would come to the list and find out 
>
> 1) is it true that the libraries can't handle encrypted private keys

No.

> 2) If not how do you handle encrypted private keys

You can load PKCS#8 protected keys using:

gnutls_x509_privkey_import_pkcs8.

And encrypted keys stored in PKCS#12 using:

gnutls_certificate_set_x509_simple_pkcs12_file

These are the two standard ways to encrypt private keys that I know of.
OpenSSL has a proprietary standard that we don't support.

/Simon




From alex at samad.com.au  Fri May 30 02:50:12 2008
From: alex at samad.com.au (Alex Samad)
Date: Fri, 30 May 2008 10:50:12 +1000
Subject: [Help-gnutls] Re: Encrypted private keys
In-Reply-To: <877iddb49x.fsf@mocca.josefsson.org>
References: <001201c8c145$655bfa50$fd08a8c0@asiapacific.hpqcorp.net>
	<877iddb49x.fsf@mocca.josefsson.org>
Message-ID: <20080530005012.GD29734@samad.com.au>

On Thu, May 29, 2008 at 03:58:50PM +0200, Simon Josefsson wrote:
> "Alex Samad" <alex at samad.com.au> writes:
> 
> > Hi
> >
> > I am a debian user and use gnutls library indirectly, previously I used
> > openssl, but debian has made a move over to gnutls.
> >
> > Previously with openssl I had setup ldapsearch to use x509 certs to identify
> > myself, I encrypted my private certs with a password. Since the move to
> > gnutls I have been unable to use encrypted private keys.
> >
> > I thought maybe it was a config difference between gnutls and openssl, but
> > with all the reading I have done of certtool documentation I can't find any
> > place to setup a encrypted private key.
> >
> > I have raised a bug report against the maintainers of ldap-utils, this is
> > the package that has ldapsearch ( and other ldap-commands), but they are a
> > bit low on resources now.
> >
> > So I thought I would come to the list and find out 
> >
> > 1) is it true that the libraries can't handle encrypted private keys
> 
> No.
> 
> > 2) If not how do you handle encrypted private keys
> 
> You can load PKCS#8 protected keys using:
> 
> gnutls_x509_privkey_import_pkcs8.
> 
> And encrypted keys stored in PKCS#12 using:
> 
> gnutls_certificate_set_x509_simple_pkcs12_file
> 
> These are the two standard ways to encrypt private keys that I know of.
> OpenSSL has a proprietary standard that we don't support.

This is the important bit of information I need, I had presumed their
encrypted pem (?!) was a standard, so I should be able to use password
protected pkcs12.

Sorry I am end user of an application not the writer, I will check this
out.

Thanks

> 
> /Simon
> 

-- 
"There's no question that the minute I got elected, the storm clouds on the horizon were getting nearly directly overhead."

	- George W. Bush
05/11/2001
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20080530/0d60d11f/attachment.pgp>

From rgerhards at gmail.com  Fri May 30 08:20:31 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 30 May 2008 08:20:31 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <48340D29.2050708@gnutls.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
Message-ID: <dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>

Just double-checking:

As far as I have seen openSSL's SSL_CTX_set_cert_verify_callback() is
not implemented inside the compatibility layer? I am asking because of

http://www.ietf.org/mail-archive/web/syslog/current/msg01963.html

Thanks,
Rainer

On Wed, May 21, 2008 at 1:53 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> Rainer Gerhards wrote:
>> Hi Nikos,
>>
>> On Wed, May 21, 2008 at 1:08 PM, Nikos Mavrogiannopoulos
>> <n.mavrogiannopoulos at gmail.com> wrote:
>>> Simon Josefsson wrote:
>>>
>>>>> I still would see a lot of benefit in being able to check the remote
>>>>> peers identity BEFORE the Finished message is sent. That way, I could
>>>>> block access to not permitted peers at the risk of the DoS outlined
>>>>> above. Am I still overlooking something?
>>>> No, I think that is correct.  Nikos, any thoughts?  You added some
>>>> callbacks during the handshake earlier, are any of those useful here?
>>> No unfortunately not. The callbacks I added are called after client
>>> hello is received. The callbacks you discuss need to be called after the
>>> certificate message is received.
>>
>> Could you point me to the file where processing the certificate
>> message is done? I would be interested to see if I could add a
>> callback, and may it even just be to know how it is done ;)
>
> The file is gnutls_handshake.c. The functions you're interested in are
> _gnutls_handshake_client, _gnutls_handshake_server (if you're doing it
> for both of them).
>
> A similar callback is _gnutls_user_hello_func which is the post_hello
> callback.
>
> I'd glad to review and commit and patches for this issue.
>
> regards,
> Nikos
>




From simon at josefsson.org  Fri May 30 11:34:28 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 May 2008 11:34:28 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 30 May 2008 08:20:31 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805192356q63d7e0e0u684f7d6339309dda@mail.gmail.com>
	<87prrh8jgh.fsf@mocca.josefsson.org>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
Message-ID: <877idc3zkr.fsf@mocca.josefsson.org>

No, that is not implemented.  By reading the documentation for this, I
think GnuTLS should provide a similar callback.  Patches welcome. :)

/Simon

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Just double-checking:
>
> As far as I have seen openSSL's SSL_CTX_set_cert_verify_callback() is
> not implemented inside the compatibility layer? I am asking because of
>
> http://www.ietf.org/mail-archive/web/syslog/current/msg01963.html
>
> Thanks,
> Rainer
>
> On Wed, May 21, 2008 at 1:53 PM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> Rainer Gerhards wrote:
>>> Hi Nikos,
>>>
>>> On Wed, May 21, 2008 at 1:08 PM, Nikos Mavrogiannopoulos
>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>> Simon Josefsson wrote:
>>>>
>>>>>> I still would see a lot of benefit in being able to check the remote
>>>>>> peers identity BEFORE the Finished message is sent. That way, I could
>>>>>> block access to not permitted peers at the risk of the DoS outlined
>>>>>> above. Am I still overlooking something?
>>>>> No, I think that is correct.  Nikos, any thoughts?  You added some
>>>>> callbacks during the handshake earlier, are any of those useful here?
>>>> No unfortunately not. The callbacks I added are called after client
>>>> hello is received. The callbacks you discuss need to be called after the
>>>> certificate message is received.
>>>
>>> Could you point me to the file where processing the certificate
>>> message is done? I would be interested to see if I could add a
>>> callback, and may it even just be to know how it is done ;)
>>
>> The file is gnutls_handshake.c. The functions you're interested in are
>> _gnutls_handshake_client, _gnutls_handshake_server (if you're doing it
>> for both of them).
>>
>> A similar callback is _gnutls_user_hello_func which is the post_hello
>> callback.
>>
>> I'd glad to review and commit and patches for this issue.
>>
>> regards,
>> Nikos
>>




From simon at josefsson.org  Fri May 30 11:30:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 May 2008 11:30:17 +0200
Subject: [Help-gnutls] Re: Encrypted private keys
In-Reply-To: <20080530005012.GD29734@samad.com.au> (Alex Samad's message of
	"Fri, 30 May 2008 10:50:12 +1000")
References: <001201c8c145$655bfa50$fd08a8c0@asiapacific.hpqcorp.net>
	<877iddb49x.fsf@mocca.josefsson.org>
	<20080530005012.GD29734@samad.com.au>
Message-ID: <87bq2o3zrq.fsf@mocca.josefsson.org>

Alex Samad <alex at samad.com.au> writes:

>> > 2) If not how do you handle encrypted private keys
>> 
>> You can load PKCS#8 protected keys using:
>> 
>> gnutls_x509_privkey_import_pkcs8.
>> 
>> And encrypted keys stored in PKCS#12 using:
>> 
>> gnutls_certificate_set_x509_simple_pkcs12_file
>> 
>> These are the two standard ways to encrypt private keys that I know of.
>> OpenSSL has a proprietary standard that we don't support.
>
> This is the important bit of information I need, I had presumed their
> encrypted pem (?!) was a standard, so I should be able to use password
> protected pkcs12.

Whether to use PKCS#8 or PKCS#12 depends on whether you want to store
the certificate and CA information as well.  If you just want to protect
the keys, use PKCS#8.  If you want to include the certificate, use
PKCS#12.  Normally it is simpler to use PKCS#8 for the keys and provide
the certificate in a separate file.

/Simon




From rgerhards at gmail.com  Fri May 30 14:32:42 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 30 May 2008 14:32:42 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <877idc3zkr.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	<877idc3zkr.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>

I am hearing the hint ;) I already pulled the git archive, let me see
if I can do anything. Looks like this becomes more important than I
originally thought...

Rainer

On Fri, May 30, 2008 at 11:34 AM, Simon Josefsson <simon at josefsson.org> wrote:
> No, that is not implemented.  By reading the documentation for this, I
> think GnuTLS should provide a similar callback.  Patches welcome. :)
>
> /Simon
>
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>> Just double-checking:
>>
>> As far as I have seen openSSL's SSL_CTX_set_cert_verify_callback() is
>> not implemented inside the compatibility layer? I am asking because of
>>
>> http://www.ietf.org/mail-archive/web/syslog/current/msg01963.html
>>
>> Thanks,
>> Rainer
>>
>> On Wed, May 21, 2008 at 1:53 PM, Nikos Mavrogiannopoulos
>> <nmav at gnutls.org> wrote:
>>> Rainer Gerhards wrote:
>>>> Hi Nikos,
>>>>
>>>> On Wed, May 21, 2008 at 1:08 PM, Nikos Mavrogiannopoulos
>>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>>> Simon Josefsson wrote:
>>>>>
>>>>>>> I still would see a lot of benefit in being able to check the remote
>>>>>>> peers identity BEFORE the Finished message is sent. That way, I could
>>>>>>> block access to not permitted peers at the risk of the DoS outlined
>>>>>>> above. Am I still overlooking something?
>>>>>> No, I think that is correct.  Nikos, any thoughts?  You added some
>>>>>> callbacks during the handshake earlier, are any of those useful here?
>>>>> No unfortunately not. The callbacks I added are called after client
>>>>> hello is received. The callbacks you discuss need to be called after the
>>>>> certificate message is received.
>>>>
>>>> Could you point me to the file where processing the certificate
>>>> message is done? I would be interested to see if I could add a
>>>> callback, and may it even just be to know how it is done ;)
>>>
>>> The file is gnutls_handshake.c. The functions you're interested in are
>>> _gnutls_handshake_client, _gnutls_handshake_server (if you're doing it
>>> for both of them).
>>>
>>> A similar callback is _gnutls_user_hello_func which is the post_hello
>>> callback.
>>>
>>> I'd glad to review and commit and patches for this issue.
>>>
>>> regards,
>>> Nikos
>>>
>




From simon at josefsson.org  Fri May 30 14:42:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 May 2008 14:42:46 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 30 May 2008 14:32:42 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805200219j2893bf3fj75717c84eb560bb5@mail.gmail.com>
	<87hcctqq7z.fsf@mocca.josefsson.org>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	<877idc3zkr.fsf@mocca.josefsson.org>
	<dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>
Message-ID: <878wxs0xq1.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> I am hearing the hint ;) I already pulled the git archive, let me see
> if I can do anything. Looks like this becomes more important than I
> originally thought...

Keep in mind that if you want to get bigger patches (more than 10 lines
of code) added to gnutls, you'll need to sign papers to transfer the
copyright to the FSF.  I can send you the forms privately.

/Simon




From rgerhards at gmail.com  Fri May 30 15:15:10 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 30 May 2008 15:15:10 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <878wxs0xq1.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	<877idc3zkr.fsf@mocca.josefsson.org>
	<dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>
	<878wxs0xq1.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805300615p68bd3c4dtdcd12f239008baa7@mail.gmail.com>

Simon,

On Fri, May 30, 2008 at 2:42 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>
>> I am hearing the hint ;) I already pulled the git archive, let me see
>> if I can do anything. Looks like this becomes more important than I
>> originally thought...
>
> Keep in mind that if you want to get bigger patches (more than 10 lines
> of code) added to gnutls, you'll need to sign papers to transfer the
> copyright to the FSF.  I can send you the forms privately.

That's not a problem for me, but let me see first if I can find
sufficient time to actually do it. I so far have no idea how much of
the code/philosophy of GnuTLS I need to understand before I can do a
good enough patch. In any case, if I can, I will happily sign the
papers.

Rainer




From simon at josefsson.org  Fri May 30 15:20:36 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 May 2008 15:20:36 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <dc67eef70805300615p68bd3c4dtdcd12f239008baa7@mail.gmail.com>
	(Rainer Gerhards's message of "Fri, 30 May 2008 15:15:10 +0200")
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<dc67eef70805200309x5ea25674oae75b86b5b05b9c4@mail.gmail.com>
	<87skwdjlj6.fsf@mocca.josefsson.org> <483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	<877idc3zkr.fsf@mocca.josefsson.org>
	<dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>
	<878wxs0xq1.fsf@mocca.josefsson.org>
	<dc67eef70805300615p68bd3c4dtdcd12f239008baa7@mail.gmail.com>
Message-ID: <874p8g0vyz.fsf@mocca.josefsson.org>

"Rainer Gerhards" <rgerhards at gmail.com> writes:

> Simon,
>
> On Fri, May 30, 2008 at 2:42 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> "Rainer Gerhards" <rgerhards at gmail.com> writes:
>>
>>> I am hearing the hint ;) I already pulled the git archive, let me see
>>> if I can do anything. Looks like this becomes more important than I
>>> originally thought...
>>
>> Keep in mind that if you want to get bigger patches (more than 10 lines
>> of code) added to gnutls, you'll need to sign papers to transfer the
>> copyright to the FSF.  I can send you the forms privately.
>
> That's not a problem for me, but let me see first if I can find
> sufficient time to actually do it. I so far have no idea how much of
> the code/philosophy of GnuTLS I need to understand before I can do a
> good enough patch. In any case, if I can, I will happily sign the
> papers.

Great.  I fear you may need to gain a fair bit of understanding of some
rather messy internals to cook up this patch, but nothing is
impossible. ;)

/Simon




From rgerhards at gmail.com  Fri May 30 15:23:38 2008
From: rgerhards at gmail.com (Rainer Gerhards)
Date: Fri, 30 May 2008 15:23:38 +0200
Subject: [Help-gnutls] Re: Authentication during Handshake
In-Reply-To: <874p8g0vyz.fsf@mocca.josefsson.org>
References: <dc67eef70805191138x7b265be5v32d7071536120a94@mail.gmail.com>
	<483402CA.9020601@gmail.com>
	<dc67eef70805210444g744688edpe3f9191432bcab8f@mail.gmail.com>
	<48340D29.2050708@gnutls.org>
	<dc67eef70805292320y7b515e60m80beed48d753a574@mail.gmail.com>
	<877idc3zkr.fsf@mocca.josefsson.org>
	<dc67eef70805300532h569f04adqb6984cf2e8513b37@mail.gmail.com>
	<878wxs0xq1.fsf@mocca.josefsson.org>
	<dc67eef70805300615p68bd3c4dtdcd12f239008baa7@mail.gmail.com>
	<874p8g0vyz.fsf@mocca.josefsson.org>
Message-ID: <dc67eef70805300623g104b481am9df55704c6f58304@mail.gmail.com>

On Fri, May 30, 2008 at 3:20 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "Rainer Gerhards" <rgerhards at gmail.com> writes:
> Great.  I fear you may need to gain a fair bit of understanding of some
> rather messy internals to cook up this patch, but nothing is
> impossible. ;)

Yeah ... this is what I fear, too, and thus I am uncertain I can complete it ;)

Rainer