From simon at josefsson.org  Mon Aug 10 15:43:44 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 15:43:44 +0200
Subject: [Help-gnutls] GnuTLS 2.8.2
Message-ID: <87k51bg4xb.fsf@mocca.josefsson.org>

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

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

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

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

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

** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
into 1) not printing the entire CN/SAN field value when printing a
certificate and 2) cause incorrect positive matches when matching a
hostname against a certificate.  Some CAs apparently have poor
checking of CN/SAN values and issue these (arguable invalid)
certificates.  Combined, this can be used by attackers to become a
MITM on server-authenticated TLS sessions.  The problem is mitigated
since attackers needs to get one certificate per site they want to
attack, and the attacker reveals his tracks by applying for a
certificate at the CA.  It does not apply to client authenticated TLS
sessions.  Research presented independently by Dan Kaminsky and Moxie
Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
for providing one part of the patch.  [GNUTLS-SA-2009-4].

** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
Before it always returned false.  Reported by Peter Hendrickson
<pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.

** libgnutls: Fix off-by-one size computation error in unknown DN printing.
The error resulted in truncated strings when printing unknown OIDs in
X.509 certificate DNs.  Reported by Tim Kosse
<tim.kosse at filezilla-project.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.

** libgnutls: Return correct bit lengths of some MPIs.
gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
gnutls_dh_get_peers_public_bits.  Before the reported value was
overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.

** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
and
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.

** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
Before we required that the runtime library used the same (or more
recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
that the runtime usage is above the minimum required.  Reported by
Marco d'Itri <md at linux.it> via Andreas Metzler
<ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.

** minitasn1: Internal copy updated to libtasn1 v2.3.

** tests: Fix failure in "chainverify" because a certificate have expired.

** 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.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

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

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

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

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

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

eea59fb972e7d566679645a564a56b58aeffe10b  gnutls-2.8.2.tar.bz2

048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a  gnutls-2.8.2.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

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

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

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

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer includes
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2.

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

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

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

18fc15825832606123284dd5d7a77d402bf14101  gnutls-2.8.2.exe
9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3  gnutls-2.8.2.exe

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

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

af492d1c31ef4ecc27724839ce62f5a334731b26  gnutls-2.8.2.zip
ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c  gnutls-2.8.2.zip

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

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

4d591773c387be1409fb000ff1a9eae3c3c19756  mingw32-gnutls_2.8.2-1_all.deb
fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57  mingw32-gnutls_2.8.2-1_all.deb

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090810/607fbd3d/attachment.pgp>

From daniel at haxx.se  Wed Aug 12 00:04:44 2009
From: daniel at haxx.se (Daniel Stenberg)
Date: Wed, 12 Aug 2009 00:04:44 +0200 (CEST)
Subject: [Help-gnutls] gnutls_x509_crt_check_hostname()
Message-ID: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>

Hey gnutls'ers!

When I pass a cert and a hostname to the gnutls_x509_crt_check_hostname() 
function (I'm using 2.8.1-2 on a Debian Linux here), I'm seeing a problem I'd 
like your feedback on!

If the server cert has a subjectAltName field that doesn't match, but also a 
CN that matches, it seems this function happily returns OK. The way I'm 
reading RFC2818, that's not what it is supposed to do:

     If a subjectAltName extension of type dNSName is present, that MUST
     be used as the identity. Otherwise, the (most specific) Common Name
     field in the Subject field of the certificate MUST be used.

Am I wrong?

-- 

  / daniel.haxx.se




From daniel at haxx.se  Wed Aug 12 10:40:05 2009
From: daniel at haxx.se (Daniel Stenberg)
Date: Wed, 12 Aug 2009 10:40:05 +0200 (CEST)
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <87y6ppigif.fsf@mocca.josefsson.org>
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
	<87y6ppigif.fsf@mocca.josefsson.org>
Message-ID: <alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr>

On Wed, 12 Aug 2009, Simon Josefsson wrote:

> Can you post the certificate, or create one that exhibits the same problem?

Yes I can. I have the luxury of actually being able to repeat this problem 
within the curl test suite (test 311). This test was just added and thus made 
me notice this flaw...

The exact cerficates used for this test are found here: 
http://cool.haxx.se/cvs.cgi/curl/tests/certs/

The "Server-localhost0h-sv.pem" is used for the server cert, while 
EdelCurlRoot-ca.crt is the cacert.

-- 

  / daniel.haxx.se




From simon at josefsson.org  Wed Aug 12 10:43:21 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Aug 2009 10:43:21 +0200
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Wed, 12 Aug 2009 00:04:44 +0200 (CEST)")
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
Message-ID: <87tz0difrq.fsf@mocca.josefsson.org>

FWIW, I extended the self-test to check the situation you describe, and
as far as I can tell it appears to do the right thing.  Code in:

http://git.savannah.gnu.org/cgit/gnutls.git/diff/tests/hostname-check.c
http://git.savannah.gnu.org/cgit/gnutls.git/diff/tests/utils.c

Compile as
gcc -o hostname-check hostname-check.c -lgnutls utils.c

Expected output is

...
Testing pem9...
Hostname correctly does not match (0)
Hostname correctly matches (1)
...

/Simon




From simon at josefsson.org  Wed Aug 12 10:27:20 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Aug 2009 10:27:20 +0200
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Wed, 12 Aug 2009 00:04:44 +0200 (CEST)")
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
Message-ID: <87y6ppigif.fsf@mocca.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

> Hey gnutls'ers!
>
> When I pass a cert and a hostname to the
> gnutls_x509_crt_check_hostname() function (I'm using 2.8.1-2 on a
> Debian Linux here), I'm seeing a problem I'd like your feedback on!
>
> If the server cert has a subjectAltName field that doesn't match, but
> also a CN that matches, it seems this function happily returns OK. The
> way I'm reading RFC2818, that's not what it is supposed to do:
>
>     If a subjectAltName extension of type dNSName is present, that MUST
>     be used as the identity. Otherwise, the (most specific) Common Name
>     field in the Subject field of the certificate MUST be used.
>
> Am I wrong?

I agree with you.

Looking at the code, though, it seems that at a first glance both the
comments and the code suggests that this situation is taken into
account.  I've noticed that the code fails to check return values, so a
corrupt SAN might be skipped, but I'm not sure if that applies in your
situation.

Can you post the certificate, or create one that exhibits the same
problem?

We'll need to do a 2.8.3 shortly so if there is another problem in this
area, it would be nice to fix it at the same time.

/Simon




From simon at josefsson.org  Wed Aug 12 10:53:03 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Aug 2009 10:53:03 +0200
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Wed, 12 Aug 2009 10:40:05 +0200 (CEST)")
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
	<87y6ppigif.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr>
Message-ID: <87prb1ifbk.fsf@mocca.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

> On Wed, 12 Aug 2009, Simon Josefsson wrote:
>
>> Can you post the certificate, or create one that exhibits the same problem?
>
> Yes I can. I have the luxury of actually being able to repeat this
> problem within the curl test suite (test 311). This test was just
> added and thus made me notice this flaw...
>
> The exact cerficates used for this test are found here:
> http://cool.haxx.se/cvs.cgi/curl/tests/certs/
>
> The "Server-localhost0h-sv.pem" is used for the server cert, while
> EdelCurlRoot-ca.crt is the cacert.

Thanks.  The extra spice needed here is that the SAN contains an
embedded NUL.

This is what I feared would happen if we return an error when NUL in
CN/SAN values is discovered: some other code incorrectly uses the error
to mean that there is no valid SAN field at all, and proceeds to check
the CN instead.  Possibly we need to return valid data, but make sure
any NULs are correctly LDAP-escaped.

Maybe we can come up with a simpler solution...

/Simon




From simon at josefsson.org  Wed Aug 12 10:54:34 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Aug 2009 10:54:34 +0200
Subject: [Help-gnutls] Re: GnuTLS 2.8.2
In-Reply-To: <1250066631.3868.8.camel@marathon> (Jeff Cai's message of "Wed,
	12 Aug 2009 16:43:51 +0800")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon>
Message-ID: <87iqgtif91.fsf@mocca.josefsson.org>

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

>> What's New
>> ==========
>> 
>> ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
>> By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
>> into 1) not printing the entire CN/SAN field value when printing a
>> certificate and 2) cause incorrect positive matches when matching a
>> hostname against a certificate.  Some CAs apparently have poor
>> checking of CN/SAN values and issue these (arguable invalid)
>> certificates.  Combined, this can be used by attackers to become a
>> MITM on server-authenticated TLS sessions.  The problem is mitigated
>> since attackers needs to get one certificate per site they want to
>> attack, and the attacker reveals his tracks by applying for a
>> certificate at the CA.  It does not apply to client authenticated TLS
>> sessions.  Research presented independently by Dan Kaminsky and Moxie
>> Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
>> for providing one part of the patch.  [GNUTLS-SA-2009-4].
>
> How is it affecting old versions of gnutls like 2.6 and 2.4? Do they
> also need a patch applied if not upgrading them?

Yes.  I believe all earlier versions are affected.

/Simon




From simon at josefsson.org  Thu Aug 13 11:51:13 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 11:51:13 +0200
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr> (Daniel
	Stenberg's message of "Wed, 12 Aug 2009 10:40:05 +0200 (CEST)")
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
	<87y6ppigif.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr>
Message-ID: <87zla4dotq.fsf@mocca.josefsson.org>

Daniel Stenberg <daniel at haxx.se> writes:

> On Wed, 12 Aug 2009, Simon Josefsson wrote:
>
>> Can you post the certificate, or create one that exhibits the same problem?
>
> Yes I can. I have the luxury of actually being able to repeat this
> problem within the curl test suite (test 311). This test was just
> added and thus made me notice this flaw...
>
> The exact cerficates used for this test are found here:
> http://cool.haxx.se/cvs.cgi/curl/tests/certs/
>
> The "Server-localhost0h-sv.pem" is used for the server cert, while
> EdelCurlRoot-ca.crt is the cacert.

Looking into this further, I'm not able to reproduce it...  The code
below, that uses your cert, works for me with 2.8.2.  It appears as if
the patch that went into 2.8.2 to fix the security issue is effective.
Am I doing something wrong?

If you can convert the code into a test that incorrectly fails with
2.8.2 (or upcoming 2.8.3) it will be easier for me to fix it.

jas at mocca:~$ gcc -o test test.c -lgnutls
jas at mocca:~$ ./test
Hostname correctly does not match (0)
jas at mocca:~$ 

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 5778 bytes
Desc: not available
URL: </pipermail/attachments/20090813/37264f35/attachment.c>

From simon at josefsson.org  Thu Aug 13 11:52:41 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 11:52:41 +0200
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <87zla4dotq.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 13 Aug 2009 11:51:13 +0200")
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
	<87y6ppigif.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr>
	<87zla4dotq.fsf@mocca.josefsson.org>
Message-ID: <87vdksdora.fsf@mocca.josefsson.org>

D'oh - you said in your first e-mail that you were using 2.8.1.  The
problem was fixed in 2.8.2.  So try upgrading.

/Simon




From simon at josefsson.org  Thu Aug 13 12:32:01 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 12:32:01 +0200
Subject: [Help-gnutls] GnuTLS 2.8.3
Message-ID: <871vngdmxq.fsf@mocca.josefsson.org>

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

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

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

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

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

** libgnutls: Fix patch for NUL in CN/SAN in last release.
Code intended to be removed would lead to an read-out-bound error in
some situations.  Reported by Tomas Hoger <thoger at redhat.com>.  A CVE
code have been allocated for the vulnerability: [CVE-2009-2730].

** libgnutls: Fix rare failure in gnutls_x509_crt_import.
The function may fail incorrectly when an earlier certificate was
imported to the same gnutls_x509_crt_t structure.

** libgnutls-extra, libgnutls-openssl: Fix MinGW cross-compiling build error.

** tests: Made self-test mini-eagain take less time.

** doc: Typo fixes.

** 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.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

c25fb354258777f9ee34b79b08eb87c024cada75  gnutls-2.8.3.tar.bz2
dff4d774ec9339a1e94711fc9c3762d36df1e77c0b1c1a591ea190aa  gnutls-2.8.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

For developers interested in improving code quality, we publish
Cyclomatic code complexity charts that help you find code that may need
review and improvements:

  http://www.gnu.org/software/gnutls/cyclo/

Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:

  http://www.gnu.org/software/gnutls/coverage/

Community
=========

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

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

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

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

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer includes
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.3.

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

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

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

6c6503cbd357d71595a320502ce3e32fe5598d64  gnutls-2.8.3.exe
f75988a6efe8306bf4ba4827ff49a2fd39f3f6d9730ddffcca1f3254  gnutls-2.8.3.exe

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

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

4c4829495d7277b3fec69a975084e1144e805e0d  gnutls-2.8.3.zip
515dcbe98b739db7419ae25db1a2d59d3cea60683ca1bfd424c348b3  gnutls-2.8.3.zip

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

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

8cf060268369f1d261b10731840cf0392e625210  mingw32-gnutls_2.8.3-1_all.deb
0f99a5a356cd1a03cc0a3cce9f19b7615772d4486fea0d06e68f3ef6  mingw32-gnutls_2.8.3-1_all.deb

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

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

From daniel at haxx.se  Thu Aug 13 13:49:50 2009
From: daniel at haxx.se (Daniel Stenberg)
Date: Thu, 13 Aug 2009 13:49:50 +0200 (CEST)
Subject: [Help-gnutls] Re: gnutls_x509_crt_check_hostname()
In-Reply-To: <87zla4dotq.fsf@mocca.josefsson.org>
References: <alpine.DEB.2.00.0908120001150.14983@yvahk2.pbagnpgbe.fr>
	<87y6ppigif.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0908121036300.1809@yvahk2.pbagnpgbe.fr>
	<87zla4dotq.fsf@mocca.josefsson.org>
Message-ID: <alpine.DEB.2.00.0908131349230.28043@yvahk2.pbagnpgbe.fr>

On Thu, 13 Aug 2009, Simon Josefsson wrote:

> If you can convert the code into a test that incorrectly fails with 2.8.2 
> (or upcoming 2.8.3) it will be easier for me to fix it.

Confirmed to work properly in 2.8.3. Thanks! Sorry for the noise.

-- 

  / daniel.haxx.se




From simon at josefsson.org  Fri Aug 14 12:02:27 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Aug 2009 12:02:27 +0200
Subject: [Help-gnutls] NUL bytes in X.509 CN/SAN fields [GNUTLS-SA-2009-4]
	[CVE-2009-2730]
Message-ID: <87ws56pvbg.fsf@mocca.josefsson.org>

Research presented independently by Dan Kaminsky and Moxie Marlinspike
at BlackHat09 demonstrated a vulnerability related to NUL bytes in X.509
certificate name fields.  Attackers needs to go to a CA and acquire a
certificate for an invalid name.  To attack GnuTLS, the attacker needs
to acquire such an invalid certificate for each TLS server to be
attacked.  The attacker is then able to use the certificate to become a
man-in-the-middle on server authenticated channels.  The client will
receive the attacker's certificate, so the attack leaves traces with the
client.  The attack does not work for client-authenticated TLS channels.

To make client notice the attack and reject it, a few separate aspects
needs to be resolved:

1) When displaying a certificate to the user, GnuTLS needs to be fixed
so that it does not truncate strings in CN/SAN fields to the first NUL.

2) When comparing the CN/SAN fields to a hostname, it has to make sure
it compares the entire string, and not only up until the first NUL.

We recommend all users to upgrade to version 2.8.3 which solves these
concerns.

For people using older releases, or wants to read the minimal patch
required to solve the problem, I have prepared patches that applies to
version 2.8.1 -- the last stable releases that didn't have this
vulnerability.

To solve 1) apply PATCH 1 included below.  The patches in git
corresponding to this patch is (they have to be applied in order):

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=a431be86124f900c4082e82d32917f86fcce461a
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=74b6d92f9675ce4e03642c4d6ced4a3a614b07f6
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=40081594e3de518b998f3e5177ed5a9f7707f2e8

To solve 2) apply PATCH 2 included below.  This patch was supplied by
Tomas Hoger <thoger at redhat.com>.  The patches in git corresponding to
this patch is (they have to be applied in order):

http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=5a58e9d33448235377afd5fbfcee1683dc70eae3
http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=1ea190d216767dd4ab93b87361cbcb9d4fb3aafc

I have verified that the patches work for v2.6.6 as well if you manually
resolve one failed hunk.

/Simon

PATCH 1

diff -ur gnutls-2.8.1.orig/lib/x509/common.c gnutls-2.8.1/lib/x509/common.c
--- gnutls-2.8.1.orig/lib/x509/common.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/common.c	2009-08-14 11:56:17.000000000 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation
+ * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -242,6 +242,10 @@
     {
       str[len] = 0;
 
+      /* Refuse to deal with strings containing NULs. */
+      if (strlen (str) != len)
+	return GNUTLS_E_ASN1_DER_ERROR;
+
       if (res)
 	_gnutls_str_cpy (res, *res_size, str);
       *res_size = len;
@@ -291,25 +295,27 @@
 	    non_printable = 0;
 	}
 
-      if (res)
+      if (non_printable == 0)
 	{
-	  if (non_printable == 0)
-	    {
-	      str[len] = 0;
-	      _gnutls_str_cpy (res, *res_size, str);
-	      *res_size = len;
-	    }
-	  else
+	  str[len] = 0;
+
+	  /* Refuse to deal with strings containing NULs. */
+	  if (strlen (str) != len)
+	    return GNUTLS_E_ASN1_DER_ERROR;
+
+	  if (res)
+	    _gnutls_str_cpy (res, *res_size, str);
+	  *res_size = len;
+	}
+      else
+	{
+	  result = _gnutls_x509_data2hex (str, len, res, res_size);
+	  if (result < 0)
 	    {
-	      result = _gnutls_x509_data2hex (str, len, res, res_size);
-	      if (result < 0)
-		{
-		  gnutls_assert ();
-		  return result;
-		}
+	      gnutls_assert ();
+	      return result;
 	    }
 	}
-
     }
 
   return 0;
diff -ur gnutls-2.8.1.orig/lib/x509/output.c gnutls-2.8.1/lib/x509/output.c
--- gnutls-2.8.1.orig/lib/x509/output.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/output.c	2009-08-14 11:56:17.000000000 +0200
@@ -354,6 +354,17 @@
 	  return;
 	}
 
+      if ((err == GNUTLS_SAN_DNSNAME
+	   || err == GNUTLS_SAN_RFC822NAME
+	   || err == GNUTLS_SAN_URI) &&
+	  strlen (buffer) != size)
+	{
+	  adds (str, _("warning: distributionPoint contains an embedded NUL, "
+		       "replacing with '!'\n"));
+	  while (strlen (buffer) < size)
+	    buffer[strlen (buffer)] = '!';
+	}
+
       switch (err)
 	{
 	case GNUTLS_SAN_DNSNAME:
@@ -552,6 +563,17 @@
 	  return;
 	}
 
+      if ((err == GNUTLS_SAN_DNSNAME
+	   || err == GNUTLS_SAN_RFC822NAME
+	   || err == GNUTLS_SAN_URI) &&
+	  strlen (buffer) != size)
+	{
+	  adds (str, _("warning: SAN contains an embedded NUL, "
+		       "replacing with '!'\n"));
+	  while (strlen (buffer) < size)
+	    buffer[strlen (buffer)] = '!';
+	}
+
       switch (err)
 	{
 	case GNUTLS_SAN_DNSNAME:
@@ -623,8 +645,18 @@
 	      }
 
 	    if (err == GNUTLS_SAN_OTHERNAME_XMPP)
-	      addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix,
-		    (int) size, buffer);
+	      {
+		if (strlen (buffer) != size)
+		  {
+		    adds (str, _("warning: SAN contains an embedded NUL, "
+				 "replacing with '!'\n"));
+		    while (strlen (buffer) < size)
+		      buffer[strlen (buffer)] = '!';
+		  }
+
+		addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix,
+		      (int) size, buffer);
+	      }
 	    else
 	      {
 		addf (str, _("%s\t\t\totherName OID: %.*s\n"), prefix,


PATCH 2

diff -ur gnutls-2.8.1.orig/lib/gnutls_str.c gnutls-2.8.1/lib/gnutls_str.c
--- gnutls-2.8.1.orig/lib/gnutls_str.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/gnutls_str.c	2009-08-14 11:40:45.000000000 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2002, 2004, 2005, 2007, 2008  Free Software Foundation
+ * Copyright (C) 2002, 2004, 2005, 2007, 2008, 2009  Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -363,17 +363,22 @@
 
 /* compare hostname against certificate, taking account of wildcards
  * return 1 on success or 0 on error
+ *
+ * note: certnamesize is required as X509 certs can contain embedded NULs in
+ * the strings such as CN or subjectAltName
  */
 int
-_gnutls_hostname_compare (const char *certname, const char *hostname)
+_gnutls_hostname_compare (const char *certname,
+			  size_t certnamesize,
+			  const char *hostname)
 {
   /* find the first different character */
   for (; *certname && *hostname && toupper (*certname) == toupper (*hostname);
-       certname++, hostname++)
+       certname++, hostname++, certnamesize--)
     ;
 
   /* the strings are the same */
-  if (strlen (certname) == 0 && strlen (hostname) == 0)
+  if (certnamesize == 0 && *hostname == '\0')
     return 1;
 
   if (*certname == '*')
@@ -381,15 +386,16 @@
       /* a wildcard certificate */
 
       certname++;
+      certnamesize--;
 
       while (1)
 	{
 	  /* Use a recursive call to allow multiple wildcards */
-	  if (_gnutls_hostname_compare (certname, hostname))
-	    {
-	      return 1;
-	    }
-	  /* wildcards are only allowed to match a single domain component or component fragment */
+	  if (_gnutls_hostname_compare (certname, certnamesize, hostname))
+	    return 1;
+
+	  /* wildcards are only allowed to match a single domain
+	     component or component fragment */
 	  if (*hostname == '\0' || *hostname == '.')
 	    break;
 	  hostname++;
diff -ur gnutls-2.8.1.orig/lib/gnutls_str.h gnutls-2.8.1/lib/gnutls_str.h
--- gnutls-2.8.1.orig/lib/gnutls_str.h	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/gnutls_str.h	2009-08-14 11:40:45.000000000 +0200
@@ -79,7 +79,7 @@
 int _gnutls_hex2bin (const opaque * hex_data, int hex_size, opaque * bin_data,
 		     size_t * bin_size);
 
-int _gnutls_hostname_compare (const char *certname, const char *hostname);
+int _gnutls_hostname_compare (const char *certname, size_t certnamesize, const char *hostname);
 #define MAX_CN 256
 
 #endif
diff -ur gnutls-2.8.1.orig/lib/openpgp/pgp.c gnutls-2.8.1/lib/openpgp/pgp.c
--- gnutls-2.8.1.orig/lib/openpgp/pgp.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/openpgp/pgp.c	2009-08-14 11:40:45.000000000 +0200
@@ -570,7 +570,7 @@
 
       if (ret == 0)
 	{
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    return 1;
 	}
     }
diff -ur gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c gnutls-2.8.1/lib/x509/rfc2818_hostname.c
--- gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/rfc2818_hostname.c	2009-08-14 11:40:45.000000000 +0200
@@ -74,7 +74,7 @@
       if (ret == GNUTLS_SAN_DNSNAME)
 	{
 	  found_dnsname = 1;
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    {
 	      return 1;
 	    }
@@ -84,7 +84,7 @@
 	  found_dnsname = 1;	/* RFC 2818 is unclear whether the CN
 				   should be compared for IP addresses
 				   too, but we won't do it.  */
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    {
 	      return 1;
 	    }
@@ -104,7 +104,7 @@
 	  return 0;
 	}
 
-      if (_gnutls_hostname_compare (dnsname, hostname))
+      if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	{
 	  return 1;
 	}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090814/7f81d2ea/attachment.pgp>

From simon at josefsson.org  Fri Aug 14 12:14:21 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Aug 2009 12:14:21 +0200
Subject: [Help-gnutls] How to check if your GnuTLS is vulnerable to
	NUL-in-CN/SAN issue
Message-ID: <87my62purm.fsf@mocca.josefsson.org>

Here is how you test if your GnuTLS library is vulnerable to the
NUL-in-CN/SAN issue (i.e., [GNUTLS-SA-2009-4] [CVE-2009-2730]).

Download and build:
http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c

For example:

jas at mocca:~$ wget -q http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c
jas at mocca:~$ gcc -o nul-in-x509-names nul-in-x509-names.c -lgnutls
jas at mocca:~$ ./nul-in-x509-names 
gnutls_x509_crt_check_hostname OK (NUL-IN-CN)
gnutls_x509_crt_check_hostname OK (NUL-IN-SAN)
jas at mocca:~$

If your library have not yet been patched, the output will look like:

gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN)
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN)

If you have a locally installed GnuTLS version and wants to check your
system library version, on GNU/Linux system you can use the LD_PRELOAD
variable to point at the exact library version to test.  For example on
my Debian system:

jas at mocca:~$ LD_PRELOAD=/usr/lib/libgnutls.so ./nul-in-x509-names 
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN)
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN)
jas at mocca:~$ 

To verify that displaying of certificates works correctly, you can use
two sample certificates provided by Tomas Hoger <thoger at redhat.com>.

To test whether NUL in CN is handled properly, here is how you do it:

jas at mocca:~$ cat>nul-cn.pem
-----BEGIN CERTIFICATE-----
MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES
MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N
eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k
bHkgQ0EwHhcNMDkwODA0MDczMzQzWhcNMTkwODAyMDczMzQzWjAjMSEwHwYDVQQD
Exh3d3cuYmFuay5jb20ALmJhZGd1eS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDNJnCWqaZdPpztDwgVWnwXJWhorxO5rUH6ElTihHJ9WNHiQELB
We0FPaoQU3AAiDp3oMBWnqx9ISpxRFEIvBcH2qijdtxRvBuK9gIaVb9GtERrJ16+
5ReLVrLGgjYRg6i/9y8NF/bNR7VvK6ZBto0zX+rqi7Ea4pk4/1lbCqFxE8o3P7mw
HpGayJM1DErgnfTSYcdOW0EKfDFUmdv1Zc6A08ICN2T9VBJ76qyFWVwX4S720Kjy
0C6UWS/Cpl/aB957LhQH7eQnJDedCS6x+VpIuYAkQ+bLx24139VpNP/m1p7odmZu
X1kBPJY77HILPB6VD85oE5wi3Ru1RChQSgV/AgMBAAGjezB5MAkGA1UdEwQCMAAw
LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G
A1UdDgQWBBQzFSS+2mY6BovZJzQ6r2JA5JVmXTAfBgNVHSMEGDAWgBQKaTlfnTAE
GAguAg7m6p2yJvbiajANBgkqhkiG9w0BAQUFAAOCAQEAMmUjH8jZU4SC0ArrFFEk
A7xsGypa/hvw6GkMKxmGz38ydtgr0s+LxNG2W5xgo5kuknIGzt6L0qLSiXwTqQtO
vhIJ5dYoOqynJlaUfxPuZH3elGB1wbxVl9SqE44C2LCwcFOuGFPOqrIshT7j8+Em
8/pc7vh7C8Y5tQQzXq64Xg5mzKjAag3sYMHF2TnqvRuPHH0WOLHoyDcBqkuZ3+QP
EL5h7prPzScFRgBg2Gp0CDI8i5ABagczDGyQ2+r7ahcadrtzFCfhpH7V3TCxXfIO
qtSy1Uz2T5EqB/Q3wc9IGcX+fpKWqN9QajGSo7EU/kHMSWKYTerFugUtScMicu9B
CQ==
-----END CERTIFICATE-----
jas at mocca:~$ certtool -i < nul-cn.pem 
...
	Subject: CN=#13187777772e62616e6b2e636f6d002e6261646775792e636f6d
...

Notice how the Subject line is LDAP escaped when it contains a NUL
value.

Buggy versions would display the cert like this:

	Subject: CN=www.bank.com

To test whether NUL in CN is handled properly, here is how you do it:

jas at mocca:~$ cat>nul-san.pem
-----BEGIN CERTIFICATE-----
MIIDrTCCApWgAwIBAgIBADANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES
MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N
eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k
bHkgQ0EwHhcNMDkwODA0MDY1MzA1WhcNMTkwODAyMDY1MzA1WjAZMRcwFQYDVQQD
Ew53d3cuYmFkZ3V5LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AM0mcJappl0+nO0PCBVafBclaGivE7mtQfoSVOKEcn1Y0eJAQsFZ7QU9qhBTcACI
OnegwFaerH0hKnFEUQi8FwfaqKN23FG8G4r2AhpVv0a0RGsnXr7lF4tWssaCNhGD
qL/3Lw0X9s1HtW8rpkG2jTNf6uqLsRrimTj/WVsKoXETyjc/ubAekZrIkzUMSuCd
9NJhx05bQQp8MVSZ2/VlzoDTwgI3ZP1UEnvqrIVZXBfhLvbQqPLQLpRZL8KmX9oH
3nsuFAft5CckN50JLrH5Wki5gCRD5svHbjXf1Wk0/+bWnuh2Zm5fWQE8ljvscgs8
HpUPzmgTnCLdG7VEKFBKBX8CAwEAAaOBpDCBoTAJBgNVHRMEAjAAMCwGCWCGSAGG
+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU
MxUkvtpmOgaL2Sc0Oq9iQOSVZl0wHwYDVR0jBBgwFoAUCmk5X50wBBgILgIO5uqd
sib24mowJgYDVR0RBB8wHYIbd3d3LmJhbmsuY29tAHd3dy5iYWRndXkuY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQAnbn2zqYZSV2qgxjBsHpQJp2+t/hGfvjKNAXuLlGbX
fLaxkPzk9bYyvGxxI7EYiNZHvNoHx15GcTrmQG7Bfx1WlnBl2FGp3J6lBgCY5x4Q
vIK6AOVOog8+7Irdb8bJweztbXwxPmaHR6GLFTwhfuwheD0hcHK6cMNk+B1P2dAn
PD5+olmuvprTAESncjrjP8ibxY+xlP4AD264FIjxA1CRUa/wHve4WqRXNS3xrciu
3SlhFH3q0TSAXBv960PcIW3GRPk7VHbEkVuspI5y59gk/6dawO8nw9fk+X9VjQ0w
7KLZbch29L6UPRIySpFP28PndgdaEpcYtxUAmFkhiT41
-----END CERTIFICATE-----
jas at mocca:~$ certtool -i < nul-san.pem 
...
		Subject Alternative Name (not critical):
warning: SAN contains an embedded NUL, replacing with '!'
			DNSname: www.bank.com!www.badguy.com
...

Notice the warning and the full output.

Buggy versions would display the cert like this:

		Subject Alternative Name (not critical):
			DNSname: www.bank.com

I hope this helps you test your system!

/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/20090814/eb35e38e/attachment.pgp>

From hoyt6 at llnl.gov  Fri Aug 21 19:29:21 2009
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Fri, 21 Aug 2009 10:29:21 -0700
Subject: Multiple Definition of "_Unwind_Resume"
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9D9F8D94A87@NSPEXMBX-C.the-lab.llnl.gov>

I'm using mingw gcc 4.4.0 w/ dw2 exception handling on a windows xp machine. I'm using the latest source (I think - v2.8.3). When compiling, I get a multiple definition error for "_Unwind_Resume." The shared libraries (dlls) compile fine, but it errors out when attempting to link a test C++ program. I didn't used to get any errors like this, but I was using a slightly older version of gcc and it was using SJLJ exception handling. Here's the output:

libtool: link: g++ -g -O2 -Wl,--exclude-libs=libintl.a -o .libs/ex-cxx.exe ex-cxx.o  ./.libs/libexamples.a ../../lib/.libs/libgnutls.dll.a ../../libextra/.libs/libgnutls-extra.dll.a ../../gl/.libs/libgnu.a ../../lib/.libs/libgnutlsxx.dll.a /C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs/libgnutls.dll.a -lz /C/Build/Windows/Win32/Release/lib/libgcrypt.dll.a /C/Build/Windows/Win32/Release/lib/libgpg-error.dll.a -lws2_32 -L/C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs -L/C/Build/Windows/Win32/Release/obj/gnutls/libextra/.libs -L/C/Build/Windows/Win32/Release/lib -L/C/Build/Windows/Win32/Release/libc
:/msys/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/libgcc_eh.a(unwind-dw2.o): In function `Unwind_Resume':
d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_Resume'
../../lib/.libs/libgnutlsxx.dll.a(d000015.o):(.text+0x0): first defined here
collect2: ld returned 1 exit status
make[4]: *** [ex-cxx.exe] Error 1

If there's a way to avoid compiling and running this particular test, that wouldn't be ideal, but it would be "okay" enough for now.

I appreciate any help anyone can offer.

Thanks,
- David Hoyt




From simon at josefsson.org  Sun Aug 23 17:26:20 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 23 Aug 2009 17:26:20 +0200
Subject: Multiple Definition of "_Unwind_Resume"
In-Reply-To: <B288BDCCFC5B874BBC7D22117EDFB6F9D9F8D94A87@NSPEXMBX-C.the-lab.llnl.gov>
	(David Hoyt's message of "Fri, 21 Aug 2009 10:29:21 -0700")
References: <B288BDCCFC5B874BBC7D22117EDFB6F9D9F8D94A87@NSPEXMBX-C.the-lab.llnl.gov>
Message-ID: <87iqge7dr7.fsf@mocca.josefsson.org>

"Hoyt, David" <hoyt6 at llnl.gov> writes:

> I'm using mingw gcc 4.4.0 w/ dw2 exception handling on a windows xp machine. I'm using the latest source (I think - v2.8.3). When compiling, I get a multiple definition error for "_Unwind_Resume." The shared libraries (dlls) compile fine, but it errors out when attempting to link a test C++ program. I didn't used to get any errors like this, but I was using a slightly older version of gcc and it was using SJLJ exception handling. Here's the output:
>
> libtool: link: g++ -g -O2 -Wl,--exclude-libs=libintl.a -o .libs/ex-cxx.exe ex-cxx.o  ./.libs/libexamples.a ../../lib/.libs/libgnutls.dll.a ../../libextra/.libs/libgnutls-extra.dll.a ../../gl/.libs/libgnu.a ../../lib/.libs/libgnutlsxx.dll.a /C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs/libgnutls.dll.a -lz /C/Build/Windows/Win32/Release/lib/libgcrypt.dll.a /C/Build/Windows/Win32/Release/lib/libgpg-error.dll.a -lws2_32 -L/C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs -L/C/Build/Windows/Win32/Release/obj/gnutls/libextra/.libs -L/C/Build/Windows/Win32/Release/lib -L/C/Build/Windows/Win32/Release/libc
> :/msys/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/libgcc_eh.a(unwind-dw2.o): In function `Unwind_Resume':
> d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_Resume'
> ../../lib/.libs/libgnutlsxx.dll.a(d000015.o):(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make[4]: *** [ex-cxx.exe] Error 1
>
> If there's a way to avoid compiling and running this particular test, that wouldn't be ideal, but it would be "okay" enough for now.
>
> I appreciate any help anyone can offer.

I am sorry I have no idea how to resolve this.  I suspect it is not a
strictly GnuTLS-related problem, so you may get more help asking some
mingw/gcc/c++ forum instead.  It could be a bug in how the libgnutlsxx
library is built.

/Simon




From hoyt6 at llnl.gov  Mon Aug 24 20:27:57 2009
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Mon, 24 Aug 2009 11:27:57 -0700
Subject: Multiple Definition of "_Unwind_Resume"
In-Reply-To: <87iqge7dr7.fsf@mocca.josefsson.org>
References: <B288BDCCFC5B874BBC7D22117EDFB6F9D9F8D94A87@NSPEXMBX-C.the-lab.llnl.gov>
	<87iqge7dr7.fsf@mocca.josefsson.org>
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9D9F8D94A8A@NSPEXMBX-C.the-lab.llnl.gov>

Well I got through it by configuring it w/ the C++ portion disabled since I didn't really need it.

I tried changing the order of the libraries being linked, using the static dw2 lib instead of the shared one, etc., but it didn't work. But I suppose it's good enough for now. Thanks anyway!

-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org] 
Sent: Sunday, August 23, 2009 8:26 AM
To: Hoyt, David
Cc: help-gnutls at gnu.org
Subject: Re: Multiple Definition of "_Unwind_Resume"

"Hoyt, David" <hoyt6 at llnl.gov> writes:

> I'm using mingw gcc 4.4.0 w/ dw2 exception handling on a windows xp machine. I'm using the latest source (I think - v2.8.3). When compiling, I get a multiple definition error for "_Unwind_Resume." The shared libraries (dlls) compile fine, but it errors out when attempting to link a test C++ program. I didn't used to get any errors like this, but I was using a slightly older version of gcc and it was using SJLJ exception handling. Here's the output:
>
> libtool: link: g++ -g -O2 -Wl,--exclude-libs=libintl.a -o .libs/ex-cxx.exe ex-cxx.o  ./.libs/libexamples.a ../../lib/.libs/libgnutls.dll.a ../../libextra/.libs/libgnutls-extra.dll.a ../../gl/.libs/libgnu.a ../../lib/.libs/libgnutlsxx.dll.a /C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs/libgnutls.dll.a -lz /C/Build/Windows/Win32/Release/lib/libgcrypt.dll.a /C/Build/Windows/Win32/Release/lib/libgpg-error.dll.a -lws2_32 -L/C/Build/Windows/Win32/Release/obj/gnutls/lib/.libs -L/C/Build/Windows/Win32/Release/obj/gnutls/libextra/.libs -L/C/Build/Windows/Win32/Release/lib -L/C/Build/Windows/Win32/Release/libc
> :/msys/mingw/bin/../lib/gcc/mingw32/4.4.0-dw2/libgcc_eh.a(unwind-dw2.o): In function `Unwind_Resume':
> d:\crossdev\b4.4.0-tdm-1\mingw32\libgcc/../../../gcc-4.4.0/libgcc/../gcc/unwind.inc:220: multiple definition of `_Unwind_Resume'
> ../../lib/.libs/libgnutlsxx.dll.a(d000015.o):(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make[4]: *** [ex-cxx.exe] Error 1
>
> If there's a way to avoid compiling and running this particular test, that wouldn't be ideal, but it would be "okay" enough for now.
>
> I appreciate any help anyone can offer.

I am sorry I have no idea how to resolve this.  I suspect it is not a
strictly GnuTLS-related problem, so you may get more help asking some
mingw/gcc/c++ forum instead.  It could be a bug in how the libgnutlsxx
library is built.

/Simon




From mydevforums at gmail.com  Wed Aug 26 15:28:04 2009
From: mydevforums at gmail.com (Ram G)
Date: Wed, 26 Aug 2009 09:28:04 -0400
Subject: Question on Anonymous Diffie-Hellman key exchange
Message-ID: <3a8533cc0908260628w5c8a9663t1c40436b1bf9712d@mail.gmail.com>

Hi,

I have a question regarding the generation of DH parameters.

>From GnuTLS documentation (
http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html#gnutls-dh-params-generate2
)

"....Also note that the DH parameters are only useful to servers. Since
clients use the parameters sent by the server, it's of no use to call this
in client side....."

What I have been able to gather from online sources on DH key exchange is
that

1) Alice and Bob decides on the prime P and generator G
2) Alice decides on a random number X and sends G(power of X) mod P to Bob
3) Bob decides on a random number Y and sends G(power of Y) mod P to Alice
4) Both Bob and Alice can calculate the shared secret on their own from
steps 2 and 3.

So my question is - why are the DH params not generated in the client side
too ? What is the point in generating the DH params and the shared key in
the server (Bob) and sending it to the client (Alice) - won't it be
accessible to an attacker when it is sent in the clear ?

I would really appreciate if someone can shed some light on how anonymous DH
works in GnuTLS.

Thanks

Ramg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090826/f6b1d50a/attachment.htm>

From nmav at gnutls.org  Thu Aug 27 17:32:35 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 27 Aug 2009 18:32:35 +0300
Subject: Question on Anonymous Diffie-Hellman key exchange
In-Reply-To: <3a8533cc0908260628w5c8a9663t1c40436b1bf9712d@mail.gmail.com>
References: <3a8533cc0908260628w5c8a9663t1c40436b1bf9712d@mail.gmail.com>
Message-ID: <4A96A713.2020108@gnutls.org>

Ram G wrote:
> Hi,
> "....Also note that the DH parameters are only useful to servers. Since
> clients use the parameters sent by the server, it's of no use to call this
> in client side....."
[...]
> 1) Alice and Bob decides on the prime P and generator G
> 2) Alice decides on a random number X and sends G(power of X) mod P to Bob
> 3) Bob decides on a random number Y and sends G(power of Y) mod P to Alice
> 4) Both Bob and Alice can calculate the shared secret on their own from
> steps 2 and 3.
> 
> So my question is - why are the DH params not generated in the client side
> too ? What is the point in generating the DH params and the shared key in
> the server (Bob) and sending it to the client (Alice) - won't it be
> accessible to an attacker when it is sent in the clear ?

Hello,
 They will be available to attackers but the security of the DH
cryptosystem doesn't depend on the secrecy of the group and generator.
The security depends on the random numbers X and Y.

regards,
Nikos





From mydevforums at gmail.com  Thu Aug 27 17:50:45 2009
From: mydevforums at gmail.com (Ram G)
Date: Thu, 27 Aug 2009 11:50:45 -0400
Subject: Question on Anonymous Diffie-Hellman key exchange
In-Reply-To: <4A96A713.2020108@gnutls.org>
References: <3a8533cc0908260628w5c8a9663t1c40436b1bf9712d@mail.gmail.com>
	<4A96A713.2020108@gnutls.org>
Message-ID: <3a8533cc0908270850o5b619f9cn252a779704e781e3@mail.gmail.com>

So does this mean the GnuTLS client generates the "shared key" on its own ?

When I read that the DH parameters are useful only to the server, perhaps
I got confused that the server generates P, G and the "Shared Key" and sends
the "Shared Key" to the client.

So this is the correct logic:

1) GnuTLS server generates P & G and sends it to the client
2) GnuTLS client selects a random number X and sends G(power of X) mod P to
server
3) GnuTLS server selects a random number Y and sends G(power of Y) mod P to
client
4) Both client and server independently calculates the "shared key"

Thanks for clearing my confusion

Ramg

On Thu, Aug 27, 2009 at 11:32 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org>wrote:

> Ram G wrote:
> > Hi,
> > "....Also note that the DH parameters are only useful to servers. Since
> > clients use the parameters sent by the server, it's of no use to call
> this
> > in client side....."
> [...]
> > 1) Alice and Bob decides on the prime P and generator G
> > 2) Alice decides on a random number X and sends G(power of X) mod P to
> Bob
> > 3) Bob decides on a random number Y and sends G(power of Y) mod P to
> Alice
> > 4) Both Bob and Alice can calculate the shared secret on their own from
> > steps 2 and 3.
> >
> > So my question is - why are the DH params not generated in the client
> side
> > too ? What is the point in generating the DH params and the shared key in
> > the server (Bob) and sending it to the client (Alice) - won't it be
> > accessible to an attacker when it is sent in the clear ?
>
> Hello,
>  They will be available to attackers but the security of the DH
> cryptosystem doesn't depend on the secrecy of the group and generator.
> The security depends on the random numbers X and Y.
>
> regards,
> Nikos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090827/5eb11a13/attachment.htm>