From nmav at gnutls.org  Wed Jan  2 19:57:52 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 02 Jan 2013 19:57:52 +0100
Subject: [gnutls-help] gnutls 3.1.6
Message-ID: <50E48330.7080408@gnutls.org>

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

* Version 3.1.6 (released 2012-01-02)

** libgnutls: Fixed record padding parsing issue. Reported by Kenny
Patterson and Nadhem Alfardan.

** libgnutls: Several updates in the ASN.1 string handling subsystem.

** libgnutls: gnutls_x509_crt_get_policy() allows for a list of zero
policy qualifiers.

** libgnutls: Ignore heartbeat messages when received out-of-order,
instead of issuing an error.

** libgnutls: Stricter RSA PKCS #1 1.5 encoding and decoding. Reported
by Kikuchi Masashi.

** libgnutls: TPM support is disabled by default because GPL programs
cannot link with it. Use --with-tpm to enable it.

** libgnutls-guile: Fixed parallel compilation issue.

** gnutls-cli: It will try to connect to all possible returned addresses
before failing.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.6.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.6.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  Thu Jan  3 19:14:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 03 Jan 2013 19:14:40 +0100
Subject: [gnutls-help] gnutls 3.0.27
Message-ID: <50E5CA90.4090801@gnutls.org>

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

* Version 3.0.27 (released 2013-01-03)

** libgnutls: Fixed record padding parsing issue. Reported by Kenny
Patterson and Nadhem Alfardan.

** libgnutls: Stricter RSA PKCS #1 1.5 encoding. Reported
by Kikuchi Masashi.

** libgnutls-guile: Fixed parallel compilation issue.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.27.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.27.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 nyc4bos at aol.com  Thu Jan  3 23:37:59 2013
From: nyc4bos at aol.com (nyc4bos at aol.com)
Date: Thu, 03 Jan 2013 21:37:59 -0100
Subject: [gnutls-help] gnutls 3.1.6
References: <50E48330.7080408@gnutls.org>
Message-ID: <xl5r4m16gfs.fsf@aol.com>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

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

Is there a Windows binary of GnuTLS 3.1.6 available?

The latest one I see at:

ftp://ftp.gnu.org/gnu/gnutls/w32 is:

 11/24/2012 06:17PM      3,085,721 gnutls-3.1.5-w32.zip

Unfortunately, GnuTLS 3.1.5  doesn't include the patch:


http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c9658d930016519e0b44ac284e7414292267e57d

Thanks.



From nmav at gnutls.org  Fri Jan  4 01:05:56 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Jan 2013 01:05:56 +0100
Subject: [gnutls-help] gnutls 3.1.6
In-Reply-To: <xl5r4m16gfs.fsf@aol.com>
References: <50E48330.7080408@gnutls.org> <xl5r4m16gfs.fsf@aol.com>
Message-ID: <50E61CE4.4030807@gnutls.org>

On 01/03/2013 11:37 PM, nyc4bos at aol.com wrote:

> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> Hi,
>> Hello,
>>  I've just released gnutls 3.1.6. This is a bug-fix release on the
>> current stable branch.
> 
> Is there a Windows binary of GnuTLS 3.1.6 available?
> 
> The latest one I see at:
> ftp://ftp.gnu.org/gnu/gnutls/w32 is:


The new site is at:
ftp://ftp.gnutls.org/gcrypt/gnutls/w32/

regards,
Nikos


From nmav at gnutls.org  Sun Jan  6 00:25:32 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 06 Jan 2013 00:25:32 +0100
Subject: [gnutls-help] gnutls 2.12.22
Message-ID: <50E8B66C.8090702@gnutls.org>

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

Version 2.12.22 (released 2013-01-05)

** libgnutls: Stricter RSA PKCS #1 1.5 encoding and decoding. Reported
by Kikuchi Masashi.

** libgnutls: Fixed record padding parsing issue. Reported by Kenny
Patterson and Nadhem Alfardan.

** libgnutls: gnutls_x509_privkey_import_pkcs8() will accept a
NULL password.

** libgnutls: Updated gnulib

** 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 compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v2.12/gnutls-2.12.22.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-2.12.22.tar.bz2.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  Thu Jan 17 20:30:53 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Jan 2013 20:30:53 +0100
Subject: [gnutls-help] higher level session API?
Message-ID: <50F8516D.9080700@gnutls.org>

Hello,
 I've trying ways to simplify the gnutls_session_t by adding higher
level functions. I plan to add function that allow buffering data into a
session prior to sending, to avoid sending many small TLS records (and
avoid the whole overhead). Something like:

ssize_t gnutls_sbuf_queue (gnutls_sbuf_t sb, const void *data,
                           size_t data_size);
ssize_t gnutls_sbuf_flush (gnutls_sbuf_t sb);


However I'm wondering whether a full higher level API over
gnutls_session_t is needed, that for example does not require to handle
non-fatal errors (e.g. GNUTLS_E_AGAIN, or
GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
for a TLS session. Any thoughts?

regards,
Nikos


From mail.flacco at gmail.com  Fri Jan 18 04:11:48 2013
From: mail.flacco at gmail.com (Nick Flacco)
Date: Thu, 17 Jan 2013 19:11:48 -0800
Subject: [gnutls-help] programmatically building a trusted cert list/crl list
Message-ID: <CAMpi_8KaFeE54yYm3=c5R-4P8ytiejkck4kxS3h7yRh_B3-yUw@mail.gmail.com>

I have a similar question to the known in advance PK auth question asked a
while back (
http://lists.gnu.org/archive/html/help-gnutls/2012-11/msg00025.html).

Is there a way to override the set x509 trust + crl file functions? I'm
writing a p2p vpn application and there is no central CA- instead I want to
use voting of some sort, or at least make a request to a trusted peer. From
the x509 server examples I have these two functions:

gnutls_certificate_set_x509_trust_file (x509_cred, CAFILE,
> GNUTLS_X509_FMT_PEM);


In the gnutls source there are some other functions for cetting the trust
file/crl it looks like:

int gnutls_certificate_set_x509_trust_mem (gnutls_certificate_credentials_t
> res, const gnutls_datum_t * ca, gnutls_x509_crt_fmt_t type)
> int gnutls_certificate_set_x509_trust (gnutls_certificate_credentials_t
> res, gnutls_x509_crt_t * ca_list, int ca_list_size)


Is there some function where you can automatically pass in trusted certs?
Or is this something where I need my own function to build a list of
certs? I wrote a simple function to do this (modeled after some stuff I saw
in gnutls_x509.c), but it doesn't work- I get an error on
calling gnutls_x509_crt_import, so I'm using it wrong. Any tips?

Here's how I call the function:

  gnutls_x509_crt_t calist[1];
>   populate_calist(calist, sizeofarr(calist));
>   gnutls_certificate_set_x509_trust (xcred, calist, sizeofarr(calist));


Here's the function:

void populate_calist(gnutls_x509_crt_t *cafile, int length)
{
    int ret;

    // 1. Read binary file (pem)
    // 2. Create x509 pem out of it
    // 3. Add this x509 to the certificate list

    // 1. Read binary file
    size_t size;

    gnutls_datum_t x509blob;
    x509blob.data =  (void*)read_binary_file (CAFILE, &size);
    x509blob.size = (unsigned int) size;
    if (x509blob.data == NULL)
    {
        printf("Error reading file '%s'.\n", CAFILE);
        exit(1);
    }


    // 2. So we have the data in binary form, we need to create an x509 pem
out of it
    gnutls_x509_crt_t crt;
    ret = gnutls_x509_crt_init (&crt);
    if (ret < 0)
    {
        printf("Error on gnutls_x509_crt_init\n");
        return ret;
    }
    ret = gnutls_x509_crt_import(crt, x509blob, GNUTLS_X509_FMT_PEM);
    if (ret < 0)
    {
        printf("error gnutls_x509_crt_import\n"); <------------------ I get
this
        exit(1);
    }

    // 3. Init the list and add the cert
    int i = 0; // just do single element for now
    ret = gnutls_x509_crt_init (&ca_file[i]);
    if (ret < 0)
    {
        printf("Error on gnutls_x509_crt_init(ca_list)\n");
        return ret;
    }
    cafile[0] = crt;

    printf("success!\n");

    return;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130117/97fa36de/attachment.htm>

From alfredo.pironti at inria.fr  Fri Jan 18 11:04:50 2013
From: alfredo.pironti at inria.fr (Alfredo Pironti)
Date: Fri, 18 Jan 2013 11:04:50 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <50F8516D.9080700@gnutls.org>
References: <50F8516D.9080700@gnutls.org>
Message-ID: <CALR0ui+Gcn_bnLOpMLqCwPy3FxoXfmHBD3hndosGhUTeEOiP_Q@mail.gmail.com>

Hi,

One issue I see, is what happen to the buffered data if a
(re)handshake takes place. Potentially, this changes the ciphersuite
and the peer's identity. Safe renegotiation ensures the next
ciphersuite and peer's identity have been negotiated with the previous
peer, but the application may not want to send the remaining buffered
data to the new peer with the new (potentially less secure)
ciphersuite.

Best,
Alfredo

On Thu, Jan 17, 2013 at 8:30 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> Hello,
>  I've trying ways to simplify the gnutls_session_t by adding higher
> level functions. I plan to add function that allow buffering data into a
> session prior to sending, to avoid sending many small TLS records (and
> avoid the whole overhead). Something like:
>
> ssize_t gnutls_sbuf_queue (gnutls_sbuf_t sb, const void *data,
>                            size_t data_size);
> ssize_t gnutls_sbuf_flush (gnutls_sbuf_t sb);
>
>
> However I'm wondering whether a full higher level API over
> gnutls_session_t is needed, that for example does not require to handle
> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
> for a TLS session. Any thoughts?
>
> regards,
> Nikos
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From nmav at gnutls.org  Sat Jan 19 13:56:12 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Jan 2013 13:56:12 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <CALR0ui+Gcn_bnLOpMLqCwPy3FxoXfmHBD3hndosGhUTeEOiP_Q@mail.gmail.com>
References: <50F8516D.9080700@gnutls.org>
	<CALR0ui+Gcn_bnLOpMLqCwPy3FxoXfmHBD3hndosGhUTeEOiP_Q@mail.gmail.com>
Message-ID: <50FA97EC.6050809@gnutls.org>

On 01/18/2013 11:04 AM, Alfredo Pironti wrote:

> Hi,
> 
> One issue I see, is what happen to the buffered data if a
> (re)handshake takes place. Potentially, this changes the ciphersuite
> and the peer's identity. Safe renegotiation ensures the next
> ciphersuite and peer's identity have been negotiated with the previous
> peer, but the application may not want to send the remaining buffered
> data to the new peer with the new (potentially less secure)
> ciphersuite.


Indeed, the higher level functions should either prohibit rehandshake,
or only allow it when safe renegotiation is supported by both.

About a potentially less secure ciphersuite, I think that the actual
security level of the session is set by the initial priority string.
That is, the weakest algorithm in that list should be assumed to be the
security level. A renegotiation couldn't reduce that level.

regards,
Nikos


From nmav at gnutls.org  Wed Jan 23 10:42:54 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 23 Jan 2013 10:42:54 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <201301211041.27942.tim.ruehsen@gmx.de>
References: <50F8516D.9080700@gnutls.org>
	<201301211041.27942.tim.ruehsen@gmx.de>
Message-ID: <CAJU7za+0QaEUe0F9QnjyUGJgT_o=jLykioKna_xLBqwn9XDUNw@mail.gmail.com>

On Mon, Jan 21, 2013 at 10:41 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:

>> However I'm wondering whether a full higher level API over
>> gnutls_session_t is needed, that for example does not require to handle
>> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
>> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
>> for a TLS session. Any thoughts?
> For an application developer, a high level API that can be used 'quick and
> dirty', would reduce the amounts of code and time ot use gnutls.
> e.g. like this pseudo code
> gnutls_session_t sess = gnutls_open(
>         hostname, port,
>         // here come *optional* key, value pairs, some examples
>         // GNUTLS_READ_TIMEOUT, 5000, // in milliseconds
>         // GNUTLS_PRIORITY, "NORMAL:-VERS-SSL3.0",
>         // GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on and off
>         / ...
>         NULL); // gcc >= 4 is able to check this with attribute 'sentinel'

That's pretty high level. I think the networking part (i.e. connection
to host and resolving) will have to be kept out. Networking
applications already have this code and in these cases it may be
harder to use that API. I'm thinking of a simpler API that includes
the
priority string, the check certificate flag, and a credentials structure if any.

> ssize_t nbytes = gnutls_write(sess, buf, buflen);
> ssize_t nbytes = gnutls_printf(sess, "%d - %s\n", ival, str);
> ssize_t nbytes = gnutls_read(sess, buf, bufsize);
> ssize_t nbytes = gnutls_getline(sess, &buf, &bufsize);

I like those. I'll try to add them (I think the getline is missing
from the current code).

> The 'open' function should have reasonable default values to work 'right out
> of the box'. It should also do gnutls_global_init() implicitely, if it hasn't
> be done yet.

That one is tricky because it would mean having explicit thread locks
(global_init isn't thread safe). I think global_init should be called
independently.

> And back to your idea with queue/flush:
> - inspired from TCP_CORK, my idea would be something like
>         gnutls_cork()
>         do some writes
>         gnutls_uncork (or calling it gnutls_flush, if you like)
> - or/and implementing something like the Nagle algorithm, kind of automatic
> cork/uncork

Is that for the gnutls_session_t API? It's an interesting idea and may
even remove the need of a higher-level API. I'll think about it.

regards,
Nikos


From nmav at gnutls.org  Sat Jan 26 11:40:58 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jan 2013 11:40:58 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <201301251724.01362.tim.ruehsen@gmx.de>
References: <50F8516D.9080700@gnutls.org>
	<201301211041.27942.tim.ruehsen@gmx.de>
	<CAJU7za+0QaEUe0F9QnjyUGJgT_o=jLykioKna_xLBqwn9XDUNw@mail.gmail.com>
	<201301251724.01362.tim.ruehsen@gmx.de>
Message-ID: <5103B2BA.6030004@gnutls.org>

On 01/25/2013 05:24 PM, Tim R?hsen wrote:

> You are right. Maybe the socket descriptor should go to gnutls_open().
> And isn't the hostname needed for host validation while handshaking ? I think 
> about gnutls_x509_crt_check_hostname().


Right.

>> I like those. I'll try to add them (I think the getline is missing
>> from the current code).
> If it helps, look at my getline() implementation for file descriptors.
> The internal variables are saved at the end of buf, but you won't need this 
> ugly trick since you have a session variable.


I've implemented it using gnulib's getline which in turn was based on
libc's one :)

Now only the _open/ or _init is missing. Also I have to think of a
better prefix name.

I'm thinking with the high level functions to also simplify credentials
handling, and initially support:
1. normal X.509 certificate verification (based on system certs)
2. TOFU (for people who don't want to buy a cert)
3. Insecure (for debugging)

>>> And back to your idea with queue/flush:
>>> - inspired from TCP_CORK, my idea would be something like
>>>         gnutls_cork()
>>>         do some writes
>>>         gnutls_uncork (or calling it gnutls_flush, if you like)
>>> - or/and implementing something like the Nagle algorithm, kind of 
> automatic
>>> cork/uncork
>>
>> Is that for the gnutls_session_t API?
> It was just an idea without thinking about that ;-)


I liked them though, because they allow the usage of buffering in the
low-level API so they are there now.

> A higher level API is always good for application programmers to have a fast 
> success (and a short learning time). Later. if things become more wicked, they 
> will investigate into the mid- and/or low-level API.


When I created the original low-level API I expected that there will be
middle-ware libraries that wrap over sockets and TLS. It seems that even
today they are no so widespread, so indeed a high level API makes sense.

regards,
Nikos


From nmav at gnutls.org  Mon Jan 28 02:24:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Jan 2013 02:24:40 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <201301251724.01362.tim.ruehsen@gmx.de>
References: <50F8516D.9080700@gnutls.org>
	<201301211041.27942.tim.ruehsen@gmx.de>
	<CAJU7za+0QaEUe0F9QnjyUGJgT_o=jLykioKna_xLBqwn9XDUNw@mail.gmail.com>
	<201301251724.01362.tim.ruehsen@gmx.de>
Message-ID: <5105D358.7000400@gnutls.org>

Ok it seems I'm closer to a simpler API. A draft version is in:
https://gitorious.org/gnutls/gnutls/blobs/master/lib/includes/gnutls/xssl.h

Currently the code to set credentials is the most complex, but overall
it looks quite an improvement in terms of size of code. An example of a
client and a server is at:

https://gitorious.org/gnutls/gnutls/blobs/master/tests/mini-xssl.c#line151

regards,
Nikos

On 01/25/2013 05:24 PM, Tim R?hsen wrote:

> Am Mittwoch, 23. Januar 2013 schrieb Nikos Mavrogiannopoulos:
>> On Mon, Jan 21, 2013 at 10:41 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>>
>>>> However I'm wondering whether a full higher level API over
>>>> gnutls_session_t is needed, that for example does not require to handle
>>>> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
>>>> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
>>>> for a TLS session. Any thoughts?
>>> For an application developer, a high level API that can be used 'quick and
>>> dirty', would reduce the amounts of code and time ot use gnutls.
>>> e.g. like this pseudo code
>>> gnutls_session_t sess = gnutls_open(
>>>         hostname, port,
>>>         // here come *optional* key, value pairs, some examples
>>>         // GNUTLS_READ_TIMEOUT, 5000, // in milliseconds
>>>         // GNUTLS_PRIORITY, "NORMAL:-VERS-SSL3.0",
>>>         // GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on 
> and off
>>>         / ...
>>>         NULL); // gcc >= 4 is able to check this with attribute 'sentinel'
>>
>> That's pretty high level. I think the networking part (i.e. connection
>> to host and resolving) will have to be kept out. Networking
>> applications already have this code and in these cases it may be
>> harder to use that API. I'm thinking of a simpler API that includes
>> the
>> priority string, the check certificate flag, and a credentials structure if 
> any.
>>
> 
> You are right. Maybe the socket descriptor should go to gnutls_open().
> And isn't the hostname needed for host validation while handshaking ? I think 
> about gnutls_x509_crt_check_hostname().
> 
>>> ssize_t nbytes = gnutls_write(sess, buf, buflen);
>>> ssize_t nbytes = gnutls_printf(sess, "%d - %s\n", ival, str);
>>> ssize_t nbytes = gnutls_read(sess, buf, bufsize);
>>> ssize_t nbytes = gnutls_getline(sess, &buf, &bufsize);
>>
>> I like those. I'll try to add them (I think the getline is missing
>> from the current code).
> 
> If it helps, look at my getline() implementation for file descriptors.
> The internal variables are saved at the end of buf, but you won't need this 
> ugly trick since you have a session variable.
> 
> https://github.com/rockdaboot/mget/blob/master/libmget/io.c
> 
>>
>>> The 'open' function should have reasonable default values to work 'right 
> out
>>> of the box'. It should also do gnutls_global_init() implicitely, if it 
> hasn't
>>> be done yet.
>>
>> That one is tricky because it would mean having explicit thread locks
>> (global_init isn't thread safe). I think global_init should be called
>> independently.
> 
> Yes, to avoid thread locks, global_init needs to be called explicitely.
> 
>>
>>> And back to your idea with queue/flush:
>>> - inspired from TCP_CORK, my idea would be something like
>>>         gnutls_cork()
>>>         do some writes
>>>         gnutls_uncork (or calling it gnutls_flush, if you like)
>>> - or/and implementing something like the Nagle algorithm, kind of 
> automatic
>>> cork/uncork
>>
>> Is that for the gnutls_session_t API?
> 
> It was just an idea without thinking about that ;-)
> 
>> It's an interesting idea and may
>> even remove the need of a higher-level API. I'll think about it.
> 
> A higher level API is always good for application programmers to have a fast 
> success (and a short learning time). Later. if things become more wicked, they 
> will investigate into the mid- and/or low-level API.
> 
> Regards, Tim
> 




From nmav at gnutls.org  Mon Jan 28 12:58:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Jan 2013 12:58:40 +0100
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <201301281055.09733.tim.ruehsen@gmx.de>
References: <50F8516D.9080700@gnutls.org>
	<201301251724.01362.tim.ruehsen@gmx.de>
	<5105D358.7000400@gnutls.org>
	<201301281055.09733.tim.ruehsen@gmx.de>
Message-ID: <CAJU7za+ZiAgQDDftApxqo59X5sGK2buRkpNU94DS0Wzzrpahtg@mail.gmail.com>

On Mon, Jan 28, 2013 at 10:55 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Am Monday 28 January 2013 schrieb Nikos Mavrogiannopoulos:
>> Ok it seems I'm closer to a simpler API. A draft version is in:
>> https://gitorious.org/gnutls/gnutls/blobs/master/lib/includes/gnutls/xssl.h
>> Currently the code to set credentials is the most complex, but overall
>> it looks quite an improvement in terms of size of code. An example of a
>> client and a server is at:
>> https://gitorious.org/gnutls/gnutls/blobs/master/tests/mini-xssl.c#line151
> I like it. Really much simpler than the current approach. I would like to
> implement it into my current project (libmget / mget) in the near future.
> How can a client 'force' a server certificate to be accepted (switch
> certificate checking off) ?

The gnutls_vmethod_t specifies how the peer will be authenticated. The
current options are NO_AUTH, TOFU, GIVEN_CAS, and SYSTEM_CAS (and more
than one can be specified).

My plan is to increase that with DANE (that would be tricky), OCSP,
and possibly SRP, PSK etc.

Also I'm thinking to remove the specification of a priority string in
the xssl_init function and only specify a security parameter
(gnutls_sec_param_t), which will be translated to a priority string
internally.

> Do I still link with -lgnutls, or will there be an extra libgnutls-xssl
> library ?

Currently it is part of the main library, but probably before any
release I move it to a separate one. Since it is a totally new API
that is not tested in the field, I wouldn't like to commit on it so
early. Maybe initially it can be part of an xssl library and when it
is stable enough as an API it moves into the main gnutls library.

> What I can't judge: is xssl_cert_init() complete to handle all cases of a real
> life implementation like e.g. Wget ? There are these kinds of arguments:
> --no-check-certificate
> --certificate=file
> --certificate-type=type
> --private-key=file
> --private-key-type=type
> --ca-certificate=file
> --ca-directory=directory

I believe all these options are handled by the current code (except
the ca-directory).

regards,
Nikos


From dkg at fifthhorseman.net  Tue Jan 29 21:12:06 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 29 Jan 2013 15:12:06 -0500
Subject: [gnutls-help] telling gnutls-cli to avoid sending SNI
Message-ID: <87wquv6961.fsf@alice.fifthhorseman.net>

Sometimes I don't want gnutls-cli to send SNI.

The two ways i see to do this currently are:

 0) do the DNS resolution outside of gnutls-cli:

    gnutls-cli $(dig +short foo.example | head -n1)

 1) disable all TLS extensions:

   gnutls-cli --disable-extensions


The problem with (0) of course is that the certificate verification
fails because gnutls-cli doesn't know what to check for.

The problem with (1) is that sometimes i'd like to use other extensions
while avoiding SNI.  And gnutls-cli(1) claims it's deprecated:

> This option disables all TLS extensions. Deprecated option. Use the priority string.

But i don't see how to use the priority string to disable SNI itself.

src/cli.c doesn't seem to offer a way to do it:

-------------
  if (disable_extensions == 0)
    {
      if (!isdigit(hostname[0]) && strchr(hostname, ':') == 0)
        gnutls_server_name_set (session, GNUTLS_NAME_DNS, hostname,
                                strlen (hostname));
    }
-------------

I'm currently trying to make a patch for a --disable-sni flag to
gnutls-cli (does something like that sound useful?), but i seem to be
stumbling over some of the generated files that are committed to the git
repo.

The attached patch seems like the nice minimal thing to add, but then it
appears to be necessary to also do:

 cd src && autogen cli-args.def

But that creates a much larger and more opaque patch, and then compilation
fails (perhaps because my system has autogen 5.17.1 and the existing
other autogen'ed headers appear to be from autogen 5.16).

The compilation failure looks like this:

  CC     libcmd_cli_la-cli-args.lo
In file included from cli-args.c:44:0:
cli-args.h:62:3: error: #error option template version mismatches autoopts/options.h header
cli-args.h:63:3: error: unknown type name 'Choke'
cli-args.h:63:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
cli-args.h:117:3: warning: data definition has no type or storage class [enabled by default]
cli-args.h:117:3: warning: type defaults to 'int' in declaration of 'teOptIndex' [enabled by default]
cli-args.c:1190:29: error: 'INDEX_OPT_VERSION' undeclared here (not in a function)
cli-args.c:1204:29: error: 'INDEX_OPT_HELP' undeclared here (not in a function)
cli-args.c:1216:29: error: 'INDEX_OPT_MORE_HELP' undeclared here (not in a function)
cli-args.c: In function 'AO_gettext':
cli-args.c:1583:9: error: 'option_xlateable_txt' undeclared (first use in this function)
cli-args.c:1583:9: note: each undeclared identifier is reported only once for each function it appears in
cli-args.c: In function 'translate_option_strings':
cli-args.c:1622:9: error: 'option_xlateable_txt' undeclared (first use in this function)
make[4]: *** [libcmd_cli_la-cli-args.lo] Error 1
make[4]: Leaving directory `/tmp/cdtemp.TdCJYy/gnutls/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/cdtemp.TdCJYy/gnutls/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/cdtemp.TdCJYy/gnutls/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/cdtemp.TdCJYy/gnutls'
make: *** [all] Error 2
2 dkg at alice:/tmp/cdtemp.TdCJYy/gnutls$ 

any ideas about how i should proceed with this?

Regards,

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cli-disable-sni.patch
Type: text/x-diff
Size: 1560 bytes
Desc: add a --disable-sni option to gnutls-cli
URL: </pipermail/attachments/20130129/0bc30499/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20130129/0bc30499/attachment-0001.pgp>

From tim.ruehsen at gmx.de  Mon Jan 21 11:20:48 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 21 Jan 2013 10:20:48 -0000
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <50F8516D.9080700@gnutls.org>
References: <50F8516D.9080700@gnutls.org>
Message-ID: <201301211041.27942.tim.ruehsen@gmx.de>

Am Thursday 17 January 2013 schrieb Nikos Mavrogiannopoulos:
>  I've trying ways to simplify the gnutls_session_t by adding higher
> level functions. I plan to add function that allow buffering data into a
> session prior to sending, to avoid sending many small TLS records (and
> avoid the whole overhead). Something like:
> 
> ssize_t gnutls_sbuf_queue (gnutls_sbuf_t sb, const void *data,
>                            size_t data_size);
> ssize_t gnutls_sbuf_flush (gnutls_sbuf_t sb);
> 
> 
> However I'm wondering whether a full higher level API over
> gnutls_session_t is needed, that for example does not require to handle
> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
> for a TLS session. Any thoughts?

For an application developer, a high level API that can be used 'quick and 
dirty', would reduce the amounts of code and time ot use gnutls.

e.g. like this pseudo code

gnutls_session_t sess = gnutls_open(
	hostname, port,
	// here come *optional* key, value pairs, some examples
	// GNUTLS_READ_TIMEOUT, 5000, // in milliseconds
	// GNUTLS_PRIORITY, "NORMAL:-VERS-SSL3.0",
	// GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on and off
	/ ...
	NULL); // gcc >= 4 is able to check this with attribute 'sentinel'

ssize_t nbytes = gnutls_write(sess, buf, buflen);
ssize_t nbytes = gnutls_printf(sess, "%d - %s\n", ival, str);
ssize_t nbytes = gnutls_read(sess, buf, bufsize);
ssize_t nbytes = gnutls_getline(sess, &buf, &bufsize);
// and why not gnutls_fgets(), though i personally don't like it

gnutls_close(sess);

The 'open' function should have reasonable default values to work 'right out 
of the box'. It should also do gnutls_global_init() implicitely, if it hasn't 
be done yet.
You still have access to the gnutls_session_t variable, if you need to 
something fancy. 
The key/value approach of course has no 'value type checking' (though it could 
be done by a gcc plugin).

Right now I need ~ 300 lines of C code to implent the open/read/write/close 
part.

And back to your idea with queue/flush:
- inspired from TCP_CORK, my idea would be something like
	gnutls_cork()
	do some writes
	gnutls_uncork (or calling it gnutls_flush, if you like)
- or/and implementing something like the Nagle algorithm, kind of automatic 
cork/uncork

Just my thoughts...

Regards, 

     Tim R?hsen


From tim.ruehsen at gmx.de  Fri Jan 25 17:26:08 2013
From: tim.ruehsen at gmx.de (Tim =?utf-8?q?R=C3=BChsen?=)
Date: Fri, 25 Jan 2013 16:26:08 -0000
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <CAJU7za+0QaEUe0F9QnjyUGJgT_o=jLykioKna_xLBqwn9XDUNw@mail.gmail.com>
References: <50F8516D.9080700@gnutls.org>
 <201301211041.27942.tim.ruehsen@gmx.de>
 <CAJU7za+0QaEUe0F9QnjyUGJgT_o=jLykioKna_xLBqwn9XDUNw@mail.gmail.com>
Message-ID: <201301251724.01362.tim.ruehsen@gmx.de>

Am Mittwoch, 23. Januar 2013 schrieb Nikos Mavrogiannopoulos:
> On Mon, Jan 21, 2013 at 10:41 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> 
> >> However I'm wondering whether a full higher level API over
> >> gnutls_session_t is needed, that for example does not require to handle
> >> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
> >> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
> >> for a TLS session. Any thoughts?
> > For an application developer, a high level API that can be used 'quick and
> > dirty', would reduce the amounts of code and time ot use gnutls.
> > e.g. like this pseudo code
> > gnutls_session_t sess = gnutls_open(
> >         hostname, port,
> >         // here come *optional* key, value pairs, some examples
> >         // GNUTLS_READ_TIMEOUT, 5000, // in milliseconds
> >         // GNUTLS_PRIORITY, "NORMAL:-VERS-SSL3.0",
> >         // GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on 
and off
> >         / ...
> >         NULL); // gcc >= 4 is able to check this with attribute 'sentinel'
> 
> That's pretty high level. I think the networking part (i.e. connection
> to host and resolving) will have to be kept out. Networking
> applications already have this code and in these cases it may be
> harder to use that API. I'm thinking of a simpler API that includes
> the
> priority string, the check certificate flag, and a credentials structure if 
any.
> 

You are right. Maybe the socket descriptor should go to gnutls_open().
And isn't the hostname needed for host validation while handshaking ? I think 
about gnutls_x509_crt_check_hostname().

> > ssize_t nbytes = gnutls_write(sess, buf, buflen);
> > ssize_t nbytes = gnutls_printf(sess, "%d - %s\n", ival, str);
> > ssize_t nbytes = gnutls_read(sess, buf, bufsize);
> > ssize_t nbytes = gnutls_getline(sess, &buf, &bufsize);
> 
> I like those. I'll try to add them (I think the getline is missing
> from the current code).

If it helps, look at my getline() implementation for file descriptors.
The internal variables are saved at the end of buf, but you won't need this 
ugly trick since you have a session variable.

https://github.com/rockdaboot/mget/blob/master/libmget/io.c

> 
> > The 'open' function should have reasonable default values to work 'right 
out
> > of the box'. It should also do gnutls_global_init() implicitely, if it 
hasn't
> > be done yet.
> 
> That one is tricky because it would mean having explicit thread locks
> (global_init isn't thread safe). I think global_init should be called
> independently.

Yes, to avoid thread locks, global_init needs to be called explicitely.

> 
> > And back to your idea with queue/flush:
> > - inspired from TCP_CORK, my idea would be something like
> >         gnutls_cork()
> >         do some writes
> >         gnutls_uncork (or calling it gnutls_flush, if you like)
> > - or/and implementing something like the Nagle algorithm, kind of 
automatic
> > cork/uncork
> 
> Is that for the gnutls_session_t API?

It was just an idea without thinking about that ;-)

> It's an interesting idea and may
> even remove the need of a higher-level API. I'll think about it.

A higher level API is always good for application programmers to have a fast 
success (and a short learning time). Later. if things become more wicked, they 
will investigate into the mid- and/or low-level API.

Regards, Tim



From tim.ruehsen at gmx.de  Mon Jan 28 10:51:35 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 28 Jan 2013 09:51:35 -0000
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <5105D358.7000400@gnutls.org>
References: <50F8516D.9080700@gnutls.org>
 <201301251724.01362.tim.ruehsen@gmx.de> <5105D358.7000400@gnutls.org>
Message-ID: <201301281055.09733.tim.ruehsen@gmx.de>

Am Monday 28 January 2013 schrieb Nikos Mavrogiannopoulos:
> Ok it seems I'm closer to a simpler API. A draft version is in:
> https://gitorious.org/gnutls/gnutls/blobs/master/lib/includes/gnutls/xssl.h
> 
> Currently the code to set credentials is the most complex, but overall
> it looks quite an improvement in terms of size of code. An example of a
> client and a server is at:
> 
> https://gitorious.org/gnutls/gnutls/blobs/master/tests/mini-xssl.c#line151

I like it. Really much simpler than the current approach. I would like to 
implement it into my current project (libmget / mget) in the near future.

How can a client 'force' a server certificate to be accepted (switch 
certificate checking off) ?

Do I still link with -lgnutls, or will there be an extra libgnutls-xssl 
library ?

What I can't judge: is xssl_cert_init() complete to handle all cases of a real 
life implementation like e.g. Wget ? There are these kinds of arguments:
--no-check-certificate
--certificate=file
--certificate-type=type
--private-key=file
--private-key-type=type
--ca-certificate=file
--ca-directory=directory

Regards, Tim


From tim.ruehsen at gmx.de  Mon Jan 28 11:02:22 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 28 Jan 2013 10:02:22 -0000
Subject: [gnutls-help] [gnutls-devel] higher level session API?
In-Reply-To: <5103B2BA.6030004@gnutls.org>
References: <50F8516D.9080700@gnutls.org>
 <201301251724.01362.tim.ruehsen@gmx.de> <5103B2BA.6030004@gnutls.org>
Message-ID: <201301281105.52450.tim.ruehsen@gmx.de>

Am Saturday 26 January 2013 schrieb Nikos Mavrogiannopoulos:
> > If it helps, look at my getline() implementation for file descriptors.
> > The internal variables are saved at the end of buf, but you won't need
> > this ugly trick since you have a session variable.
> 
> I've implemented it using gnulib's getline which in turn was based on
> libc's one :)

just BTW:
When I needed glib's getline() for a socket descriptor (using freopen to use a 
stream), I realized that I did not work (i guess, the stream has to be 
seekable). So I wrote my own function, directly capable of using file/socket 
descriptors. I did not look at gnulib's code, since I needed my own copyright 
on the code. Afterwards I realized my function being (AFAIK) ~30% faster that 
glib's - I guess it is the missing FILE handle overhead... 

Regards, Tim


From mmfwwijnen at gmail.com  Thu Jan 17 15:11:04 2013
From: mmfwwijnen at gmail.com (Marcel Wijnen)
Date: Thu, 17 Jan 2013 14:11:04 -0000
Subject: [gnutls-help] Compiling example programs
Message-ID: <CA+N6Ea9dNhuZVWuhG8q7EKHxNDfNWnristLxB7V2XdO-FmH++Q@mail.gmail.com>

Hi All,

Currently I'm looking at the different examples that are available on the
website.When I try to compile the example code several errors appear.

In 9.1.1 Simple client example with X.509 certificate support
(
https://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support
 )

#include "example.h" causes the error : No such file or directory

In 9.1.3 Simple client example with anonymous authentication
(
https://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-anonymous-authentication.html#Simple-client-example-with-anonymous-authentication
 )

undefined reference to 'tcp_connect'
undefined reference to 'gnutls_handshake_set_timeout'
undefined reference to 'tcp_close'

I'm compiling with: *gcc <filename>.c -l gnutls*

I was wondering whether someone can point me in the right direction to move
forward.

Any help is greatly appreciated. Thanks in advance.

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130117/222db0ff/attachment-0001.html>