From tzz at lifelogs.com  Mon Jul  1 14:31:28 2013
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Mon, 01 Jul 2013 08:31:28 -0400
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
Message-ID: <8761wulavz.fsf@lifelogs.com>

(I know the function is deprecated in a recent 3.x, but this is a
general behavior question.)

Emacs users are wondering about the negotiation behavior with the DH
minimum bits.  Currently Emacs uses `gnutls_dh_set_prime_bits' and the
users can set it very low, 256 for instance.  We understand that's
insecure, but want to know about the negotiation: can it go up?  Are
there any rules?  Some IMAP servers, for instance, refuse to connect if
it's over 256 (the full story is in an Emacs bug discussion).

I looked around but the best I could find was a SSH-related RFC that
discusses this negotiation.  I would appreciate some information
regarding the behavior of GnuTLS (and possibly OpenSSL and others, as a
comparison).

Ted



From nmav at gnutls.org  Mon Jul  1 22:45:17 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 01 Jul 2013 22:45:17 +0200
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
In-Reply-To: <8761wulavz.fsf@lifelogs.com>
References: <8761wulavz.fsf@lifelogs.com>
Message-ID: <51D1EA5D.7070003@gnutls.org>

On 07/01/2013 02:31 PM, Ted Zlatanov wrote:
> (I know the function is deprecated in a recent 3.x, but this is a
> general behavior question.)
> Emacs users are wondering about the negotiation behavior with the DH
> minimum bits.  Currently Emacs uses `gnutls_dh_set_prime_bits' and the
> users can set it very low, 256 for instance.  We understand that's
> insecure,

256 bits, means that it is a matter of minutes to recover the keys used
in the session in a modern PC.

> but want to know about the negotiation: can it go up?  Are
> there any rules?  Some IMAP servers, for instance, refuse to connect if
> it's over 256 (the full story is in an Emacs bug discussion).

I don't quite understand what do you mean about going up. However, the
problem is in the DHE ciphersuites that do not allow the client to
notify the server of its security threshold for the parameters. You are
better off using the ECDHE equivalents (in recent gnutls version they
take precedence over DHE).

regards,
Nikos



From tzz at lifelogs.com  Mon Jul  1 23:50:56 2013
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Mon, 01 Jul 2013 17:50:56 -0400
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
Message-ID: <87txkehrun.fsf@lifelogs.com>

On Mon, 01 Jul 2013 22:45:17 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 07/01/2013 02:31 PM, Ted Zlatanov wrote:
>> (I know the function is deprecated in a recent 3.x, but this is a
>> general behavior question.)
>> Emacs users are wondering about the negotiation behavior with the DH
>> minimum bits.  Currently Emacs uses `gnutls_dh_set_prime_bits' and the
>> users can set it very low, 256 for instance.  We understand that's
>> insecure,

NM> 256 bits, means that it is a matter of minutes to recover the keys used
NM> in the session in a modern PC.

We understand it's insecure.  Our users have told us some servers won't
work without it.  We need to know if setting it to 256 means the client
and the server will negotiate a higher setting with DHE.  We also don't
want to spend a lot of effort making custom settings for this if it's
irrelevant for 3.x.

>> but want to know about the negotiation: can it go up?  Are
>> there any rules?  Some IMAP servers, for instance, refuse to connect if
>> it's over 256 (the full story is in an Emacs bug discussion).

NM> I don't quite understand what do you mean about going up. However, the
NM> problem is in the DHE ciphersuites that do not allow the client to
NM> notify the server of its security threshold for the parameters.

I need to know, when the client sets this to 256, what actually happens
during the session:

- is there a negotiation?
- will the number be opportunistically adjusted up by either side?
- how can we detect a server that demands 256 and renegotiate only for
  those servers?

NM> You are better off using the ECDHE equivalents (in recent gnutls
NM> version they take precedence over DHE).

We've been considering requiring GnuTLS 3.x but due to the platforms we
support in Emacs, that's not a simple decision.  Can you explain the
above questions and how they are different with ECDHE?  We plan to move
to 3.x fairly soon in any case, but knowing this will make my life easier.

Will legacy servers (of which there are many, all critical to our users
apparently) work with ECDHE?  Or do they drop down to DHE?  If they drop
to DHE, do we still need the minimum prime bits?  Where do we set it in
3.x, since `gnutls_dh_set_prime_bits' is deprecated in 3.12, and I can't
find a priority string setting for it?

Basically I have to answer all these questions from Emacs and especially
Gnus users, so I'm trying to understand the protocols a little better.

Thanks!
Ted



From dkg at fifthhorseman.net  Tue Jul  2 00:22:41 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Jul 2013 18:22:41 -0400
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
In-Reply-To: <87txkehrun.fsf@lifelogs.com>
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com>
Message-ID: <51D20131.5040705@fifthhorseman.net>

On 07/01/2013 05:50 PM, Ted Zlatanov wrote:
> We understand it's insecure.  Our users have told us some servers won't
> work without it.

I'd be curious to know which servers fail like this.  on those servers,
i'd say you'd be better off just not negotiating the any of the DHE
ciphersuites at all, rather than forcing the connection to a
trivially-crackable diffie-hellman exchange.

	--dkg

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

From nmav at gnutls.org  Tue Jul  2 01:00:09 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 02 Jul 2013 01:00:09 +0200
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
In-Reply-To: <87txkehrun.fsf@lifelogs.com>
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com>
Message-ID: <51D209F9.2060702@gnutls.org>

On 07/01/2013 11:50 PM, Ted Zlatanov wrote:

> NM> 256 bits, means that it is a matter of minutes to recover the keys used
> NM> in the session in a modern PC.
> We understand it's insecure.  Our users have told us some servers won't
> work without it.  We need to know if setting it to 256 means the client
> and the server will negotiate a higher setting with DHE.  We also don't
> want to spend a lot of effort making custom settings for this if it's
> irrelevant for 3.x.

The set_prime_bits sets the lowest acceptable threshold for a DHE prime.
That is the actual security level. That unfortunately it is not
negotiated in TLS, and thus the client can only drop the connection if
the server goes lower than that threshold. A way to overcome that issue
is instead of lowering the threshold, to retry a connection without DHE
as Daniel mentioned.

> - how can we detect a server that demands 256 and renegotiate only for
>   those servers?

You cannot. The way TLS is designed, you only get an error at the handshake.

> We've been considering requiring GnuTLS 3.x but due to the platforms we
> support in Emacs, that's not a simple decision.  Can you explain the
> above questions and how they are different with ECDHE?  We plan to move
> to 3.x fairly soon in any case, but knowing this will make my life easier.

In ECDHE the curve (which is effectively the security level) is
negotiated and thus has not the problems of DHE.

> Will legacy servers (of which there are many, all critical to our users
> apparently) work with ECDHE? 

Unfortunately, I cannot know that. If they are very old servers most
probably wouldn't support elliptic curves.

regards,
Nikos



From tzz at lifelogs.com  Tue Jul  2 20:31:15 2013
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Tue, 02 Jul 2013 14:31:15 -0400
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net>
Message-ID: <87mwq44xvw.fsf@lifelogs.com>

On Mon, 01 Jul 2013 18:22:41 -0400 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote: 

DKG> On 07/01/2013 05:50 PM, Ted Zlatanov wrote:
>> We understand it's insecure.  Our users have told us some servers won't
>> work without it.

DKG> I'd be curious to know which servers fail like this.  on those servers,
DKG> i'd say you'd be better off just not negotiating the any of the DHE
DKG> ciphersuites at all, rather than forcing the connection to a
DKG> trivially-crackable diffie-hellman exchange.

Here are the user reports about buggy servers and further discussions,
though in many cases they don't tell me the server name and I haven't
been asking.

http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-07/msg00657.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-04/msg00761.html
http://thread.gmane.org/gmane.emacs.gnus.general/83413/focus=83441

On Tue, 02 Jul 2013 01:00:09 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> The set_prime_bits sets the lowest acceptable threshold for a DHE prime.
NM> That is the actual security level. That unfortunately it is not
NM> negotiated in TLS, and thus the client can only drop the connection if
NM> the server goes lower than that threshold. A way to overcome that issue
NM> is instead of lowering the threshold, to retry a connection without DHE
NM> as Daniel mentioned.

(Assume we're upgrading Emacs to use the latest GnuTLS.)

I think negotiating the connection twice is unacceptable for
performance.  We have to find a way to do it in one attempt, even if the
user has to configure something about the exceptional servers.  Can we
always try ECDHE and only do DHE if the user tells us so?

>> - how can we detect a server that demands 256 and renegotiate only for
>> those servers?

NM> You cannot. The way TLS is designed, you only get an error at the
NM> handshake.

>> We've been considering requiring GnuTLS 3.x but due to the platforms we
>> support in Emacs, that's not a simple decision.  Can you explain the
>> above questions and how they are different with ECDHE?  We plan to move
>> to 3.x fairly soon in any case, but knowing this will make my life easier.

NM> In ECDHE the curve (which is effectively the security level) is
NM> negotiated and thus has not the problems of DHE.

>> Will legacy servers (of which there are many, all critical to our users
>> apparently) work with ECDHE? 

NM> Unfortunately, I cannot know that. If they are very old servers most
NM> probably wouldn't support elliptic curves.

Well, there's always collateral damage.  We can tell our users "This
server is very old so it can't work by default.  You can set this
special workaround but only for a specific host name."  So I think it's
enough to detect this case, and in Emacs-land we can even auto-configure
so it only happens once.

Can we, then, have the following sequence:

- always connect with ECDHE, no DHE at all

- if ECDHE doesn't work, tell the user to configure
  some-special-variable for the target host to use DHE.  This will also
  let the user set the DHE min prime bits.  This code path does the
  dh_set_prime_bits in the priority string.

If so, could you tell me how to do the two steps?  I can't find examples
of this fallback in the manual in the repo or online, unfortunately.

(It would have been nice if the priority string could have the
dh_set_prime_bits control in it from the beginning.  I suggested packing
as much as possible in the priority string in the past, and still think
it's a good idea, essentially giving users a DSL to control GnuTLS
connection parameters.  Then the problem is reduced to keeping a special
priority string per host name, which is much more manageable for our
users.)

Ted



From spam.vassdal at hotmail.com  Wed Jul  3 15:00:22 2013
From: spam.vassdal at hotmail.com (Daniel Vassdal)
Date: Wed, 3 Jul 2013 15:00:22 +0200
Subject: [gnutls-help] gnutls_mac_algorithm_t and gnutls_digest_algorithm_t
	1:1 compatible?
Message-ID: <DUB115-W12267091FCAF84D42460ACF90730@phx.gbl>

Is it reliable to cast from gnutls_mac_algorithm_t to gnutls_digest_algorithm_t?
I want to let the user dynamically select hashing algorithm from what their gnutls installation supports, so what I'm doing is:
gnutls_digest_algorithm_t selected_hash = (gnutls_digest_algorithm_t)gnutls_mac_get_id(hash_name);
Is this prone to failure? I see the enums have a comment in them telling to align them. Could this change?
Is there a better way to do what I want to do?

 --DV

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130703/43bc9d86/attachment.html>

From nmav at gnutls.org  Thu Jul  4 23:00:29 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 04 Jul 2013 23:00:29 +0200
Subject: [gnutls-help] gnutls_mac_algorithm_t and
 gnutls_digest_algorithm_t 1:1 compatible?
In-Reply-To: <DUB115-W12267091FCAF84D42460ACF90730@phx.gbl>
References: <DUB115-W12267091FCAF84D42460ACF90730@phx.gbl>
Message-ID: <51D5E26D.7070202@gnutls.org>

On 07/03/2013 03:00 PM, Daniel Vassdal wrote:
> Is it reliable to cast from gnutls_mac_algorithm_t to gnutls_digest_algorithm_t?
> I want to let the user dynamically select hashing algorithm from what their gnutls installation supports, so what I'm doing is:
> gnutls_digest_algorithm_t selected_hash = (gnutls_digest_algorithm_t)gnutls_mac_get_id(hash_name);
> Is this prone to failure? I see the enums have a comment in them telling to align them. Could this change?
> Is there a better way to do what I want to do?

In general yes, but note that gnutls_mac_algorithm_t is a superset of
gnutls_digest_algorithm_t, i.e., a MAC algorithm may not always be a
digest algorithm (e.g. UMAC).

I'll try to add similar functions for the digest algorithms to avoid
such issues.

regards,
Nikos



From nmav at gnutls.org  Sun Jul  7 19:36:18 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 07 Jul 2013 19:36:18 +0200
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
In-Reply-To: <87mwq44xvw.fsf@lifelogs.com>
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net>
 <87mwq44xvw.fsf@lifelogs.com>
Message-ID: <51D9A712.8070000@gnutls.org>

On 07/02/2013 08:31 PM, Ted Zlatanov wrote:

> I think negotiating the connection twice is unacceptable for
> performance.  We have to find a way to do it in one attempt, even if the
> user has to configure something about the exceptional servers.  Can we
> always try ECDHE and only do DHE if the user tells us so?

Hello,
 You can always disable DHE. That way ECDHE will be negotiated with RSA
as fallback.

regards,
Nikos



From tzz at lifelogs.com  Tue Jul  9 15:13:59 2013
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Tue, 09 Jul 2013 09:13:59 -0400
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net>
 <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org>
Message-ID: <874nc3x4dk.fsf@lifelogs.com>

On Sun, 07 Jul 2013 19:36:18 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On 07/02/2013 08:31 PM, Ted Zlatanov wrote:
>> I think negotiating the connection twice is unacceptable for
>> performance.  We have to find a way to do it in one attempt, even if the
>> user has to configure something about the exceptional servers.  Can we
>> always try ECDHE and only do DHE if the user tells us so?

NM>  You can always disable DHE. That way ECDHE will be negotiated with RSA
NM> as fallback.

I'm sorry to keep asking, but I can't find this explicitly in the
manual.  Maybe I'm looking in the wrong places.  From
http://gnutls.org/manual/html_node/Priority-Strings.html I am guessing
that:

1) Including ANON-ECDH enables ECDHE
2) !DHE-RSA:!DHE-DSS disables DHE (not sure if DHE-RSA should be enabled for us)
3) NORMAL enables DHE and ECDHE

Can you confirm this?

It would be very nice if the initial keywords' description in that
documentation page actually showed what's enabled by each one,
especially "NORMAL".

I also can't tell how to set the DH minimum prime bits in a priority
string, if that's possible at all.

I can write additions to the manual to explain any of the above if you
think they are needed.

Thanks!
Ted



From nmav at gnutls.org  Tue Jul  9 15:46:56 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 09 Jul 2013 15:46:56 +0200
Subject: [gnutls-help] gnutls_dh_set_prime_bits question
In-Reply-To: <874nc3x4dk.fsf@lifelogs.com>
References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org>
 <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net>
 <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org>
 <874nc3x4dk.fsf@lifelogs.com>
Message-ID: <51DC1450.9070405@gnutls.org>

On 07/09/2013 03:13 PM, Ted Zlatanov wrote:

> NM> On 07/02/2013 08:31 PM, Ted Zlatanov wrote:
>>> I think negotiating the connection twice is unacceptable for
>>> performance.  We have to find a way to do it in one attempt, even if the
>>> user has to configure something about the exceptional servers.  Can we
>>> always try ECDHE and only do DHE if the user tells us so?
> 
> NM>  You can always disable DHE. That way ECDHE will be negotiated with RSA
> NM> as fallback.
> 
> I'm sorry to keep asking, but I can't find this explicitly in the
> manual.  Maybe I'm looking in the wrong places.  From
> http://gnutls.org/manual/html_node/Priority-Strings.html I am guessing
> that:
> 
> 1) Including ANON-ECDH enables ECDHE

No. Anon-ECDH is for anonymous authentication. ECDHE-RSA and ECDHE-ECDSA
are for certificate authentication and are already enabled by NORMAL.

> 2) !DHE-RSA:!DHE-DSS disables DHE (not sure if DHE-RSA should be enabled for us)

Correct.

> 3) NORMAL enables DHE and ECDHE

Yes.

> It would be very nice if the initial keywords' description in that
> documentation page actually showed what's enabled by each one,
> especially "NORMAL".

Indeed, this may be useful. I should update that at some time.
You can see that using gnutls-cli -l --priority xxx.

> I also can't tell how to set the DH minimum prime bits in a priority
> string, if that's possible at all.

The initial keyword of the string sets the acceptable security level,
which at some later point it is translated on the minimum size of the
prime. Currently normal sets the value GNUTLS_SEC_PARAM_VERY_WEAK, which
is 727 bits of a prime. SECURE128 and 256 increase that value.

The idea was to have some consistency in the security levels, but given
the security levels offered by real-world servers, that would take some
time to occur.

> I can write additions to the manual to explain any of the above if you
> think they are needed.

That would be really helpful.

regards,
Nikos



From nmav at gnutls.org  Sat Jul 13 11:11:19 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jul 2013 11:11:19 +0200
Subject: [gnutls-help] gnutls 3.1.13
Message-ID: <51E119B7.70101@gnutls.org>

Hello,
 I've just released gnutls 3.1.13. This is a bug-fix release on the 3.1
stable branch.

* Version 3.1.13 (released 2013-07-12)

** libgnutls: Ensure that gnutls_dtls_set_mtu() cannot exceed the
maximum allowed DTLS size.

** libgnutls: Fixes in SRTP extension generation when MKI is being
used.

** libgnutls: Fixes in discovery of trusted objects (CA certificates)
PKCS #11 in tokens. Patch by Stef Walter.

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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.13.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.13.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.13.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.13.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From nmav at gnutls.org  Sat Jul 13 11:13:59 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Jul 2013 11:13:59 +0200
Subject: [gnutls-help] gnutls 3.0.31
Message-ID: <51E11A57.904@gnutls.org>

Hello,
 I've just released gnutls 3.0.31. This is a bug-fix release on the
previous stable branch.

* Version 3.0.31 (released 2013-07-12)

** libgnutls: Ensure that gnutls_dtls_set_mtu() cannot exceed the
maximum allowed DTLS size.

** libgnutls: Fixes in discovery of trusted objects (CA certificates)
PKCS #11 in tokens. Patch by Stef Walter.

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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.31.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.31.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.31.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.31.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From nmav at gnutls.org  Sun Jul 14 11:03:26 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 14 Jul 2013 11:03:26 +0200
Subject: [gnutls-help] gnutls 3.2.2
Message-ID: <51E2695E.4030009@gnutls.org>

Hello,
 I've just released gnutls 3.2.2. This release adds features and fixes
bugs on the current stable branch.

* Version 3.2.2 (released 2013-07-14)

** libgnutls: Several optimizations in the related to packet processing
subsystems.

** libgnutls: DTLS replay detection can now be disabled (to be used
in certain transport layers like SCTP).

** libgnutls: Fixes in SRTP extension generation when MKI is being
used.

** libgnutls: Added ability to set hooks before or after sending or
receiving any handshake message with
gnutls_handshake_set_hook_function().

** API and ABI modifications:
GNUTLS_NO_REPLAY_PROTECTION: Added
gnutls_certificate_set_trust_list: Added
gnutls_cipher_get_tag_size: Added
gnutls_record_overhead_size: Added
gnutls_est_record_overhead_size: Added
gnutls_handshake_set_hook_function: Added
gnutls_handshake_description_get_name: Added
gnutls_digest_list: Added
gnutls_digest_get_id: Added
gnutls_digest_get_name: Added


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.2.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.2.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.2.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.2.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From hfusa at web.de  Mon Jul 15 22:22:29 2013
From: hfusa at web.de (Horst Freiburger)
Date: Mon, 15 Jul 2013 22:22:29 +0200 (CEST)
Subject: [gnutls-help] Using GnuTLS with an HSM
Message-ID: <trinity-d5249a92-1a70-4237-b963-5ad3f24b7fd0-1373919749395@3capp-webde-bs26>

An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130715/1f2eed2d/attachment.html>

From nmav at gnutls.org  Tue Jul 16 10:19:43 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 16 Jul 2013 10:19:43 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <trinity-d5249a92-1a70-4237-b963-5ad3f24b7fd0-1373919749395@3capp-webde-bs26>
References: <trinity-d5249a92-1a70-4237-b963-5ad3f24b7fd0-1373919749395@3capp-webde-bs26>
Message-ID: <51E5021F.8080106@gnutls.org>

On 07/15/2013 10:22 PM, Horst Freiburger wrote:
> Hi!
> I'am quiet new to TLS an GnuTLS. I want to use GnuTLS in a 
> client-server-project. I successfully have a TLS connection between the client 
> and the server using GnuTLS. Because of the use of an HSM i have a few 
> requirements to GnuTLS and i'am not sure if GnuTLS ist able to fullfil my 
> requirements.
> 1. Before sending "Client Hello" the HSM is generating a random number. This 
> random number should be used in the "Client Hello"-message.

Hello Horst,
 That one yes. There is gnutls_handshake_set_random().

> 2. After receiving "Server Key Exchange" from the Client should give the Public 
> Key of the Server to the HSM. The HSM generates the pre-masters secret.

On which ciphersuite do you refer to, and which side? For example on
server side and the RSA ciphersuite what your HSM does makes no sense.

I've never seen this type of HSM. HSMs typically protect the long-term
key of the server (or client), and for that provide operations on the
key without exposing them. What does your HSM protect?

regards,
Nikos



From hfusa at web.de  Wed Jul 17 21:18:17 2013
From: hfusa at web.de (Horst Freiburger)
Date: Wed, 17 Jul 2013 21:18:17 +0200 (CEST)
Subject: [gnutls-help] Using GnuTLS with an HSM
Message-ID: <trinity-f48be5d4-4386-41b6-8f57-d03b1b508e6c-1374088697693@3capp-webde-bs09>


I had a private conversation with Nikos. We decided to put this an the mailing list. Here a the results so far. The rest will be treated here...
?
----------------------------------------
The conversation so far:

?Hello Nikos!

No. That is a good idea! Maybe someone in the near future has the same problem, because of the TR-03109 in germany will very important for the german "Energiewende". What should i do, so that this conversation will appear on the mailing list?

Today i analysed this flow-chart a secound time and it seems to be like the standard-tls-handshake (except the thing with the HSM). The HSM has to do 5 steps in this handshake:

1. generate the random number ("ClientHello" - this step is solved with gnutls_handshake_set_random())
2. generate a Client-DH-EC-keypair for the DH-key-exchange while the handshake ("ClientKeyExchange")
3. calculate the pre-master-secret with the private Client-DH-Key and the public Server-DH-Key
4. calculate the signature of the All-Clients-Messages-Hash
5. verify the signature of the All-Servers-Message-Hash


Is there a way (except of direct changing the sourcecode) to manipulate the gnutls_handshake()? (Something like overwriting the whole handshake with my own functions, where i can call the security-module-things. Or to redirect the relevant function-calls in the real gnutls_handshake() to my functions) The HSM for TR-03109 doesn't exist neither. So i want to do something like write this function-prototypes in my program:
RANDOMUMBER hsm_generate_randomnumber (); (for step 1)
DH_CLIENT_PUBKEY hsm_generate_dhec_keypair (); (for step 2)
DH_PMS hsm_generate_pms (DH_SERVER_PUBKEY); (for step 3)
SIG hsm_generate_signature (HASH); (for step 4)
BOOL hsm_verify_signature (HASH, SIGNATURE); (for step 5)
The Prototypes may differ in the final version. Just an example.

An example:
In the sourcode of lib\gnutls_handhshake.c in the function static int_gnutls_send_client_hello (gnutls_session_t session, int again) something like this happenens when called:
if(funktionPointerToHsm_generate_randomnumber != NULL)
{
// call function and get the random number from there
}
else
{
// do the normal way and calculate the random number with the gnutls functions
}

Similar at the other steps. (I know that for the step 1 this way is not required because if gnutls_handshake_set_random(), but i just found the right position in the sourcecode to explain.)

I read that you added a gnutls_handshake_set_hook_function() to GNUTLS. Maybe that is the right thing for my problem and that does exactly what i discribed above. But i'm not familiar with the gnutls_handshake_set_hook_function()-function yet. (Just startet with GNUTLS 3 days ago). ;)

Sorry for the german document TR-03109. If you want i could post a english translation of this picture.

Thank you for your time and your answers!

Horst

Gesendet: Mittwoch, 17. Juli 2013 um 14:03 Uhr
Von: "Nikos Mavrogiannopoulos" <nmav at gnutls.org>
An: "Horst Freiburger" <hfusa at web.de>
Betreff: Re: Re: [gnutls-help] Using GnuTLS with an HSM
Hello Horst,
Would you mind to continue this conversation on the mailing list? I
think it is quite interesting for other parties that may use that
library that way?

regards,
Nikos

On Tue, Jul 16, 2013 at 7:22 PM, Horst Freiburger <hfusa at web.de> wrote:
> Hello Nikos!
>
> Thank you very much for your help. That one with the Random-Number is very
> useful to me!
>
> I think my secound question was explained in a very strange way be me. Sorry
> it was very late. ;)
>
> I'm just testing something for research by myself. I want to do a
> TLS-Handshake like it is explained in BSI TR-03109 (the german way of smart
> metering). The flow-diagram i want to realise is in
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03109/TR03109-1.pdf
> on page 121. (Sorry this document ist german but the TLS-Handshake looks
> nearly like a normal one except of the HSM "Sicherheitsmodul".)
>
> The SMGW-Administrator is the server. The Smart Meter Gateway is the client.
>
> The first thing with the random number "Generiere Zufallszahl A" was my
> first question. You just posted the solution! Thank a lot! This is a TLS 1.2
> handshake with TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as the cipher suite.
> The the flow chart says that the server generates a EC-Keypair and sends the
> public key of this pair to the client. The client sends this to the HSM. The
> HSM genrates a EC-Keypair and calculates a master secret. The master secret
> and the public key of the clients key-pair will be send to the server. Now
> the hashes over all messages will be calculated and so on...
>
> So i think it is something like a standard TLS-handshake because everything
> that the TR-03109 uses is standard. But i don't know where to look, to find
> the solution. The use of a HSM is quiet new to me.
>
> Thank you for your time and your reply!
>
> Horst
>
> Gesendet: Dienstag, 16. Juli 2013 um 10:19 Uhr
> Von: "Nikos Mavrogiannopoulos" <nmav at gnutls.org>
> An: "Horst Freiburger" <hfusa at web.de>
> Cc: gnutls-help at lists.gnutls.org
> Betreff: Re: [gnutls-help] Using GnuTLS with an HSM
> On 07/15/2013 10:22 PM, Horst Freiburger wrote:
>> Hi!
>> I'am quiet new to TLS an GnuTLS. I want to use GnuTLS in a
>> client-server-project. I successfully have a TLS connection between the
>> client
>> and the server using GnuTLS. Because of the use of an HSM i have a few
>> requirements to GnuTLS and i'am not sure if GnuTLS ist able to fullfil my
>> requirements.
>> 1. Before sending "Client Hello" the HSM is generating a random number.
>> This
>> random number should be used in the "Client Hello"-message.
>
> Hello Horst,
> That one yes. There is gnutls_handshake_set_random().
>
>> 2. After receiving "Server Key Exchange" from the Client should give the
>> Public
>> Key of the Server to the HSM. The HSM generates the pre-masters secret.
>
> On which ciphersuite do you refer to, and which side? For example on
> server side and the RSA ciphersuite what your HSM does makes no sense.
>
> I've never seen this type of HSM. HSMs typically protect the long-term
> key of the server (or client), and for that provide operations on the
> key without exposing them. What does your HSM protect?
>
> regards,
> Nikos
>


From nmav at gnutls.org  Fri Jul 19 10:02:52 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 19 Jul 2013 10:02:52 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <trinity-f48be5d4-4386-41b6-8f57-d03b1b508e6c-1374088697693@3capp-webde-bs09>
References: <trinity-f48be5d4-4386-41b6-8f57-d03b1b508e6c-1374088697693@3capp-webde-bs09>
Message-ID: <51E8F2AC.4060606@gnutls.org>

On 07/17/2013 09:18 PM, Horst Freiburger wrote:

> Today i analysed this flow-chart a secound time and it seems to be
> like the standard-tls-handshake (except the thing with the HSM). The
> HSM has to do 5 steps in this handshake: 1. generate the random
> number ("ClientHello" - this step is solved with
> gnutls_handshake_set_random())

> 2. generate a Client-DH-EC-keypair for the DH-key-exchange while the
> handshake ("ClientKeyExchange")

For that you'll need to modify gnutls to add a hook for generating
a private-public key pair, rather than calling gnutls_pk_generate().

> 3. calculate the pre-master-secret with the private Client-DH-Key and
> the public Server-DH-Key

This is also done by gnutls itself, so modification via a hook will be
needed.

> 4. calculate the signature of the All-Clients-Messages-Hash

This can be done using either the PKCS #11 API or use a private key that
is imported using gnutls_privkey_import_ext2().

> 5. verify the signature of the All-Servers-Message-Hash

This is also not supported. Another hook will be required there, or
better something like gnutls_pubkey_import_ext2() that would allow
importing a "virtual" public key that provides the verification
operation similarly to gnutls_privkey_import_ext2().

> Is there a way (except of direct changing the sourcecode) to
> manipulate the gnutls_handshake()? (Something like overwriting the
> whole handshake with my own functions, where i can call the
> security-module-things. 

Not really. The security module you're working on, is a bit particular
and requires much more than any supported modules.

However, if you make the hooks and can be used in a generic way there
will be no problem including them in a future release.

> Or to redirect the relevant function-calls in
> the real gnutls_handshake() to my functions) The HSM for TR-03109
> doesn't exist neither. So i want to do something like write this
> function-prototypes in my program: RANDOMUMBER
> hsm_generate_randomnumber (); (for step 1) DH_CLIENT_PUBKEY
> hsm_generate_dhec_keypair (); (for step 2) DH_PMS hsm_generate_pms
> (DH_SERVER_PUBKEY); (for step 3) SIG hsm_generate_signature (HASH);
> (for step 4) BOOL hsm_verify_signature (HASH, SIGNATURE); (for step
> 5) The Prototypes may differ in the final version. Just an example.
> An example: In the sourcode of lib\gnutls_handhshake.c in the
> function static int_gnutls_send_client_hello (gnutls_session_t
> session, int again) something like this happenens when called: 
> if(funktionPointerToHsm_generate_randomnumber != NULL) { // call
> function and get the random number from there } else { // do the
> normal way and calculate the random number with the gnutls functions 
> }

While you could directly modify gnutls for your purpose, doing things in
a more generic way (i.e., hooks), would allow that to be included in a
future version and thus you'll be able to upgrade to a future gnutls
version.

> I read that you added a gnutls_handshake_set_hook_function() to
> GNUTLS. Maybe that is the right thing for my problem and that does
> exactly what i discribed above. But i'm not familiar with the
> gnutls_handshake_set_hook_function()-function yet. (Just startet with
> GNUTLS 3 days ago). ;)

The set_hook_function() provides a call to the "hook" function after or
before a handshake message has been received. That is probably not what
you want.

best regards,
Nikos


From hfusa at web.de  Fri Jul 19 14:14:59 2013
From: hfusa at web.de (Horst Freiburger)
Date: Fri, 19 Jul 2013 14:14:59 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51E8F2AC.4060606@gnutls.org>
References: <51E8F2AC.4060606@gnutls.org>
Message-ID: <51E92DC3.7040407@web.de>

Hi Nikos,

thanks for your reply.

So i think i will test the things (and do some test-implementations) you 
said in the near future. Any tipps to program the hook thing? Is the use 
of function-pointers a good solution to implement this? (maybe i can 
also imspire myself of your hook implementation)


Another question to do the implementation tests:
I use the gnutls windows-version in Dev-C++ using mingw. Does a little 
tutorial exists where the compiling of the gnutls-sourcecode for windows 
is explained? (Linux-PCs exists if needed.) I wish to program my changes 
in an editor and then compile a windows version of gnutls so that i 
could directly test this in my (windows-based-)server-client-testtools 
using my fresh compiled gnutls.

Thanks for your time.

regards

Horst


From pascal.fautrero at crdp.ac-versailles.fr  Fri Jul 19 14:20:09 2013
From: pascal.fautrero at crdp.ac-versailles.fr (Pascal Fautrero)
Date: Fri, 19 Jul 2013 14:20:09 +0200
Subject: [gnutls-help] openldap+gnutls - unable to get TLS client DN
Message-ID: <51E92EF9.4000901@crdp.ac-versailles.fr>

Hi,

I try to understand a situation encountered by several openldap users on 
the net. I use openldap package built for debian (compiled with gnutls, 
that's why I submit this post).

When a consumer openldap tries to connect to a provider openldap using 
TLS, the provider displays the following message :

"unable to get TLS client DN"

Connection is ok if we set (on the server) TLSVerifyClient to never or 
allow. But just for fun, I wan't to manage with such a message. And I 
must admit it is quite difficult to understand for me. Help or hints 
would be appreciated :)

I found that "unable to get TLS client DN" is displayed because 
gnutls_certificate_get_peers sends back an empty raw_certificate_list.
Thus, I tried to study the gnutls_handshake procedure to understand why 
such a list is empty.

On the server side, I found that _gnutls_proc_x509_server_certificate 
sends back GNUTLS_E_NO_CERTIFICATE_FOUND.
If I look at _gnutls_handshake_server, when openldap slave tries to 
connect to openldap master, only STATE0, STATE6 and STATE7 are executed. 
Is it a normal situation ?

On the client side, If I look at _gnutls_handshake_client, during the 
same handshake, only STATE0 is executed. More, gnutls_handshake function 
is executed only once. STATE7, responsible of sending client certificate 
is never executed. Is it a normal situation to see a TLS handshake with 
so few STATE executed ? STATE2 and STATE3 shouldn't be catched ?

Thanks in advance

Regards,

Pascal Fautrero
CRDP de l'acad?mie de Versailles



From nmav at gnutls.org  Fri Jul 19 14:45:29 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 19 Jul 2013 14:45:29 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51E92DC3.7040407@web.de>
References: <51E8F2AC.4060606@gnutls.org>
	<51E92DC3.7040407@web.de>
Message-ID: <CAJU7zaLStg5ew0XDvxY7+z7O9LUDrgpaFu1MM7PAQ=6R7x=MWQ@mail.gmail.com>

On Fri, Jul 19, 2013 at 2:14 PM, Horst Freiburger <hfusa at web.de> wrote:
> Hi Nikos,
> thanks for your reply.
> So i think i will test the things (and do some test-implementations) you
> said in the near future. Any tipps to program the hook thing? Is the use of
> function-pointers a good solution to implement this? (maybe i can also
> imspire myself of your hook implementation)

I think function pointers seem like the simplest solution.

> Another question to do the implementation tests:
> I use the gnutls windows-version in Dev-C++ using mingw. Does a little
> tutorial exists where the compiling of the gnutls-sourcecode for windows is
> explained?

Compiling gnutls in windows is something unknown to me. I
cross-compile gnutls using mingw64 in a Debian system (see the
cross.mk makefile).

However, I'd suggest to use the Orwell dev-cpp (the original has been
quite inactive for many years). I had released some devpaks for orwell
dev-cpp but they are pretty old right now. You can generate them (in a
Linux system) from the gnutls repository using cross.mk as well (and
the devpak rule).

[0]. http://orwelldevcpp.blogspot.be/
[1]. ftp://ftp.gnu.org/gnu/gnutls/w32/

regards,
Nikos


From hfusa at web.de  Mon Jul 22 10:51:33 2013
From: hfusa at web.de (Horst Freiburger)
Date: Mon, 22 Jul 2013 10:51:33 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <CAJU7zaLStg5ew0XDvxY7+z7O9LUDrgpaFu1MM7PAQ=6R7x=MWQ@mail.gmail.com>
References: <CAJU7zaLStg5ew0XDvxY7+z7O9LUDrgpaFu1MM7PAQ=6R7x=MWQ@mail.gmail.com>
Message-ID: <51ECF295.4000207@web.de>

Hi Nikos,

so i will use function pointers.

My compiling skills under Linux are very very basic. My cross-compiling 
skills under Linux doesn't exists. Does a step by step manual exists. I 
now have a freshly installed debian-linux and i just run
sudo aptitude install git
to clone the sources to my pc with
git clone git://gitorious.org/gnutls/gnutls.git

How should i run cross.mk now? Do i need additional tools to to this?

regards
Horst




From hfusa at web.de  Mon Jul 22 11:07:55 2013
From: hfusa at web.de (Horst Freiburger)
Date: Mon, 22 Jul 2013 11:07:55 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51ECF295.4000207@web.de>
References: <51ECF295.4000207@web.de>
Message-ID: <51ECF66B.1070807@web.de>

Sorry!

I just found the README-alpha where the tools are listed!

regards
Horst


From hfusa at web.de  Mon Jul 22 12:02:55 2013
From: hfusa at web.de (Horst Freiburger)
Date: Mon, 22 Jul 2013 12:02:55 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51ECF66B.1070807@web.de>
References: <51ECF66B.1070807@web.de>
Message-ID: <51ED034F.7030904@web.de>

Hi Nikos!

Another question for cross-compiling gnutls for windows.

I read http://gitorious.org/gnutls/gnutls/blobs/master/README-alpha and 
i installed all the tools for my fresh debian installation.

Then i run
$ git clone git://gitorious.org/gnutls/gnutls.git
and i get a clone of the sources on my harddisc. I changed into the 
gnutls-directory and run
$ make bootstrap

The process started and was aborted with the failure:
configure.ac:203: possibly undefined macro: AC_LIBTOOL_WIN32_DLL

What should i do now?

Does a little tutorial for cross-compiling gnutls exists? I am not 
really sure what i should do after "make bootstrap" (if i get this 
working). I think "make" will only build the linux version. Am i right?!?

regard
Horst


From nmav at gnutls.org  Mon Jul 22 22:56:24 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 22 Jul 2013 22:56:24 +0200
Subject: [gnutls-help] openldap+gnutls - unable to get TLS client DN
In-Reply-To: <51E92EF9.4000901@crdp.ac-versailles.fr>
References: <51E92EF9.4000901@crdp.ac-versailles.fr>
Message-ID: <CAJU7zaJOfaJOPFSjaM+X5Hee7-P_0M_pSU399OTb7x3i1kwOvw@mail.gmail.com>

On Fri, Jul 19, 2013 at 2:20 PM, Pascal Fautrero
<pascal.fautrero at crdp.ac-versailles.fr> wrote:
> Hi,
> I try to understand a situation encountered by several openldap users on the
> net. I use openldap package built for debian (compiled with gnutls, that's
> why I submit this post).
> When a consumer openldap tries to connect to a provider openldap using TLS,
> the provider displays the following message :
> "unable to get TLS client DN"
> Connection is ok if we set (on the server) TLSVerifyClient to never or
> allow. But just for fun, I wan't to manage with such a message. And I must
> admit it is quite difficult to understand for me. Help or hints would be
> appreciated :)

As far as I understand from your description the client never sent a
certificate even if you have configured it to send one. Is that
correct?

> On the client side, If I look at _gnutls_handshake_client, during the same
> handshake, only STATE0 is executed. More, gnutls_handshake function is
> executed only once. STATE7, responsible of sending client certificate is
> never executed. Is it a normal situation to see a TLS handshake with so few
> STATE executed ? STATE2 and STATE3 shouldn't be catched ?

So I assume that there is a certificate configured. In that case is
the authority of the certificate trusted by the server? In TLS, the
server sends to the client its trusted authorities and the client
replies with a certificate from that list. If its certificate is not
from this trusted list gnutls will not send any (different versions
may have different behavior - which one do you try with?). You can
check the actual conversation using wireshark, and see in the server's
certificate request message the list of trusted authorities. If you
see no certificate request message from the server, it means that the
server is configured not to request a certificate from the client.

regards,
Nikos


From pascal.fautrero at crdp.ac-versailles.fr  Mon Jul 22 23:27:18 2013
From: pascal.fautrero at crdp.ac-versailles.fr (pascal Fautrero)
Date: Mon, 22 Jul 2013 23:27:18 +0200 (CEST)
Subject: [gnutls-help] openldap+gnutls - unable to get TLS client DN
In-Reply-To: <CAJU7zaJOfaJOPFSjaM+X5Hee7-P_0M_pSU399OTb7x3i1kwOvw@mail.gmail.com>
Message-ID: <1921729972.21388.1374528438510.JavaMail.root@zimbra>

Hi,

yes, you are right, it was my fault. My client certificate (self-signed) was not included in the list of trusted CA in the master... 

----- Mail original -----
> 
> As far as I understand from your description the client never sent a
> certificate even if you have configured it to send one. Is that
> correct?
> 
> > On the client side, If I look at _gnutls_handshake_client, during
> > the same
> > handshake, only STATE0 is executed. More, gnutls_handshake function
> > is
> > executed only once. STATE7, responsible of sending client
> > certificate is
> > never executed. Is it a normal situation to see a TLS handshake with
> > so few
> > STATE executed ? STATE2 and STATE3 shouldn't be catched ?
> 
> So I assume that there is a certificate configured. In that case is
> the authority of the certificate trusted by the server? In TLS, the
> server sends to the client its trusted authorities and the client
> replies with a certificate from that list. If its certificate is not
> from this trusted list gnutls will not send any (different versions
> may have different behavior - which one do you try with?).

ok, that's it ! I just have re-re-read the gnutls doc and it is clearly written !


Thank you very much :)

Regards,


 You can
> check the actual conversation using wireshark, and see in the server's
> certificate request message the list of trusted authorities. If you
> see no certificate request message from the server, it means that the
> server is configured not to request a certificate from the client.
> 
> regards,
> Nikos

-- 
Pascal Fautrero 
DTIC - Mission TICE 
CRDP de Versailles - 2 rue Pierre Bourdan - 78160 Marly-le-Roi 
http://www.crdp.ac-versailles.fr/ 


From nmav at gnutls.org  Tue Jul 23 19:38:29 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 23 Jul 2013 19:38:29 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51ED034F.7030904@web.de>
References: <51ECF66B.1070807@web.de> <51ED034F.7030904@web.de>
Message-ID: <51EEBF95.703@gnutls.org>

On 07/22/2013 12:02 PM, Horst Freiburger wrote:
> Hi Nikos!
> 
> Another question for cross-compiling gnutls for windows.
> 
> I read http://gitorious.org/gnutls/gnutls/blobs/master/README-alpha and
> i installed all the tools for my fresh debian installation.
> 
> Then i run
> $ git clone git://gitorious.org/gnutls/gnutls.git
> and i get a clone of the sources on my harddisc. I changed into the
> gnutls-directory and run
> $ make bootstrap
> 
> The process started and was aborted with the failure:
> configure.ac:203: possibly undefined macro: AC_LIBTOOL_WIN32_DLL

That's pretty awkward. Which version of libtool do you have installed?

> Does a little tutorial for cross-compiling gnutls exists? I am not
> really sure what i should do after "make bootstrap" (if i get this
> working). I think "make" will only build the linux version. Am i right?!?

The simple way is to do within the gnutls directory,
$ mkdir win32
$ cd win32
$ ln -s ../cross.mk Makefile
$ make gnutls-w32

By adjusting cross.mk you'll be able to chose between different versions
of the library, but you'll not be able to compile the git repository.

If you want to compile the git repository you should do something
similar to:
$ ./configure --host=i686-w64-mingw32 --enable-shared --disable-static
--enable-local-libopts --with-libnettle-prefix=/path/to/nettle-lib
--disable-libdane --disable-openssl-compatibility --with-included-libtasn1
$ make

regards,
Nikos



From naresh.sunkara at gmail.com  Wed Jul 24 06:50:59 2013
From: naresh.sunkara at gmail.com (Naresh Sunkara)
Date: Wed, 24 Jul 2013 10:20:59 +0530
Subject: [gnutls-help] DTSL ASYNC Operation
Message-ID: <CAL1gqHH0ZcTzZusq=r8tM1b=F_p1swm9qKioa8E5J=N4BENrMg@mail.gmail.com>

I am exploring using GNUTLS for CAPWAP implemention using DTLS. The place
where I got struck was the following,

in DTSL code, GNUTLS calls pull_timeout_func. It assumes to be a
synchronous call from the library. I want to multiplex multiple session in
a single event loop using libev. With the current implementaiton of GNUTLS,
do you have any ideas, by which I can handle this situation.

For eg.

1. Assume I have 10 FDs, with Different Sessions.
2. One of them enters a handshake phase.
3. Deep in GNUTLS, we migth call pull_timeout_func
4. At that point, I am already in the select loop of the outer application.
I am forced to sleep inside a select loop.

Is there a way around it. ?


-- 
-thanks
Naresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130724/8dc29ad3/attachment.html>

From nmav at gnutls.org  Thu Jul 25 12:12:16 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 25 Jul 2013 12:12:16 +0200
Subject: [gnutls-help] DTSL ASYNC Operation
In-Reply-To: <CAL1gqHH0ZcTzZusq=r8tM1b=F_p1swm9qKioa8E5J=N4BENrMg@mail.gmail.com>
References: <CAL1gqHH0ZcTzZusq=r8tM1b=F_p1swm9qKioa8E5J=N4BENrMg@mail.gmail.com>
Message-ID: <51F0FA00.7030301@gnutls.org>

On 07/24/2013 06:50 AM, Naresh Sunkara wrote:
> I am exploring using GNUTLS for CAPWAP implemention using DTLS. The place
> where I got struck was the following,
> 
> in DTSL code, GNUTLS calls pull_timeout_func. It assumes to be a
> synchronous call from the library. I want to multiplex multiple session in
> a single event loop using libev. With the current implementaiton of GNUTLS,
> do you have any ideas, by which I can handle this situation.

Hello Naresh,
 GnuTLS can operate asynchronously if you tell it so. There is the
GNUTLS_NONBLOCK flag that can be set in gnutls_init(). You can see some
discussion in:
http://gnutls.org/manual/html_node/Asynchronous-operation.html#Asynchronous-operation

In those cases the pull_timeout_func() will be called with a timeout
value of 0.

regards,
Nikos



From hfusa at web.de  Fri Jul 26 15:09:51 2013
From: hfusa at web.de (Horst Freiburger)
Date: Fri, 26 Jul 2013 15:09:51 +0200
Subject: [gnutls-help] Using GnuTLS with an HSM
In-Reply-To: <51EEBF95.703@gnutls.org>
References: <51EEBF95.703@gnutls.org>
Message-ID: <51F2751F.8070607@web.de>

Hi Nikos!

Thanks for your answer. I have to apologize. The next two weeks i have 
no chance to work on that topic. But after this two weeks i will 
concentrate my work to solve this problem. I now have an overview about 
the GnuTLS-sourcecode and i also have an idea how to implement my 
extensions to GnuTLS. The compiling-problem is not solved yet, but i 
haven't tried it a secound time so far.  In two weeks i will try tips.

I will answer on this thread if i have new problems. Thanks a lot for 
your help so far! I will also post my results.

See you in two weeks and thank you for everything!

regards,
Horst
^


From nmav at gnutls.org  Mon Jul 29 00:35:38 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 29 Jul 2013 00:35:38 +0200
Subject: [gnutls-help] gnutls 3.2.3pre0
Message-ID: <51F59CBA.50506@gnutls.org>

Hello,
 This is a pre-release of 3.2.3. This should fix all known issues
introduced by 3.2.2. If there are no reported issues in this prerelease
I'll rename the released files to 3.2.3.

* Version 3.2.3pre0 (released 2013-07-28)

** libgnutls: Fixes in parsing of priority strings. Patch by Stefan Buehler.

** libgnutls: Solve issue with received TLS packets that exceed 2^14.
(this fixes a bug that was accidentally introduced in 3.2.2)

** libgnutls: Removed gnulib modules under LGPLv3 that could possibly be
used by the library.

** API and ABI modifications:
gnutls_priority_kx_list: Added
gnutls_priority_mac_list: Added
gnutls_priority_cipher_list: Added


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

The pre-releases can be downloaded from:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/

regards,
Nikos


From nmav at gnutls.org  Tue Jul 30 08:52:14 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 30 Jul 2013 08:52:14 +0200
Subject: [gnutls-help] gnutls 3.2.3
Message-ID: <51F7629E.9060006@gnutls.org>

Hello,
 I've just released gnutls 3.2.3. This is a bug-fix release on
the current stable branch.

* Version 3.2.3 (released 2013-07-30)

** libgnutls: Fixes in parsing of priority strings. Patch by Stefan
Buehler.

** libgnutls: Solve issue with received TLS packets that exceed 2^14.
(this fixes a bug that was accidentally introduced in 3.2.2)

** libgnutls: Removed gnulib modules under LGPLv3 that could possibly be
used by the library.

** libgnutls: Fixes in gnutls_record_send_range(). Report and initial
fix by Alfredo Pironti.

** API and ABI modifications:
gnutls_priority_kx_list: Added
gnutls_priority_mac_list: Added
gnutls_priority_cipher_list: Added


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.3.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.3.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.3.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.3.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos