From nmav at gnutls.org  Mon Mar  3 07:21:25 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Mar 2014 07:21:25 +0100
Subject: [gnutls-help] gnutls 3.1.22
Message-ID: <53141F65.2090204@gnutls.org>

Hello,
 I've just released gnutls 3.1.22. This is an important bug-fix release
on the previous stable branch which addresses GNUTLS-SA-2014-2
http://www.gnutls.org/security.html#GNUTLS-SA-2014-2


* Version 3.1.22 (released 2014-03-03)

** libgnutls: Corrected certificate verification issue (GNUTLS-SA-2014-2)

** libgnutls: Corrected issue in gnutls_pcert_list_import_x509_raw
when provided with invalid data. Reported by Dmitriy Anisimkov.

** libgnutls: Corrected timeout issue in subsequent to the first
DTLS handshakes.

** libgnutls: Removed unconditional not-trusted message in
gnutls_certificate_verification_status_print() when used with
OpenPGP certificates. Reported by Michel Briand.

** libgnutls: All ciphersuites that were available in TLS1.0 or
later are now made available in SSL3.0 or later to prevent
any incompatibilities with servers that negotiate them in SSL 3.0.

** 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.22.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.22.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.22.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.22.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  Mon Mar  3 07:22:41 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Mar 2014 07:22:41 +0100
Subject: [gnutls-help] gnutls 3.2.12 / GNUTLS-SA-2014-2
Message-ID: <53141FB1.3040809@gnutls.org>

Hello,
 I've just released gnutls 3.2.12. This is an important bug-fix release
on the current stable branch which addresses GNUTLS-SA-2014-2
http://www.gnutls.org/security.html#GNUTLS-SA-2014-2

This fixes is an important (and at the same time embarrassing) bug
discovered during an audit for Red Hat. Everyone is urged to upgrade.
The git branches of older releases (e.g., 2.12.x), were also updated
with patches to the issue as they are also vulnerable. I'll provide more
information on the issue the next few days.


* Version 3.2.12 (released 2014-03-03)

** libgnutls: Corrected certificate verification issue (GNUTLS-SA-2014-2)

** libgnutls: Corrected issue in gnutls_pcert_list_import_x509_raw
when provided with invalid data. Reported by Dmitriy Anisimkov.

** libgnutls: Corrected timeout issue in subsequent to the first
DTLS handshakes.

** libgnutls: Removed unconditional not-trusted message in
gnutls_certificate_verification_status_print() when used with
OpenPGP certificates. Reported by Michel Briand.

** libgnutls: All ciphersuites that were available in TLS1.0 or
later are now made available in SSL3.0 or later to prevent
any incompatibilities with servers that negotiate them in SSL 3.0.

** ocsptool: When verifying a response and a signer isn't provided
assume that the signer is the issuer.

** ocsptool: When sending a nonce, verify that the nonce exists
in the OCSP response.

** gnutls-cli: Added --strict-tofu option; contributed by Jens
Lechtenboerger.

** 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.2/gnutls-3.2.12.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.12.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.12.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.12.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 fpolan at rogers.com  Mon Mar  3 19:29:25 2014
From: fpolan at rogers.com (Frank J Polan)
Date: Mon, 3 Mar 2014 13:29:25 -0500
Subject: [gnutls-help] Ubuntu 12.04lts Apache 2.4 mod_gnutls.so
Message-ID: <00c101cf370e$81be5cc0$853b1640$@com>

This is my first posting to this list. If I'm doing anything wrong or
breaking any rules please let me know
The following describes the problem ( as I posted to another forum)

Ubuntu 12.04LTS Apache 2.4 I've installed TLS be following the steps on this
link https://help.ubuntu.com/community/GnuTLS
When restarting Apache I get the following error
apache2: Syntax error on line 212 of /etc/apache2/apache2.conf: Syntax error
on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load
/usr/lib/apache2/modules/mod_gnutls.so into server:
/usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: unixd_config

If I remove the @gnutls.conf file from the /etc/apache2/mods-enabled
directory Apache restarts
Any suggestions would be appreciated
Thanks
Frank

It's been suggested that the GnuTLS package in 12.04LTS hasn't been updated
for apache 2.4 If that's the case is there a repository with an updated
version or should I revert to apache2.2 

Any advice would be appreciated

Thanks

Frank Polan




From dkg at fifthhorseman.net  Tue Mar  4 11:35:14 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 04 Mar 2014 10:35:14 +0000
Subject: [gnutls-help] Ubuntu 12.04lts Apache 2.4 mod_gnutls.so
In-Reply-To: <00c101cf370e$81be5cc0$853b1640$@com>
References: <00c101cf370e$81be5cc0$853b1640$@com>
Message-ID: <5315AC62.2020602@fifthhorseman.net>

Hi Frank--

On 03/03/2014 06:29 PM, Frank J Polan wrote:
> This is my first posting to this list. If I'm doing anything wrong or
> breaking any rules please let me know
> The following describes the problem ( as I posted to another forum)
> 
> Ubuntu 12.04LTS Apache 2.4 I've installed TLS be following the steps on this
> link https://help.ubuntu.com/community/GnuTLS
> When restarting Apache I get the following error
> apache2: Syntax error on line 212 of /etc/apache2/apache2.conf: Syntax error
> on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load
> /usr/lib/apache2/modules/mod_gnutls.so into server:
> /usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: unixd_config
> 
> If I remove the @gnutls.conf file from the /etc/apache2/mods-enabled
> directory Apache restarts
> Any suggestions would be appreciated
> Thanks
> Frank
> 
> It's been suggested that the GnuTLS package in 12.04LTS hasn't been updated
> for apache 2.4 If that's the case is there a repository with an updated
> version or should I revert to apache2.2 

it sounds like you're running into a problem with apache mod_gnutls,
which is a distinct project from gnutls itself -- mod_gnutls is a
project to connect Apache (the web server) with the GnuTLS transport
layer security library.

The right place to follow up on this is probably either the mod_gnutls
mailing list (i'm cc'ing it here):

  mod_gnutls-devel at lists.gnutls.org

or on ubuntu's packaging bug reports on https://launchpad.net/

fwiw, the mod_gnutls packaging for ubuntu should have caught this error
message during the test suite.

however, looking at http://packages.ubuntu.com/search?keywords=apache2,
i don't think that ubuntu 12.04 LTS actually has apache 2.4 at all (i
think it shipped with apache 2.2), so i'm not sure what is going on with
your system.

Did you compile these tools yourself?  if so, what versions are you
working with?

Regards,

	--dkg

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

From fpolan at rogers.com  Tue Mar  4 15:30:29 2014
From: fpolan at rogers.com (Frank J Polan)
Date: Tue, 4 Mar 2014 09:30:29 -0500
Subject: [gnutls-help] Ubuntu 12.04lts Apache 2.4 mod_gnutls.so
In-Reply-To: <5315AC62.2020602@fifthhorseman.net>
References: <00c101cf370e$81be5cc0$853b1640$@com>
 <5315AC62.2020602@fifthhorseman.net>
Message-ID: <00d001cf37b6$4b5ee700$e21cb500$@com>

Daniel

Thanks for the excellent explanation. You're correct 12.04lts doesn't have apache2.4; I downloaded it from a different repository. I'll uninstall it and revert back to 2.2 until it's an official Ubuntu release

Thanks

Frank Polan


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: March-04-2014 05:35
To: Frank J Polan; gnutls-help at lists.gnutls.org; mod_gnutls-devel at lists.gnutls.org
Subject: Re: [gnutls-help] Ubuntu 12.04lts Apache 2.4 mod_gnutls.so

Hi Frank--

On 03/03/2014 06:29 PM, Frank J Polan wrote:
> This is my first posting to this list. If I'm doing anything wrong or 
> breaking any rules please let me know The following describes the 
> problem ( as I posted to another forum)
> 
> Ubuntu 12.04LTS Apache 2.4 I've installed TLS be following the steps 
> on this link https://help.ubuntu.com/community/GnuTLS
> When restarting Apache I get the following error
> apache2: Syntax error on line 212 of /etc/apache2/apache2.conf: Syntax 
> error on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load 
> /usr/lib/apache2/modules/mod_gnutls.so into server:
> /usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: unixd_config
> 
> If I remove the @gnutls.conf file from the /etc/apache2/mods-enabled 
> directory Apache restarts Any suggestions would be appreciated Thanks 
> Frank
> 
> It's been suggested that the GnuTLS package in 12.04LTS hasn't been 
> updated for apache 2.4 If that's the case is there a repository with 
> an updated version or should I revert to apache2.2

it sounds like you're running into a problem with apache mod_gnutls, which is a distinct project from gnutls itself -- mod_gnutls is a project to connect Apache (the web server) with the GnuTLS transport layer security library.

The right place to follow up on this is probably either the mod_gnutls mailing list (i'm cc'ing it here):

  mod_gnutls-devel at lists.gnutls.org

or on ubuntu's packaging bug reports on https://launchpad.net/

fwiw, the mod_gnutls packaging for ubuntu should have caught this error message during the test suite.

however, looking at http://packages.ubuntu.com/search?keywords=apache2,
i don't think that ubuntu 12.04 LTS actually has apache 2.4 at all (i think it shipped with apache 2.2), so i'm not sure what is going on with your system.

Did you compile these tools yourself?  if so, what versions are you working with?

Regards,

	--dkg




From nmav at gnutls.org  Wed Mar  5 09:44:41 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 5 Mar 2014 09:44:41 +0100
Subject: [gnutls-help] gnutls 3.2.12 / GNUTLS-SA-2014-2
In-Reply-To: <53141FB1.3040809@gnutls.org>
References: <53141FB1.3040809@gnutls.org>
Message-ID: <CAJU7za+bh0CY0ta29SPqmZrVF_bNj_vj3WA5NOqJy8qH0gHJEg@mail.gmail.com>

On Mon, Mar 3, 2014 at 7:22 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> This fixes is an important (and at the same time embarrassing) bug
> discovered during an audit for Red Hat. Everyone is urged to upgrade.
> The git branches of older releases (e.g., 2.12.x), were also updated
> with patches to the issue as they are also vulnerable. I'll provide more
> information on the issue the next few days.

Hello,
 It seems that this bug got quite some publicity and I even started
receiving mail from random people. If anyone has any suggestions on
gnutls project workflow please post it here, and (more important)
volunteer to take up some work. Judging is easy, doing the actual work
isn't.

So here are few more words on the specific issue. The bug was
introduced around the 1.0.0 version, and went for quite long time
undetected, I believe for the following reason mainly:
1. This bug cannot be detected by any certificate validation tests;
prior to any release gnutls is tested against a certificate validation
path suite (developed to test X.509 path validation for USA's DoD),
but that couldn't help detect the issue. It didn't help with any of
the other issues that had been detected in the X.509 path validation
code of gnutls, so we have an additional suite developed in-house.
That didn't help with the issue either because it requires a specially
crafted certificate (and I'm not revealing more details on that yet).
2. This bug can only be detected by code audit, which doesn't happen
often (it's not a fun thing to do).
3. As this code was on a critical part of the library it was touched
and thus read, very rarely. Moreover, the code in question followed
the usual form of error checking in the library 'if(err<0) return
err', making it look correct, unless one would notice that the
function returned a boolean value (and we have very few such functions
in the library).

Of course the bug was introduced by me and I am fully responsible for it.
That's my last mail on the topic. Shit happens; we flush and go on.

regards,
Nikos


From nmav at gnutls.org  Fri Mar  7 08:50:21 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 07 Mar 2014 08:50:21 +0100
Subject: [gnutls-help] auditing gnutls
Message-ID: <1394178621.4157.55.camel@nomad.lan>

Hello,
 It seems there are more eyes looking at gnutls now, so to make things
easier, here is a list of the parts of gnutls (and also libtasn1) that
are exposed to network/untrusted data and have more need for auditing.

If you are able to audit the code please check the master branch (see
instructions at http://www.gnutls.org/devel.html ), and in case you are
able to successfully audit one of the following paths, please edit
the files reviewed and add a header under the author:
'Reviewed-By: Your Name (date)'
or 'Reviewed X.509 certificate verfication: Your name (date)'

Then make a patch with any changes you see fit (e.g. fixes or
simplifications of complex code) and send it to this list (preferably)
or to me directly.

If you cannot audit, but you know others that want and can, please
forward that mail to them. The reward for significant flaw finders is
eternal fame, and a @gnutls.org email address.

Note that there are people that have requested access to the coverity
gnutls logs. These are for a very old gnutls version and they don't
reveal anything that isn't also visible by clang's scan-build.


*********
The list:
*********

1. X.509 certificate verification starting from
gnutls_certificate_verify_peers3() - gnutls_cert.c
(may require PKIX details from RFC5280)

2. X.509 certificate verification starting from
gnutls_x509_trust_list_verify_crt() - x509/verify-high.c

3. X.509 certificate verification starting from
gnutls_x509_trust_list_verify_named_crt() - x509/verify-high.c

4. TOFU certificate verification starting from
gnutls_verify_stored_pubkey() - verify-tofu.c

5. TLS record parsing starting from gnutls_record_recv() to
gnutls_decrypt() - gnutls_record.c / gnutls_cipher.c
(may require TLS record details from RFC2246)

6. TLS handshake for RSA key exchange - gnutls_handshake() from
gnutls_handshake.c and auth/rsa.c.
(may require TLS details from rfc5246)

7. TLS handshake for DHE-RSA key exchange - gnutls_handshake() from
gnutls_handshake.c and auth/dhe.c.
(may require TLS details from rfc5246)

8. TLS handshake for ECDHE-ECDSA key exchange - gnutls_handshake() from
gnutls_handshake.c and auth/ecdhe.c.
(may require TLS details from rfc4492)

9 TLS handshake as a state machine starting from gnutls_handshake in
gnutls_handshake.c.

10. Random generator starting from gnutls_rnd() / random.c, and
nettle/rnd.c. This generator should work on multi-threaded systems and
after fork.

11. X.509 certificate parsing at x509/x509.c.
(may require PKIX details from RFC5280)

12. (X.509 certificate) DER decoding at libtasn1's asn1_der_decoding.
Check code from the upstream repository at:
https://www.gnu.org/software/libtasn1/
(that's a task for the brave)

regards,
Nikos




From fred.maison at gmail.com  Fri Mar  7 08:54:07 2014
From: fred.maison at gmail.com (Fred)
Date: Fri, 7 Mar 2014 08:54:07 +0100
Subject: [gnutls-help] Multi value extensions issue
Message-ID: <CAH6uPSv_1i7Y8oyintgtYkGvTZb6kGPXb1ypMZXgOouS17LXGA@mail.gmail.com>

Hi all,
It seems certtool does not correctly handles some multi-value extensions :
for example, I have 2 revocation url in my certificates, which hare
correctly handeled under OpenSSL, but only the first one is present in
certs signed by certtool.

Is this a thown issue ?
Is there any workaround or any way to fix it ?
certtool -v
certtool 3.0.28
Copyright (C) 2000-2012 Free Software Foundation, all rights reserved.
This is free software. It is licensed for use, modification and
redistribution under the terms of the
GNU General Public License, version 3 or later
    <http://gnu.org/licenses/gpl.html>


please send bug reports to:  bug-gnutls at gnu.org


From mrobinson7627 at gmail.com  Sat Mar  1 00:59:57 2014
From: mrobinson7627 at gmail.com (Matt Robinson)
Date: Fri, 28 Feb 2014 18:59:57 -0500
Subject: [gnutls-help] No such file or directory on handshake?
Message-ID: <CABBBz8V-4ZWn=_BsAB2SiDdnoNCH3R9qmRHxAWfYx6yiFO7SZw@mail.gmail.com>

I'm trying to do a simple TLS handshake, and I get a "No such file or
directory" error when attempting to do so. I ran strace on my code, and
this was the output:

open("/etc/gnutls/pkcs11.conf", O_RDONLY) = -1 ENOENT (No such file or
directory)

I'm wondering what that file is, and what I can do to fix it. Here's the
rest of my code, in case there's something wrong with it.

#include <stdio.h>#include <stdlib.h>#include <strings.h>#include
<sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include
<netdb.h>#include <gnutls/gnutls.h>
void error(char* msg) {
    perror(msg);
    exit(1);}
int main(){
    int sockfd;
    int portno = 64738;
    struct sockaddr_in serv_addr;
    struct hostent* server;

    //set up socket
    server = gethostbyname("localhost");
    bzero(&serv_addr, sizeof(serv_addr));
    serv_addr.sin_family = AF_INET;
    bcopy(server->h_addr,
          &serv_addr.sin_addr.s_addr,
          server->h_length);
    serv_addr.sin_port = htons(portno);
    if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
        error("Couldn't create socket");
    if (connect(sockfd, &serv_addr, sizeof(serv_addr)) < 0 )
        error("Connection error");

    //global init
    if (gnutls_global_init() < 0)
        error("Could not globally initialize TLS");

    //session init
    gnutls_session_t* session = malloc(sizeof(gnutls_session_t));
    if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
        error("Could not initialize TLS session");

    //Should eventually use certs, but I don't know how right now
    //gnutls_certificate_credentials_t cert_cred =
malloc(sizeof(gnutls_certificate_credentials_t));
    //if (gnutls_credentials_set(*session, GNUTLS_CRD_CERTIFICATE,
cert_cred) != GNUTLS_E_SUCCESS)
    //
    //For now do it anonymously
    gnutls_anon_client_credentials_t* anon_cred =
malloc(sizeof(gnutls_anon_client_credentials_t));
    if (gnutls_credentials_set(*session, GNUTLS_CRD_ANON, anon_cred)
!= GNUTLS_E_SUCCESS)
        error("Could not set credentials");
    if (gnutls_anon_allocate_client_credentials(anon_cred) != GNUTLS_E_SUCCESS)
        error("Could not allocate credentials");

    //set up socket for tls
    gnutls_transport_set_int(*session, sockfd);

    //do the handshake
    if (gnutls_handshake(*session) != GNUTLS_E_SUCCESS)
        error("TLS handshake failed");

    //deinit
    gnutls_global_deinit();
    printf("Success\n");
    return 0;}


Sorry if I'm not supposed to post code likethis in the middle of an
email, I don't exactly know the protocol for something like this.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140228/f70393c1/attachment.html>

From nmav at gnutls.org  Sat Mar  8 09:54:10 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Mar 2014 09:54:10 +0100
Subject: [gnutls-help] Multi value extensions issue
In-Reply-To: <CAH6uPSv_1i7Y8oyintgtYkGvTZb6kGPXb1ypMZXgOouS17LXGA@mail.gmail.com>
References: <CAH6uPSv_1i7Y8oyintgtYkGvTZb6kGPXb1ypMZXgOouS17LXGA@mail.gmail.com>
Message-ID: <1394268850.4172.3.camel@nomad.lan>

On Fri, 2014-03-07 at 08:54 +0100, Fred wrote:
> Hi all,
> It seems certtool does not correctly handles some multi-value extensions :
> for example, I have 2 revocation url in my certificates, which hare
> correctly handeled under OpenSSL, but only the first one is present in
> certs signed by certtool.

Hello,
 That's a limitation of the tool. It currently handles only a single CRL
distribution point.

regards,
Nikos




From jens.lechtenboerger at fsfe.org  Sat Mar  8 22:41:41 2014
From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger)
Date: Sat, 08 Mar 2014 22:41:41 +0100
Subject: [gnutls-help] gnutls-cli DHE preferences
Message-ID: <86eh2c8j1m.fsf@informationelle-selbstbestimmung-im-internet.de>

Hi there,

I just realized that gnutls-cli (3.2.12.1) prefers 
cipher suites without DHE over those with DHE, e.g.:
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) is preferred to
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033).

I was hoping for forward secrecy with Diffie-Hellman by default,
which I now must enable explicitly with option --priority=PFS.

Is there a reason for this preference?

Best wishes
Jens


From nmav at gnutls.org  Sun Mar  9 20:16:49 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 09 Mar 2014 20:16:49 +0100
Subject: [gnutls-help] gnutls-cli DHE preferences
In-Reply-To: <86eh2c8j1m.fsf@informationelle-selbstbestimmung-im-internet.de>
References: <86eh2c8j1m.fsf@informationelle-selbstbestimmung-im-internet.de>
Message-ID: <1394392609.12679.14.camel@nomad.lan>

On Sat, 2014-03-08 at 22:41 +0100, Jens Lechtenboerger wrote:
> Hi there,
> 
> I just realized that gnutls-cli (3.2.12.1) prefers 
> cipher suites without DHE over those with DHE, e.g.:
> TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) is preferred to
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033).
> 
> I was hoping for forward secrecy with Diffie-Hellman by default,
> which I now must enable explicitly with option --priority=PFS.
> Is there a reason for this preference?

Yes. The problem with DHE ciphersuites is that they don't negotiate the
acceptable security level; thus when a client prioritizes DH and
receives unacceptable DH parameters can only terminate the session with
an error. This makes gnutls incompatible with these servers (there are
quite some misconfigured servers like that), so gnutls prioritizes by
default ECDHE, and RSA over DHE to promote compatibility.

regards,
Nikos




From mpg at polarssl.org  Tue Mar 11 11:16:15 2014
From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=)
Date: Tue, 11 Mar 2014 11:16:15 +0100
Subject: [gnutls-help] Ciphersuite minimal version inconsistency?
In-Reply-To: <5310D8C6.2090807@gnutls.org>
References: <5310AD63.8070308@polarssl.org> <5310D8C6.2090807@gnutls.org>
Message-ID: <531EE26F.1020101@polarssl.org>

Hi Nikos,

On 02/28/2014 07:43 PM, Nikos Mavrogiannopoulos wrote:
>  The RFCs you refer to don't mention SSL 3.0 at all, so my approach was
> to allow these algorithms for TLS 1.0 or later. Unfortunately openssl
> was negotiating these algorithms on SSL 3.0 as well, so I allowed some
> of them in SSL 3.0 as well. I asked the TLS WG at the time, and there
> was no real answer. Anyway maybe it makes sense to allow all the TLS 1.0
> ciphersuites in SSL 3.0 as well to prevent any incompatibilities.
> 
I see you allowed these suites in SSL 3.0 in the latest release. I agree that
it's not clear if there is a real answer here, but thanks for you reaction anyway.

Regards,
Manuel.


From mpg at polarssl.org  Tue Mar 11 11:23:28 2014
From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=)
Date: Tue, 11 Mar 2014 11:23:28 +0100
Subject: [gnutls-help] Some "missing" ciphersuites
In-Reply-To: <5310DB5C.70105@gnutls.org>
References: <5310AD6F.6050700@polarssl.org> <5310DB5C.70105@gnutls.org>
Message-ID: <531EE420.5000507@polarssl.org>

On 02/28/2014 07:54 PM, Nikos Mavrogiannopoulos wrote:
> On 02/28/2014 04:38 PM, Manuel P?gouri?-Gonnard wrote:
>> TLS_DHE_PSK_NULL_SHA1
>> TLS_DHE_PSK_RC4_128_SHA1
>> TLS_ECDHE_PSK_NULL_SHA1
>> TLS_ECDHE_PSK_RC4_128_SHA1
>> TLS_PSK_NULL_SHA1
>> TLS_RSA_PSK_RC4_128_SHA1
>> Is that an oversight, or is there a particular reason?
> 
> No particular reason. Probably it was an oversight and no-one asked for
> them. Do you think there is some good reason to add them?
> 
Honestly, I don't know if there is a good reason to add them. However, I have a
quite selfish reason for wishing they were added: I'm currently adding GnuTLS to
our interop test script in PolarSSL, and those are the few ciphersuites that we
support but can't test interop for at the moment (they are not in OpenSSL either).

Obviously, I won't be offended if you don't think it's a good enough reason to
add them :)

Regards,
Manuel.


From nmav at gnutls.org  Tue Mar 11 13:02:48 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Mar 2014 13:02:48 +0100
Subject: [gnutls-help] Ciphersuite minimal version inconsistency?
In-Reply-To: <531EE26F.1020101@polarssl.org>
References: <5310AD63.8070308@polarssl.org> <5310D8C6.2090807@gnutls.org>
 <531EE26F.1020101@polarssl.org>
Message-ID: <CAJU7zaJr9+a87e-dXx6WWQ19JuJLaUKxqUPU41q6cYUQDU4vPw@mail.gmail.com>

On Tue, Mar 11, 2014 at 11:16 AM, Manuel P?gouri?-Gonnard
<mpg at polarssl.org> wrote:
>>  The RFCs you refer to don't mention SSL 3.0 at all, so my approach was
>> to allow these algorithms for TLS 1.0 or later. Unfortunately openssl
>> was negotiating these algorithms on SSL 3.0 as well, so I allowed some
>> of them in SSL 3.0 as well. I asked the TLS WG at the time, and there
>> was no real answer. Anyway maybe it makes sense to allow all the TLS 1.0
>> ciphersuites in SSL 3.0 as well to prevent any incompatibilities.
> I see you allowed these suites in SSL 3.0 in the latest release. I agree that
> it's not clear if there is a real answer here, but thanks for you reaction anyway.

Hello,
 Actually I was wrong in allowing them. SSL 3.0 uses a special MAC
construction that isn't defined for SHA256 or better, and there is no
authority to extend that definition. I'll revert that choice on the
next bug fix release.

regards,
Nikos


From nmav at gnutls.org  Tue Mar 11 13:05:06 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 11 Mar 2014 13:05:06 +0100
Subject: [gnutls-help] Some "missing" ciphersuites
In-Reply-To: <531EE420.5000507@polarssl.org>
References: <5310AD6F.6050700@polarssl.org> <5310DB5C.70105@gnutls.org>
 <531EE420.5000507@polarssl.org>
Message-ID: <CAJU7za+t28b=LrLNJ=gqcYcefDQc3h5yoecC_zbQiSCidF1CWg@mail.gmail.com>

On Tue, Mar 11, 2014 at 11:23 AM, Manuel P?gouri?-Gonnard
<mpg at polarssl.org> wrote:
>> No particular reason. Probably it was an oversight and no-one asked for
>> them. Do you think there is some good reason to add them?
> Honestly, I don't know if there is a good reason to add them. However, I have a
> quite selfish reason for wishing they were added: I'm currently adding GnuTLS to
> our interop test script in PolarSSL, and those are the few ciphersuites that we
> support but can't test interop for at the moment (they are not in OpenSSL either).
> Obviously, I won't be offended if you don't think it's a good enough reason to
> add them :)

Would you be interested in contributing that interop test to gnutls?
We already have interop check with openssl (in
tests/suite/testcompat), and would be nice if there were checks with
other implementations as well.

regards,
Nikos


From mpg at polarssl.org  Wed Mar 12 13:26:59 2014
From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=)
Date: Wed, 12 Mar 2014 13:26:59 +0100
Subject: [gnutls-help] Some "missing" ciphersuites
In-Reply-To: <CAJU7za+t28b=LrLNJ=gqcYcefDQc3h5yoecC_zbQiSCidF1CWg@mail.gmail.com>
References: <5310AD6F.6050700@polarssl.org>	<5310DB5C.70105@gnutls.org>	<531EE420.5000507@polarssl.org>
 <CAJU7za+t28b=LrLNJ=gqcYcefDQc3h5yoecC_zbQiSCidF1CWg@mail.gmail.com>
Message-ID: <53205293.7050200@polarssl.org>

On 03/11/2014 01:05 PM, Nikos Mavrogiannopoulos wrote:
> On Tue, Mar 11, 2014 at 11:23 AM, Manuel P?gouri?-Gonnard
> <mpg at polarssl.org> wrote:
>> Honestly, I don't know if there is a good reason to add them. However, I have a
>> quite selfish reason for wishing they were added: I'm currently adding GnuTLS to
>> our interop test script in PolarSSL, and those are the few ciphersuites that we
>> support but can't test interop for at the moment (they are not in OpenSSL either).
>> Obviously, I won't be offended if you don't think it's a good enough reason to
>> add them :)
> 
> Would you be interested in contributing that interop test to gnutls?
> We already have interop check with openssl (in
> tests/suite/testcompat), and would be nice if there were checks with
> other implementations as well.
> 
I'm not done yet integrating GnuTLS in our script, but I'll let you know when
I'm done, so we can see if we can share something here.

Regards,
Manuel.



From mail at lechevalier.se  Thu Mar 13 00:17:37 2014
From: mail at lechevalier.se (A L)
Date: Thu, 13 Mar 2014 00:17:37 +0100
Subject: [gnutls-help] curve25519, UMAC, etc
Message-ID: <5320EB11.7050104@lechevalier.se>

Are there any plans to support curve25519 or any of the other non-NIST
curves for ECC/ECDH and are there plans to support Ed25519 signature?

Reference:
http://cr.yp.to/ecdh.html
http://ed25519.cr.yp.to
https://tools.ietf.org/html/draft-josefsson-tls-curve25519-04

~A


From nmav at gnutls.org  Fri Mar 14 08:34:09 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 14 Mar 2014 08:34:09 +0100
Subject: [gnutls-help] curve25519, UMAC, etc
In-Reply-To: <5320EB11.7050104@lechevalier.se>
References: <5320EB11.7050104@lechevalier.se>
Message-ID: <CAJU7zaJGLUGAsVA4hQbxKwBWAASLmcAnsMcFGN692M4tyAY=_Q@mail.gmail.com>

On Thu, Mar 13, 2014 at 12:17 AM, A L <mail at lechevalier.se> wrote:
> Are there any plans to support curve25519 or any of the other non-NIST
> curves for ECC/ECDH and are there plans to support Ed25519 signature?
> Reference:
> http://cr.yp.to/ecdh.html
> http://ed25519.cr.yp.to
> https://tools.ietf.org/html/draft-josefsson-tls-curve25519-04

The plan is to be added once it is standardized and implemented in
nettle.  Ed25519 signature scheme will not be added, as it is not
standardized in any way and there is no plan to make it so as far as I
know.

Implementing algorithms prior to standardization has the risk of
implementing an early variant of the algorithm that isn't in the final
standard (this is the case with gnutls implementing salsa20-umac,
which was replaced with chacha20-poly, and openssh with the
chacha20-poly implementation, which is based on an early draft that is
incompatible with the latest).

regards,
Nikos


From mail at lechevalier.se  Fri Mar 14 19:45:51 2014
From: mail at lechevalier.se (A L)
Date: Fri, 14 Mar 2014 19:45:51 +0100
Subject: [gnutls-help] curve25519, UMAC, etc
In-Reply-To: <CAJU7zaJGLUGAsVA4hQbxKwBWAASLmcAnsMcFGN692M4tyAY=_Q@mail.gmail.com>
References: <5320EB11.7050104@lechevalier.se>
 <CAJU7zaJGLUGAsVA4hQbxKwBWAASLmcAnsMcFGN692M4tyAY=_Q@mail.gmail.com>
Message-ID: <53234E5F.4050709@lechevalier.se>


On 2014-03-14 08:34, Nikos Mavrogiannopoulos wrote:
> On Thu, Mar 13, 2014 at 12:17 AM, A L <mail at lechevalier.se> wrote:
>> Are there any plans to support curve25519 or any of the other non-NIST
>> curves for ECC/ECDH and are there plans to support Ed25519 signature?
>> Reference:
>> http://cr.yp.to/ecdh.html
>> http://ed25519.cr.yp.to
>> https://tools.ietf.org/html/draft-josefsson-tls-curve25519-04
> The plan is to be added once it is standardized and implemented in
> nettle.  Ed25519 signature scheme will not be added, as it is not
> standardized in any way and there is no plan to make it so as far as I
> know.
>
> Implementing algorithms prior to standardization has the risk of
> implementing an early variant of the algorithm that isn't in the final
> standard (this is the case with gnutls implementing salsa20-umac,
> which was replaced with chacha20-poly, and openssh with the
> chacha20-poly implementation, which is based on an early draft that is
> incompatible with the latest).
>
> regards,
> Nikos

Understandably, there needs to be some standardization to avoid
interoperability and security issues. Do you know the status regarding
the draft? I.e. when could we expect it to be finalized enough to be
included?

Side note. I just saw that the OpenSSH-6.5 release does support Ed25519 ;)
http://www.openssh.org/txt/release-6.5

~A



From nmav at gnutls.org  Thu Mar 27 17:50:55 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 27 Mar 2014 17:50:55 +0100
Subject: [gnutls-help] gnutls 3.3.0pre0
Message-ID: <1395939055.28794.4.camel@nomad.lan>

Hello,
 I've just released gnutls 3.3.0pre0. This is a pre-release of the next
stable branch, which adds new features, optimizations and cleanups to
the GnuTLS library.


* Version 3.3.0 (pre-release 2014-03-27)

** libgnutls: The initialization of the library was moved to a
constructor. That is, gnutls_global_init() is no longer required
unless linking with a static library or a system that does not
support library constructors.

** libgnutls: static libraries are not built by default.

** libgnutls: PKCS #11 initialization is delayed to first usage.
That avoids long delays in gnutls initialization due to broken PKCS #11
modules.

** libgnutls: The PKCS #11 subsystem is re-initialized "automatically"
on the first PKCS #11 API call after a fork. 

** libgnutls: certificate verification profiles were introduced
that can be specified as flags to verification functions. They
are enumerations in gnutls_certificate_verification_profiles_t
and can be converted to flags using GNUTLS_PROFILE_TO_VFLAGS()

** libgnutls: Added the SYSTEM priority string initial keyword.
That allows a compile-time specified configuration file to be
used to read the priorities. That can be used to impose system
specific policies.

** libgnutls: Increased the default security level of priority
strings (NORMAL and PFS strings require at minimum a 1008 DH prime), 
and set a verification profile by default.  The LEGACY keyword is 
introduced to set the old defaults.

** libgnutls: Added support for the name constraints PKIX extension.
Currently only DNS names and e-mails are supported (no URIs, IPs
or DNs).

** libgnutls: Security parameter SEC_PARAM_NORMAL was renamed to 
SEC_PARAM_MEDIUM to avoid confusion with the priority string NORMAL.

** libgnutls: Added new API in x509-ext.h to handle X.509 extensions.
This API handles the X.509 extensions in isolation, allowing to parse
similarly formatted extensions stored in other structures.

** libgnutls: When generating DSA keys the macro GNUTLS_SUBGROUP_TO_BITS
can be used to specify a particular subgroup as the number of bits in
gnutls_privkey_generate; e.g., GNUTLS_SUBGROUP_TO_BITS(2048, 256).

** libgnutls: DH parameter generation is now delegated to nettle.
That unfortunately has the side-effect that DH parameters longer than
3072 bits, cannot be generated (not without a nettle update).

** libgnutls: Separated nonce RNG from the main RNG. The nonce
random number generator is based on salsa20/12.

** libgnutls: The buffer alignment provided to crypto backend is
enforced to be 16-byte aligned, when compiled with cryptodev
support. That allows certain cryptodev drivers to operate more
efficiently.

** libgnutls: Depend on p11-kit 0.20.0 or later.

** libgnutls: The new padding (%NEW_PADDING) experimental TLS extension
has been removed. It was not approved by IETF.

** libgnutls: The experimental xssl library is removed from the gnutls
distribution.

** libgnutls: Reduced the number of gnulib modules used.

** certtool: Timestamps for serial numbers were increased to 8 bytes,
and in batch mode to 12 (appended with 4 random bytes).

** libgnutls: Added --enable-fips140-mode configuration option
(unsupported).
That option enables (when running on FIPS140-enabled system):
 o RSA, DSA and DH key generation as in FIPS-186-4 (using provable
primes)
 o The DRBG-CTR-AES256 deterministic random generator from SP800-90A.
 o Self-tests on initialization on ciphers/MACs, public key algorithms 
   and the random generator.
 o HMAC-SHA256 verification of the library on load.
 o MD5 is included for TLS purposes but cannot be used by the high level
   hashing functions.
 o All ciphers except AES are disabled.
 o All MACs and hashes except GCM and SHA are disabled (e.g., HMAC-MD5).
 o All keys (temporal and long term) are zeroized after use.
 o Security levels are adjusted to the FIPS140-2 recommendations (rather
   than ECRYPT).

** API and ABI modifications:
gnutls_privkey_generate: Added
gnutls_pkcs11_crt_is_known: Added
gnutls_fips140_mode_enabled: Added
gnutls_sec_param_to_symmetric_bits: Added
gnutls_pubkey_export_ecc_x962: Added (replaces
gnutls_pubkey_get_pk_ecc_x962)
gnutls_pubkey_export_ecc_raw: Added (replaces
gnutls_pubkey_get_pk_ecc_raw)
gnutls_pubkey_export_dsa_raw: Added (replaces
gnutls_pubkey_get_pk_dsa_raw)
gnutls_pubkey_export_rsa_raw: Added (replaces
gnutls_pubkey_get_pk_rsa_raw)
gnutls_pubkey_verify_params: Added
gnutls_privkey_export_ecc_raw: Added
gnutls_privkey_export_dsa_raw: Added
gnutls_privkey_export_rsa_raw: Added
gnutls_privkey_import_ecc_raw: Added
gnutls_privkey_import_dsa_raw: Added
gnutls_privkey_import_rsa_raw: Added
gnutls_privkey_verify_params: Added
gnutls_x509_name_constraints_init: Added
gnutls_x509_name_constraints_deinit: Added
gnutls_x509_crt_get_name_constraints: Added
gnutls_x509_name_constraints_add_permitted: Added
gnutls_x509_name_constraints_add_excluded: Added
gnutls_x509_crt_set_name_constraints: Added
gnutls_x509_name_constraints_get_permitted: Added
gnutls_x509_name_constraints_get_excluded: Added
gnutls_x509_name_constraints_check: Added
gnutls_x509_name_constraints_check_crt: Added
gnutls_x509_crl_get_extension_data2: Added
gnutls_x509_crt_get_extension_data2: Added
gnutls_x509_crq_get_extension_data2: Added
gnutls_subject_alt_names_init: Added
gnutls_subject_alt_names_deinit: Added
gnutls_subject_alt_names_get: Added
gnutls_subject_alt_names_set: Added
gnutls_x509_ext_import_subject_alt_names: Added
gnutls_x509_ext_export_subject_alt_names: Added
gnutls_x509_crl_dist_points_init: Added
gnutls_x509_crl_dist_points_deinit: Added
gnutls_x509_crl_dist_points_get: Added
gnutls_x509_crl_dist_points_set: Added
gnutls_x509_ext_import_crl_dist_points: Added
gnutls_x509_ext_export_crl_dist_points: Added
gnutls_x509_ext_import_name_constraints: Added
gnutls_x509_ext_export_name_constraints: Added
gnutls_x509_aia_init: Added
gnutls_x509_aia_deinit: Added
gnutls_x509_aia_get: Added
gnutls_x509_aia_set: Added
gnutls_x509_ext_import_aia: Added
gnutls_x509_ext_export_aia: Added
gnutls_x509_ext_import_subject_key_id: Added
gnutls_x509_ext_export_subject_key_id: Added
gnutls_x509_ext_export_authority_key_id: Added
gnutls_x509_ext_import_authority_key_id: Added
gnutls_x509_aki_init: Added
gnutls_x509_aki_get_id: Added
gnutls_x509_aki_get_cert_issuer: Added
gnutls_x509_aki_set_id: Added
gnutls_x509_aki_set_cert_issuer: Added
gnutls_x509_aki_deinit: Added
gnutls_x509_ext_import_private_key_usage_period: Added
gnutls_x509_ext_export_private_key_usage_period: Added
gnutls_x509_ext_import_basic_constraints: Added
gnutls_x509_ext_export_basic_constraints: Added
gnutls_x509_ext_import_key_usage: Added
gnutls_x509_ext_export_key_usage: Added
gnutls_x509_ext_import_proxy: Added
gnutls_x509_ext_export_proxy: Added
gnutls_x509_policies_init: Added
gnutls_x509_policies_deinit: Added
gnutls_x509_policies_get: Added
gnutls_x509_policies_set: Added
gnutls_x509_ext_import_policies: Added
gnutls_x509_ext_export_policies: Added
gnutls_x509_key_purpose_init: Added
gnutls_x509_key_purpose_deinit: Added
gnutls_x509_key_purpose_set: Added
gnutls_x509_key_purpose_get: Added
gnutls_x509_ext_import_key_purposes: Added
gnutls_x509_ext_export_key_purposes: Added
gnutls_digest_self_test: Added (conditionally)
gnutls_mac_self_test: Added (conditionally)
gnutls_pk_self_test: Added (conditionally)
gnutls_cipher_self_test: Added (conditionally)
gnutls_global_set_mem_functions: Deprecated


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.3/gnutls-3.3.0pre0.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0pre0.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0pre0.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0pre0.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 swbrown at variadic.org  Fri Mar 28 08:42:16 2014
From: swbrown at variadic.org (Steven Brown)
Date: Fri, 28 Mar 2014 00:42:16 -0700
Subject: [gnutls-help] vectored gnutls_record_send for DTLS?
Message-ID: <533527D8.8070707@variadic.org>

Is there any way of doing vectored I/O for writes with gnutls?  There
seems to be a gnutls_transport_set_vec_push_function but no
corresponding gnutls_record_send_vec or similar.  This is an issue for
DTLS where I can't just do multiple writes as they'll end up in separate
packets and the alternative of rewriting each packet in memory is expensive.


From nmav at gnutls.org  Fri Mar 28 10:37:28 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Mar 2014 10:37:28 +0100
Subject: [gnutls-help] vectored gnutls_record_send for DTLS?
In-Reply-To: <533527D8.8070707@variadic.org>
References: <533527D8.8070707@variadic.org>
Message-ID: <CAJU7zaKTtTu1gsKp-w3JjkF5HSKbM0x2r7r0Z40epv_Ae5dKng@mail.gmail.com>

On Fri, Mar 28, 2014 at 8:42 AM, Steven Brown <swbrown at variadic.org> wrote:
> Is there any way of doing vectored I/O for writes with gnutls?  There
> seems to be a gnutls_transport_set_vec_push_function but no
> corresponding gnutls_record_send_vec or similar.  This is an issue for
> DTLS where I can't just do multiple writes as they'll end up in separate
> packets and the alternative of rewriting each packet in memory is expensive.

Hello,
 There is no vectored read and write yet, but you can simulate it use
gnutls_record_cork() and uncork().

However, as these were made for TLS, there is some care needed when
using them under DTLS (e.g., ensure you don't queue more data than the
value of gnutls_dtls_get_data_mtu()).

regards,
Nikos


From nmav at gnutls.org  Fri Mar 28 10:53:12 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Mar 2014 10:53:12 +0100
Subject: [gnutls-help] vectored gnutls_record_send for DTLS?
In-Reply-To: <CAJU7zaKTtTu1gsKp-w3JjkF5HSKbM0x2r7r0Z40epv_Ae5dKng@mail.gmail.com>
References: <533527D8.8070707@variadic.org>
 <CAJU7zaKTtTu1gsKp-w3JjkF5HSKbM0x2r7r0Z40epv_Ae5dKng@mail.gmail.com>
Message-ID: <CAJU7zaKy-KjrnCjnPhaYG-V-G9=m-i8UKKGKsQu+GU5NL8griA@mail.gmail.com>

On Fri, Mar 28, 2014 at 10:37 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> Hello,
>  There is no vectored read and write yet, but you can simulate it use
> gnutls_record_cork() and uncork().
> However, as these were made for TLS, there is some care needed when
> using them under DTLS (e.g., ensure you don't queue more data than the
> value of gnutls_dtls_get_data_mtu()).

I'm wrong here. Unfortunately gnutls_record_cork() is unsafe for use
with DTLS. That should be a thing to be fixed in 3.3.0.
Hence the only way available for DTLS and vectored data is to concatenate them.

regards,
Nikos


From kroosec at gmail.com  Fri Mar 28 10:18:00 2014
From: kroosec at gmail.com (Hani B)
Date: Fri, 28 Mar 2014 10:18:00 +0100
Subject: [gnutls-help] Setting DH params when only gnutls_session_t is
	available ?
Message-ID: <20140328091800.GA6485@Inspiron-3521>

Hi list,

I am trying to set the Diffie-Hellman parameters in a case where the library I
use (Libmicrohttpd) only exposes the gnutls_session_t value, but not the
gnutls_certificate_credentials_t value (to use with gnutls_certificate_set_dh_params().)

I am wondering if:
1. There is a way to set the DH parameters using the session ?
2. Is there a way to get the certificate_credentials_t record from the session,
and thus be able to set the DH parameters using it ?

Regards,


From dkg at fifthhorseman.net  Fri Mar 28 17:44:13 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 28 Mar 2014 12:44:13 -0400
Subject: [gnutls-help] Setting DH params when only gnutls_session_t is
 available ?
In-Reply-To: <20140328091800.GA6485@Inspiron-3521>
References: <20140328091800.GA6485@Inspiron-3521>
Message-ID: <5335A6DD.1060507@fifthhorseman.net>

On 03/28/2014 05:18 AM, Hani B wrote:
> I am trying to set the Diffie-Hellman parameters in a case where the library I
> use (Libmicrohttpd) only exposes the gnutls_session_t value, but not the
> gnutls_certificate_credentials_t value (to use with gnutls_certificate_set_dh_params().)

If the session isn't already underway, i think you want to create a new
gnutls_certificate_credentials_t, configure it as you like, and then use
gnutls_credentials_set() to associate the credentials with the session.

http://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fcredentials_005fset

If this doesn't work for you, can you give details about the particular
circumstances, or what you've tried and how it (mis)behaved?

hope this helps,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140328/3abd4670/attachment-0001.sig>

From kroosec at gmail.com  Sun Mar 30 00:14:06 2014
From: kroosec at gmail.com (Hani B)
Date: Sun, 30 Mar 2014 00:14:06 +0100
Subject: [gnutls-help] Setting DH params when only gnutls_session_t is
 available ?
In-Reply-To: <5335A6DD.1060507@fifthhorseman.net>
References: <20140328091800.GA6485@Inspiron-3521>
 <5335A6DD.1060507@fifthhorseman.net>
Message-ID: <20140329231350.GC7130@Inspiron-3521>


On Fri, Mar 28, 2014 at 12:44:13PM -0400, Daniel Kahn Gillmor wrote:
> On 03/28/2014 05:18 AM, Hani B wrote:
> > I am trying to set the Diffie-Hellman parameters in a case where the library I
> > use (Libmicrohttpd) only exposes the gnutls_session_t value, but not the
> > gnutls_certificate_credentials_t value (to use with gnutls_certificate_set_dh_params().)
> 
> If the session isn't already underway, i think you want to create a new
> gnutls_certificate_credentials_t, configure it as you like, and then use
> gnutls_credentials_set() to associate the credentials with the session.
> 
> http://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fcredentials_005fset
> 
> If this doesn't work for you, can you give details about the particular
> circumstances, or what you've tried and how it (mis)behaved?
> 
> hope this helps,
> 
> 	--dkg
> 

Thanks Daniel.

Apparently, earliest one can get access to the session pointer is at the
connection callback, at which point, the tls handshake has already happened
anyway.

Guess that all I have left is hacking a patch for libmicrohttpd.

Cheers,

Hani.