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-devel] 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 INVALID.NOREPLY at gnu.org  Thu Jan  3 07:13:30 2013
From: INVALID.NOREPLY at gnu.org (Marko Lindqvist)
Date: Thu, 03 Jan 2013 06:13:30 +0000
Subject: [gnutls-devel] [sr #108219] Build with automake-1.13 broken (fix
	included)
Message-ID: <20130103-061328.sv90165.25532@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?108219>

                 Summary: Build with automake-1.13 broken (fix included)
                 Project: GnuTLS
            Submitted by: cazfi
            Submitted on: Thu 03 Jan 2013 06:13:28 AM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors
out upon seeing it.

Attached patch replaces it with proper AC_CONFIG_HEADERS.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 03 Jan 2013 06:13:28 AM GMT  Name: obsolete_automake_macros.patch 
Size: 1kB   By: cazfi

<http://savannah.gnu.org/support/download.php?file_id=27187>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108219>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



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-devel] 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 dmoncayo at gmail.com  Thu Jan  3 11:41:02 2013
From: dmoncayo at gmail.com (Dani Moncayo)
Date: Thu, 3 Jan 2013 11:41:02 +0100
Subject: [gnutls-devel] Broken link?
Message-ID: <CAH8Pv0jeGQDeR5L2y748kTJLH15tni+pxR-TS94kvM5RuomBiQ@mail.gmail.com>

Hello,

>From the GNUTLS download page (http://www.gnutls.org/download.html),
if I click on the link "ftp://ftp.gnutls.org/gcrypt/gnutls/w32/", my
browser tells me that it cannot connect to the URL.

I seem to recollect that link worked, not long ago.

Do you know what the problem could be?

-- 
Dani Moncayo


From nmav at gnutls.org  Thu Jan  3 19:51:46 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 03 Jan 2013 19:51:46 +0100
Subject: [gnutls-devel] [sr #108219] Build with automake-1.13 broken
 (fix included)
In-Reply-To: <20130103-061328.sv90165.25532@savannah.gnu.org>
References: <20130103-061328.sv90165.25532@savannah.gnu.org>
Message-ID: <50E5D342.2070609@gnutls.org>

On 01/03/2013 07:13 AM, Marko Lindqvist wrote:


> Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
> http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors
> out upon seeing it.


Thanks. I've committed a fix in the master branch.

regards,
Nikos



From nmav at gnutls.org  Fri Jan  4 01:07:18 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Jan 2013 01:07:18 +0100
Subject: [gnutls-devel] Broken link?
In-Reply-To: <CAH8Pv0jeGQDeR5L2y748kTJLH15tni+pxR-TS94kvM5RuomBiQ@mail.gmail.com>
References: <CAH8Pv0jeGQDeR5L2y748kTJLH15tni+pxR-TS94kvM5RuomBiQ@mail.gmail.com>
Message-ID: <50E61D36.2060909@gnutls.org>

On 01/03/2013 11:41 AM, Dani Moncayo wrote:

> Hello,
> 
>>From the GNUTLS download page (http://www.gnutls.org/download.html),
> if I click on the link "ftp://ftp.gnutls.org/gcrypt/gnutls/w32/", my
> browser tells me that it cannot connect to the URL.


I have no issue accessing it. It may be a bug with your browser. Since
this is an ftp URL you may want to try an ftp client.

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-devel] 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 INVALID.NOREPLY at gnu.org  Mon Jan  7 17:21:13 2013
From: INVALID.NOREPLY at gnu.org (Joshua Phillips)
Date: Mon, 07 Jan 2013 16:21:13 +0000
Subject: [gnutls-devel] [sr #108224] Segmentation fault when /dev/urandom is
	unavailable.
Message-ID: <20130107-162112.sv90187.62364@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?108224>

                 Summary: Segmentation fault when /dev/urandom is unavailable.
                 Project: GnuTLS
            Submitted by: xlq
            Submitted on: Mon 07 Jan 2013 04:21:12 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 2 - Minor
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

In lib/nettle/egd.c, find_egd_name returns NULL on failure. This is passed
directly to strlen in _rndegd_connect_socket, causing a segmentation fault if
neither /dev/urandom nor EGD are available.

The attached untested patch checks the pointer returned from find_egd_name.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 07 Jan 2013 04:21:12 PM GMT  Name: egd-crash.diff  Size: 432B   By:
xlq

<http://savannah.gnu.org/support/download.php?file_id=27217>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108224>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



From INVALID.NOREPLY at gnu.org  Mon Jan  7 17:48:00 2013
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 Jan 2013 16:48:00 +0000
Subject: [gnutls-devel] [sr #108224] Segmentation fault when /dev/urandom is
	unavailable.
In-Reply-To: <20130107-162112.sv90187.62364@savannah.gnu.org>
References: <20130107-162112.sv90187.62364@savannah.gnu.org>
Message-ID: <20130107-184800.sv707.75555@savannah.gnu.org>

Update of sr #108224 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Thank you. I've applied it. Nevertheless there is not much you can do without
a /dev/urandom and an egd device.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108224>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



From bry8star at yahoo.com  Wed Jan  9 20:07:02 2013
From: bry8star at yahoo.com (Bry8 Star)
Date: Wed, 09 Jan 2013 19:07:02 +0000
Subject: [gnutls-devel] GnuTLS RPM package, Upgrade to last stable
Message-ID: <50EDBFD6.1010501@yahoo.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,
Is there a GnuTLS RPM package with version
3.1.1 or higher for CentOS 6.3 ?
(32-bit is more than suffice for my purpose)

Currently CentOS 6.3 is using GnuTLS 2.8.5

Need to use new DANE feature of last GnuTLS, with exim, etc apps.

Those who are familiar with related areas, if they are kind enough
to point to an article for upgrading the older GnuTLS with the last
stable GnuTLS edition, (on CentOS 6.3), then that would have been
very helpful, for many users.

If newer GnuTLS is loaded onto a different directory as a 2nd
GnuTLS, then would it be possible to specify that second
directory/GnuTLS in Exim.

Thanks in advance,
- -- Bright Star.
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlDtv9UACgkQiDbboldsEOxO+AD/a6r7hqM79ly7DaPtwmwcmBvv
2c5eU6TeqWG5zcGWlxUA/j922aNflPOIYZ+dJiU3h9M+O/Z4pemi3n2Ai4tEoqRz
=iUJN
-----END PGP SIGNATURE-----


From ametzler at downhill.at.eu.org  Thu Jan 10 18:56:09 2013
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 10 Jan 2013 18:56:09 +0100
Subject: [gnutls-devel] GnuTLS RPM package, Upgrade to last stable
In-Reply-To: <50EDBFD6.1010501@yahoo.com>
References: <50EDBFD6.1010501@yahoo.com>
Message-ID: <20130110175609.GB3165@downhill.g.la>

On 2013-01-09 Bry8 Star <bry8star at yahoo.com> wrote:
[2.8.6 to 3.1.x]
> If newer GnuTLS is loaded onto a different directory as a 2nd
> GnuTLS, then would it be possible to specify that second
> directory/GnuTLS in Exim.

That is not possible, GnuTLS 3.1.x has a different soname as it is not
binary compatible with 2.8.6. You would need to recompile exim against
the newer version of GnuTLS.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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-devel] 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 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-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-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 alon.barlev at gmail.com  Sun Jan 20 20:58:53 2013
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 20 Jan 2013 21:58:53 +0200
Subject: [gnutls-devel] [PATCH] build: add danetool-args.c to BUILT_SOURCES
Message-ID: <1358711933-31302-1-git-send-email-alon.barlev@gmail.com>

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index 5aebf20..3059dd1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -191,7 +191,7 @@ libcmd_tpmtool_la_LIBADD += $(LTLIBREADLINE) $(INET_PTON_LIB)
 endif # ENABLE_TROUSERS
 
 BUILT_SOURCES = ocsptool-args.c p11tool-args.c psk-args.c cli-debug-args.c \
-		cli-args.c serv-args.c srptool-args.c certtool-args.c
+		cli-args.c serv-args.c srptool-args.c certtool-args.c danetool-args.c
 
 danetool-args.c: $(srcdir)/args-std.def $(srcdir)/danetool-args.def
 	-autogen danetool-args.def
-- 
1.7.12.4



From nmav at gnutls.org  Sun Jan 20 22:05:08 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 20 Jan 2013 22:05:08 +0100
Subject: [gnutls-devel] [PATCH] build: add danetool-args.c to
	BUILT_SOURCES
In-Reply-To: <1358711933-31302-1-git-send-email-alon.barlev@gmail.com>
References: <1358711933-31302-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <50FC5C04.7080300@gnutls.org>

Applied. Thanks.

On 01/20/2013 08:58 PM, Alon Bar-Lev wrote:

> Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
> ---
>  src/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 5aebf20..3059dd1 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -191,7 +191,7 @@ libcmd_tpmtool_la_LIBADD += $(LTLIBREADLINE) $(INET_PTON_LIB)
>  endif # ENABLE_TROUSERS
>  
>  BUILT_SOURCES = ocsptool-args.c p11tool-args.c psk-args.c cli-debug-args.c \
> -		cli-args.c serv-args.c srptool-args.c certtool-args.c
> +		cli-args.c serv-args.c srptool-args.c certtool-args.c danetool-args.c
>  
>  danetool-args.c: $(srcdir)/args-std.def $(srcdir)/danetool-args.def
>  	-autogen danetool-args.def




From tim.ruehsen at gmx.de  Mon Jan 21 10:41:27 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 21 Jan 2013 10:41:27 +0100
Subject: [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 martin at martin.st  Mon Jan 21 15:00:10 2013
From: martin at martin.st (Martin Storsjo)
Date: Mon, 21 Jan 2013 16:00:10 +0200
Subject: [gnutls-devel] [PATCH] Define _gnutls_file_mutex in gnutls_global.c
	instead of in verify-tofu.c
Message-ID: <1358776810-9468-1-git-send-email-martin@martin.st>

This fixes issues with linking the tools on OS X if not building
shared libraries.

Currently, if building with --disable-shared on OS X, the build
fails with:
  CCLD   gnutls-serv
Undefined symbols for architecture x86_64:
  "__gnutls_file_mutex", referenced from:
      _gnutls_global_deinit in libgnutls.a(gnutls_global.o)
      _gnutls_global_init in libgnutls.a(gnutls_global.o)
ld: symbol(s) not found for architecture x86_64

It seems that the linker fails to pull in verify-tofu.o to satisfy
the undefined reference to _gnutls_file_mutex.o in gnutls_global.o
unless gnutls_global.o (or any other object file in the link) also
calls functions that pulls in verify-tofu.o. Since gnutls_global.o
always is linked in, but verify-tofu.o can be left out unless someone
calls the functions in it, defining the mutex in gnutls_global.c makes
sense and simplifies the dependencies.
---
 lib/gnutls_global.c |    2 +-
 lib/verify-tofu.c   |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/gnutls_global.c b/lib/gnutls_global.c
index 295e620..1959bd3 100644
--- a/lib/gnutls_global.c
+++ b/lib/gnutls_global.c
@@ -42,7 +42,7 @@
 /* created by asn1c */
 extern const ASN1_ARRAY_TYPE gnutls_asn1_tab[];
 extern const ASN1_ARRAY_TYPE pkix_asn1_tab[];
-extern void *_gnutls_file_mutex;
+void *_gnutls_file_mutex;
 
 ASN1_TYPE _gnutls_pkix1_asn;
 ASN1_TYPE _gnutls_gnutls_asn;
diff --git a/lib/verify-tofu.c b/lib/verify-tofu.c
index 3592395..4c19c90 100644
--- a/lib/verify-tofu.c
+++ b/lib/verify-tofu.c
@@ -60,7 +60,7 @@ int store_pubkey(const char* db_name, const char* host,
 static int find_config_file(char* file, size_t max_size);
 #define MAX_FILENAME 512
 
-void *_gnutls_file_mutex;
+extern void *_gnutls_file_mutex;
 
 struct gnutls_tdb_int default_tdb = {
   store_pubkey,
-- 
1.7.9.4



From martin at martin.st  Mon Jan 21 16:17:12 2013
From: martin at martin.st (Martin Storsjo)
Date: Mon, 21 Jan 2013 17:17:12 +0200
Subject: [gnutls-devel] [PATCH] Include libiconv in Libs.private
Message-ID: <1358781432-48510-1-git-send-email-martin@martin.st>

This makes static linking succeed if the library is configured to
use libiconv.
---
 lib/gnutls.pc.in |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/gnutls.pc.in b/lib/gnutls.pc.in
index c45f8f3..ae95e2f 100644
--- a/lib/gnutls.pc.in
+++ b/lib/gnutls.pc.in
@@ -19,6 +19,6 @@ Description: Transport Security Layer implementation for the GNU system
 URL: http://www.gnu.org/software/gnutls/
 Version: @VERSION@
 Libs: -L${libdir} -lgnutls
-Libs.private: @LTLIBNETTLE@
+Libs.private: @LTLIBNETTLE@ @LTLIBICONV@
 @GNUTLS_REQUIRES_PRIVATE@
 Cflags: -I${includedir}
-- 
1.7.9.4



From martin at martin.st  Mon Jan 21 16:35:10 2013
From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=)
Date: Mon, 21 Jan 2013 17:35:10 +0200 (EET)
Subject: [gnutls-devel] [PATCH] Include libiconv in Libs.private
In-Reply-To: <1358781432-48510-1-git-send-email-martin@martin.st>
References: <1358781432-48510-1-git-send-email-martin@martin.st>
Message-ID: <alpine.DEB.2.00.1301211734230.7889@cone.martin.st>

On Mon, 21 Jan 2013, Martin Storsjo wrote:

> This makes static linking succeed if the library is configured to
> use libiconv.
> ---
> lib/gnutls.pc.in |    2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/gnutls.pc.in b/lib/gnutls.pc.in
> index c45f8f3..ae95e2f 100644
> --- a/lib/gnutls.pc.in
> +++ b/lib/gnutls.pc.in
> @@ -19,6 +19,6 @@ Description: Transport Security Layer implementation for the GNU system
> URL: http://www.gnu.org/software/gnutls/
> Version: @VERSION@
> Libs: -L${libdir} -lgnutls
> -Libs.private: @LTLIBNETTLE@
> +Libs.private: @LTLIBNETTLE@ @LTLIBICONV@
> @GNUTLS_REQUIRES_PRIVATE@
> Cflags: -I${includedir}
> -- 
> 1.7.9.4

Later in the quest of using this, I also stumbled upon the issue that this 
lacks -lz (@LTLIBZ@) as well - it should probably include everything from 
thirdparty_libadd in lib/Makefile.am.

// Martin


From nmav at gnutls.org  Mon Jan 21 18:39:11 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Jan 2013 18:39:11 +0100
Subject: [gnutls-devel] [PATCH] Define _gnutls_file_mutex in
 gnutls_global.c instead of in verify-tofu.c
In-Reply-To: <1358776810-9468-1-git-send-email-martin@martin.st>
References: <1358776810-9468-1-git-send-email-martin@martin.st>
Message-ID: <50FD7D3F.9050704@gnutls.org>

On 01/21/2013 03:00 PM, Martin Storsjo wrote:


> It seems that the linker fails to pull in verify-tofu.o to satisfy
> the undefined reference to _gnutls_file_mutex.o in gnutls_global.o
> unless gnutls_global.o (or any other object file in the link) also
> calls functions that pulls in verify-tofu.o. Since gnutls_global.o
> always is linked in, but verify-tofu.o can be left out unless someone
> calls the functions in it, defining the mutex in gnutls_global.c makes
> sense and simplifies the dependencies.


Applied. Thanks.



From n.mavrogiannopoulos at gmail.com  Mon Jan 21 18:39:45 2013
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 21 Jan 2013 18:39:45 +0100
Subject: [gnutls-devel] [PATCH] Include libiconv in Libs.private
In-Reply-To: <1358781432-48510-1-git-send-email-martin@martin.st>
References: <1358781432-48510-1-git-send-email-martin@martin.st>
Message-ID: <50FD7D61.2060806@gmail.com>

Applied. I've also added the missing libraries.

regards,
Nikos

On 01/21/2013 04:17 PM, Martin Storsjo wrote:

> This makes static linking succeed if the library is configured to
> use libiconv.




From martin at martin.st  Mon Jan 21 23:15:51 2013
From: martin at martin.st (Martin Storsjo)
Date: Tue, 22 Jan 2013 00:15:51 +0200
Subject: [gnutls-devel] [PATCH] Update Libs.private with @LIB_CLOCK_GETTIME@
	as well
Message-ID: <1358806551-55006-1-git-send-email-martin@martin.st>

This is required when linking as static libraries on linux, for
-lrt.
---
 lib/gnutls.pc.in |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/gnutls.pc.in b/lib/gnutls.pc.in
index 3e29c5b..5e2ae11 100644
--- a/lib/gnutls.pc.in
+++ b/lib/gnutls.pc.in
@@ -19,6 +19,6 @@ Description: Transport Security Layer implementation for the GNU system
 URL: http://www.gnu.org/software/gnutls/
 Version: @VERSION@
 Libs: -L${libdir} -lgnutls
-Libs.private: @LTLIBNETTLE@ @LTLIBZ@ @LTLIBINTL@ @LIBSOCKET@ @LTLIBPTHREAD@ @LTLIBICONV@ @P11_KIT_LIBS@ @LIB_SELECT@ @TSS_LIBS@
+Libs.private: @LTLIBNETTLE@ @LTLIBZ@ @LTLIBINTL@ @LIBSOCKET@ @LTLIBPTHREAD@ @LTLIBICONV@ @P11_KIT_LIBS@ @LIB_SELECT@ @TSS_LIBS@ @LIB_CLOCK_GETTIME@
 @GNUTLS_REQUIRES_PRIVATE@
 Cflags: -I${includedir}
-- 
1.7.9.4



From nmav at gnutls.org  Tue Jan 22 20:11:03 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 Jan 2013 20:11:03 +0100
Subject: [gnutls-devel] [PATCH] Update Libs.private with
 @LIB_CLOCK_GETTIME@ as well
In-Reply-To: <1358806551-55006-1-git-send-email-martin@martin.st>
References: <1358806551-55006-1-git-send-email-martin@martin.st>
Message-ID: <50FEE447.7040501@gnutls.org>

On 01/21/2013 11:15 PM, Martin Storsjo wrote:

> This is required when linking as static libraries on linux, for
> -lrt.


Applied thanks.

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-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 jouko.orava at helsinki.fi  Thu Jan 24 02:40:01 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Thu, 24 Jan 2013 03:40:01 +0200 (EET)
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
	requirements
Message-ID: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>

Hi!

GnuTLS is very, very picky about the cipher suite strings it accepts.
I wrote a test patch (attached), UNTESTED, that should relax the
requirements. The main points are:
  - Make '+' prefix optional
  - Allow full cipher names, adding/removing cipher, mac, and kx
    (I suspect it would be better to add all three, but
     when removing, only remove the cipher.
     Currently the patch adds/removes all three.)

The patch also includes a change into lib/gnutls_priority.c:prio_remove(),
that instead of replacing the removed item with the final item in the
array, uses memmove() to shorten the array. For some reason I seem
to believe the order in these priority lists matter.

I'm not exactly sure if this patch is in the right direction,
but I'm hoping to raise some discussion on how to make the
cipher suite string parsing easier for administrators.

Best regards,
  Jouko Orava
-------------- next part --------------
commit 4665b1c975aaf0165bda6c02ae59d0f3a2782040
Author: Jouko Orava <jouko.orava at iki.fi>
Date:   Thu Jan 24 02:46:43 2013 +0200

    Extend cipher suite priority parsing to make '+' prefix optional,
    and to allow users to use the full name strings to add or remove
    cipher, mac, and key exchanges easier.

diff --git a/lib/gnutls_priority.c b/lib/gnutls_priority.c
index 9f47f0a..67c8c9f 100644
--- a/lib/gnutls_priority.c
+++ b/lib/gnutls_priority.c
@@ -547,8 +547,10 @@ prio_remove (priority_st * priority_list, unsigned int algo)
 
   if (pos >= 0)
     {
-      priority_list->priority[pos] = priority_list->priority[i - 1];
-      priority_list->priority[i - 1] = 0;
+      if (pos < i - 1)
+        memmove (priority_list->priority + pos,
+                 priority_list->priority + pos + 1,
+                 (i - 1 - pos) * sizeof priority_list->priority[0]);
       priority_list->algorithms--;
     }
 
@@ -762,6 +764,8 @@ bulk_rmadd_func *func;
  * Special keywords are "!", "-" and "+".
  * "!" or "-" appended with an algorithm will remove this algorithm.
  * "+" appended with an algorithm will add this algorithm.
+ * Algorithms without special keywords, and beginning with an ASCII
+ * letter, will add this algorithm. (Thus, "+" is optional.)
  *
  * Check the GnuTLS manual section "Priority strings" for detailed
  * information.
@@ -792,8 +796,8 @@ gnutls_priority_init (gnutls_priority_t * priority_cache,
 {
   char *broken_list[MAX_ELEMENTS];
   int broken_list_size = 0, i = 0, j;
-  char *darg = NULL;
-  int algo;
+  char *darg = NULL, *s;
+  int algo, add;
   rmadd_func *fn;
   bulk_rmadd_func *bulk_fn;
 
@@ -850,43 +854,52 @@ gnutls_priority_init (gnutls_priority_t * priority_cache,
           continue;
         }
       else if (broken_list[i][0] == '!' || broken_list[i][0] == '+'
-               || broken_list[i][0] == '-')
+               || broken_list[i][0] == '-'
+               || (broken_list[i][0] >= 'A' && broken_list[i] <= 'Z')
+               || (broken_list[i][0] >= 'a' && broken_list[i] <= 'z'))
         {
           if (broken_list[i][0] == '+')
             {
               fn = prio_add;
               bulk_fn = _set_priority;
+              s = &broken_list[i][1];
+              add = 1;
             }
-          else
+          else if (broken_list[i][0] == '!' || broken_list[i][0] == '-')
             {
               fn = prio_remove;
               bulk_fn = _clear_priorities;
+              s = &broken_list[i][1];
+              add = 0;
+            }
+          else
+            {
+              fn = prio_add;
+              bulk_fn = _set_priority;
+              s = &broken_list[i][0];
+              add = 1;
             }
 
-          if (broken_list[i][0] == '+' && check_level(&broken_list[i][1], *priority_cache, 1) != 0)
+          if (add && check_level(s, *priority_cache, 1) != 0)
             {
               continue;
             }
-          else if ((algo =
-               gnutls_mac_get_id (&broken_list[i][1])) != GNUTLS_MAC_UNKNOWN)
+          else if ((algo = gnutls_mac_get_id (s)) != GNUTLS_MAC_UNKNOWN)
             fn (&(*priority_cache)->mac, algo);
-          else if ((algo = gnutls_cipher_get_id (&broken_list[i][1])) !=
-                   GNUTLS_CIPHER_UNKNOWN)
+          else if ((algo = gnutls_cipher_get_id (s)) != GNUTLS_CIPHER_UNKNOWN)
             fn (&(*priority_cache)->cipher, algo);
-          else if ((algo = gnutls_kx_get_id (&broken_list[i][1])) !=
-                   GNUTLS_KX_UNKNOWN)
+          else if ((algo = gnutls_kx_get_id (s)) != GNUTLS_KX_UNKNOWN)
             fn (&(*priority_cache)->kx, algo);
-          else if (strncasecmp (&broken_list[i][1], "VERS-", 5) == 0)
+          else if (strncasecmp (s, "VERS-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "VERS-TLS-ALL", 12) == 0)
+              if (strncasecmp (s, "VERS-TLS-ALL", 12) == 0)
                 {
                   bulk_fn (&(*priority_cache)->protocol,
                                  protocol_priority);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_protocol_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_protocol_get_id (s + 5) !=
                       GNUTLS_VERSION_UNKNOWN)
                     fn (&(*priority_cache)->protocol, algo);
                   else
@@ -894,91 +907,103 @@ gnutls_priority_init (gnutls_priority_t * priority_cache,
 
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "COMP-", 5) == 0)
+          else if (strncasecmp (s, "COMP-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "COMP-ALL", 8) == 0)
+              if (strncasecmp (s, "COMP-ALL", 8) == 0)
                 {
                   bulk_fn (&(*priority_cache)->compression,
                                  comp_priority);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_compression_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_compression_get_id (s + 5)) !=
                       GNUTLS_COMP_UNKNOWN)
                     fn (&(*priority_cache)->compression, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "CURVE-", 6) == 0)
+          else if (strncasecmp (s, "CURVE-", 6) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "CURVE-ALL", 9) == 0)
+              if (strncasecmp (s, "CURVE-ALL", 9) == 0)
                 {
                   bulk_fn (&(*priority_cache)->supported_ecc,
                                  supported_ecc_normal);
                 }
               else
                 {
-                  if ((algo =
-                       _gnutls_ecc_curve_get_id (&broken_list[i][7])) !=
+                  if ((algo = _gnutls_ecc_curve_get_id (s + 6)) !=
                       GNUTLS_ECC_CURVE_INVALID)
                     fn (&(*priority_cache)->supported_ecc, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "CTYPE-", 6) == 0)
+          else if (strncasecmp (s, "CTYPE-", 6) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "CTYPE-ALL", 9) == 0)
+              if (strncasecmp (s, "CTYPE-ALL", 9) == 0)
                 {
                   bulk_fn (&(*priority_cache)->cert_type,
                                  cert_type_priority_all);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_certificate_type_get_id (&broken_list[i][7])) !=
+                  if ((algo = gnutls_certificate_type_get_id (s + 6)) !=
                       GNUTLS_CRT_UNKNOWN)
                     fn (&(*priority_cache)->cert_type, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "SIGN-", 5) == 0)
+          else if (strncasecmp (s, "SIGN-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "SIGN-ALL", 8) == 0)
+              if (strncasecmp (s, "SIGN-ALL", 8) == 0)
                 {
                   bulk_fn (&(*priority_cache)->sign_algo,
                                  sign_priority_default);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_sign_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_sign_get_id (s + 5)) !=
                       GNUTLS_SIGN_UNKNOWN)
                     fn (&(*priority_cache)->sign_algo, algo);
                   else
                     goto error;
                 }
             }
-          else if (strncasecmp (&broken_list[i][1], "MAC-ALL", 7) == 0)
+          else if (strncasecmp (s, "MAC-ALL", 7) == 0)
             {
                   bulk_fn (&(*priority_cache)->mac,
                                 mac_priority_normal);
             }
-          else if (strncasecmp (&broken_list[i][1], "CIPHER-ALL", 10) == 0)
+          else if (strncasecmp (s, "CIPHER-ALL", 10) == 0)
             {
                   bulk_fn (&(*priority_cache)->cipher,
                                 cipher_priority_normal);
             }
-          else if (strncasecmp (&broken_list[i][1], "KX-ALL", 6) == 0)
+          else if (strncasecmp (s, "KX-ALL", 6) == 0)
             {
                   bulk_fn (&(*priority_cache)->kx,
                                 kx_priority_secure);
             }
           else
-            goto error;
+            {
+              for (j = 0; cs_algorithms[j].name != NULL; j++)
+                {
+                  if (strcasecmp (s, cs_algorithms[j].name + 7) == 0)
+                    {
+                      fn (&(*priority_cache)->mac,
+                          cs_algorithms[j].mac_algorithm);
+                      fn (&(*priority_cache)->cipher,
+                          cs_algorithms[j].cipher_algorithm);
+                      fn (&(*priority_cache)->kx,
+                          cs_algorithms[j].kx_algorithm);
+                      break;
+                    }
+                }
+              if (cs_algorithms[j].name == NULL)
+                goto error;
+            }
         }
       else if (broken_list[i][0] == '%')
         {

From tim.ruehsen at gmx.de  Fri Jan 25 17:24:01 2013
From: tim.ruehsen at gmx.de (Tim =?utf-8?q?R=C3=BChsen?=)
Date: Fri, 25 Jan 2013 17:24:01 +0100
Subject: [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 nmav at gnutls.org  Fri Jan 25 21:37:06 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Jan 2013 21:37:06 +0100
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
Message-ID: <5102ECF2.80801@gnutls.org>

On 01/24/2013 02:40 AM, Jouko Orava wrote:

> Hi!
> 
> GnuTLS is very, very picky about the cipher suite strings it accepts.
> I wrote a test patch (attached), UNTESTED, that should relax the
> requirements. The main points are:


Hello Jouko,

 I think the idea of simplifying the rules is a nice one. Some comments
on the specific changes.

>   - Make '+' prefix optional

Nice.

>   - Allow full cipher names, adding/removing cipher, mac, and kx
>     (I suspect it would be better to add all three, but
>      when removing, only remove the cipher.
>      Currently the patch adds/removes all three.)


This is tricky. Although I don't think we are going to have a cipher
called SHA1, I was afraid of collisions and that's why we have this
awkward format. E.g. what does the +NULL mean? the NULL cipher? or
compression? How could you handle that?

> The patch also includes a change into lib/gnutls_priority.c:prio_remove(),
> that instead of replacing the removed item with the final item in the
> array, uses memmove() to shorten the array. For some reason I seem
> to believe the order in these priority lists matter.


Indeed, even if it comes at the cost of memmove :(

regards,
Nikos


From dkg at fifthhorseman.net  Sat Jan 26 05:51:32 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 25 Jan 2013 23:51:32 -0500
Subject: [gnutls-devel] why is gnutls_rehandshake() only for use by servers?
Message-ID: <87r4l88s2z.fsf@alice.fifthhorseman.net>

Hi GnuTLS folks--

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

documents gnutls_rehandshake, and it suggests:

> This function will renegotiate security parameters with the
> client. This should only be called in case of a server.

However, the TLS 1.2 RFC section that describes Client Hello seems to
suggest that a client can initiate a re-handshake as well:

  https://tools.ietf.org/html/rfc5246#section-7.4.1.2 

> The client can also send a ClientHello in response to a HelloRequest
> or on its own initiative in order to renegotiate the security
> parameters in an existing connection.

What should a GnuTLS-based TLS client do if it wants to initiate a
renegotiation?

I'm probably missing something obvious, so please don't be afraid to
spell it out :)

Regards,

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

From jouko.orava at helsinki.fi  Sat Jan 26 06:38:44 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Sat, 26 Jan 2013 07:38:44 +0200 (EET)
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <5102ECF2.80801@gnutls.org>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
Message-ID: <alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>

> I think the idea of simplifying the rules is a nice one.

Thanks!

Perhaps the lib/gnutls_priority.c:prio_remove() and optional "+" in
priority strings should be separated into simpler patches for now?
Suggested but untested patches are attached.

I'll post a separate message expanding on my ideas for enhancing the
priority string parsing.

> >   - Allow full cipher names, adding/removing cipher, mac, and kx
>
> This is tricky. Although I don't think we are going to have a cipher
> called SHA1, I was afraid of collisions and that's why we have this
> awkward format. E.g. what does the +NULL mean? the NULL cipher? or
> compression? How could you handle that?

No, I meant that users seem to expect being able to specify e.g.
TLS_RSA_AES_256_CBC_SHA1 as a priority string. The untested patch
is supposed to detect that string as it matches the name entry in
cs_algorithms[], and add the cipher, mac, and kx from that entry
to the respective priority lists.

In other words, priority string
	TLS_RSA_AES_256_CBC_SHA1
should have the same effect as
	+RSA:+AES_256_CBC:+SHA1
(This would be based on matching to a cs_algorithms[] name,
 and using the cipher/mac/kx fields in that entry,
 not splitting or parsing the string itself.)

I do keenly understand it is paramount to not change the
interpretation of existing valid GnuTLS priority strings.
I only wanted to add new, unambiguous strings the parser
would recognize, not change existing interpretations or
risk confusion.

Best regards,
  Jouko
-------------- next part --------------
This patch makes '+' prefix optional in priority strings.

diff -Naur gnutls.orig/lib/gnutls_priority.c gnutls.new/lib/gnutls_priority.c
--- gnutls.orig/lib/gnutls_priority.c	2013-01-26 05:58:18.948730334 +0200
+++ gnutls.new/lib/gnutls_priority.c	2013-01-26 07:21:48.763014539 +0200
@@ -792,8 +794,8 @@
 {
   char *broken_list[MAX_ELEMENTS];
   int broken_list_size = 0, i = 0, j;
-  char *darg = NULL;
-  int algo;
+  char *darg = NULL, *part;
+  int algo, op;
   rmadd_func *fn;
   bulk_rmadd_func *bulk_fn;
 
@@ -849,44 +851,56 @@
         {
           continue;
         }
-      else if (broken_list[i][0] == '!' || broken_list[i][0] == '+'
-               || broken_list[i][0] == '-')
+      else if (broken_list[i][0] == '!' || broken_list[i][0] == '-'
+               || (broken_list[i][0] >= 'A' && broken_list[i][0] <= 'Z')
+               || (broken_list[i][0] >= 'a' && broken_list[i][0] <= 'z')
+               || broken_list[i][0] == '+')
         {
           if (broken_list[i][0] == '+')
             {
               fn = prio_add;
               bulk_fn = _set_priority;
+              op = '+';
+              part = &broken_list[i][1];
             }
-          else
+          else if (broken_list[i][0] == '!' || broken_list[i][0] == '-')
             {
               fn = prio_remove;
               bulk_fn = _clear_priorities;
+              op = '-';
+              part = &broken_list[i][1];
+            }
+          else
+            {
+              fn = prio_add;
+              bulk_fn = _set_priority;
+              op = '+';
+              part = &broken_list[i][0];
             }
 
-          if (broken_list[i][0] == '+' && check_level(&broken_list[i][1], *priority_cache, 1) != 0)
+          if (op == '+' && check_level(part, *priority_cache, 1) != 0)
             {
               continue;
             }
-          else if ((algo =
-               gnutls_mac_get_id (&broken_list[i][1])) != GNUTLS_MAC_UNKNOWN)
+          else if ((algo = gnutls_mac_get_id (part)) !=
+                   GNUTLS_MAC_UNKNOWN)
             fn (&(*priority_cache)->mac, algo);
-          else if ((algo = gnutls_cipher_get_id (&broken_list[i][1])) !=
+          else if ((algo = gnutls_cipher_get_id (part)) !=
                    GNUTLS_CIPHER_UNKNOWN)
             fn (&(*priority_cache)->cipher, algo);
-          else if ((algo = gnutls_kx_get_id (&broken_list[i][1])) !=
+          else if ((algo = gnutls_kx_get_id (part)) !=
                    GNUTLS_KX_UNKNOWN)
             fn (&(*priority_cache)->kx, algo);
-          else if (strncasecmp (&broken_list[i][1], "VERS-", 5) == 0)
+          else if (strncasecmp (part, "VERS-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "VERS-TLS-ALL", 12) == 0)
+              if (strcasecmp (part, "VERS-TLS-ALL") == 0)
                 {
                   bulk_fn (&(*priority_cache)->protocol,
                                  protocol_priority);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_protocol_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_protocol_get_id (part)) !=
                       GNUTLS_VERSION_UNKNOWN)
                     fn (&(*priority_cache)->protocol, algo);
                   else
@@ -894,85 +908,81 @@
 
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "COMP-", 5) == 0)
+          else if (strncasecmp (part, "COMP-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "COMP-ALL", 8) == 0)
+              if (strcasecmp (part, "COMP-ALL") == 0)
                 {
                   bulk_fn (&(*priority_cache)->compression,
                                  comp_priority);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_compression_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_compression_get_id (part + 5)) !=
                       GNUTLS_COMP_UNKNOWN)
                     fn (&(*priority_cache)->compression, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "CURVE-", 6) == 0)
+          else if (strncasecmp (part, "CURVE-", 6) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "CURVE-ALL", 9) == 0)
+              if (strcasecmp (part, "CURVE-ALL") == 0)
                 {
                   bulk_fn (&(*priority_cache)->supported_ecc,
                                  supported_ecc_normal);
                 }
               else
                 {
-                  if ((algo =
-                       _gnutls_ecc_curve_get_id (&broken_list[i][7])) !=
+                  if ((algo = _gnutls_ecc_curve_get_id (part + 6)) !=
                       GNUTLS_ECC_CURVE_INVALID)
                     fn (&(*priority_cache)->supported_ecc, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "CTYPE-", 6) == 0)
+          else if (strncasecmp (part, "CTYPE-", 6) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "CTYPE-ALL", 9) == 0)
+              if (strcasecmp (part, "CTYPE-ALL") == 0)
                 {
                   bulk_fn (&(*priority_cache)->cert_type,
                                  cert_type_priority_all);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_certificate_type_get_id (&broken_list[i][7])) !=
+                  if ((algo = gnutls_certificate_type_get_id (part + 6)) !=
                       GNUTLS_CRT_UNKNOWN)
                     fn (&(*priority_cache)->cert_type, algo);
                   else
                     goto error;
                 }
             }                   /* now check if the element is something like -ALGO */
-          else if (strncasecmp (&broken_list[i][1], "SIGN-", 5) == 0)
+          else if (strncasecmp (part, "SIGN-", 5) == 0)
             {
-              if (strncasecmp (&broken_list[i][1], "SIGN-ALL", 8) == 0)
+              if (strcasecmp (part, "SIGN-ALL") == 0)
                 {
                   bulk_fn (&(*priority_cache)->sign_algo,
                                  sign_priority_default);
                 }
               else
                 {
-                  if ((algo =
-                       gnutls_sign_get_id (&broken_list[i][6])) !=
+                  if ((algo = gnutls_sign_get_id (part + 5)) !=
                       GNUTLS_SIGN_UNKNOWN)
                     fn (&(*priority_cache)->sign_algo, algo);
                   else
                     goto error;
                 }
             }
-          else if (strncasecmp (&broken_list[i][1], "MAC-ALL", 7) == 0)
+          else if (strcasecmp (part, "MAC-ALL") == 0)
             {
                   bulk_fn (&(*priority_cache)->mac,
                                 mac_priority_normal);
             }
-          else if (strncasecmp (&broken_list[i][1], "CIPHER-ALL", 10) == 0)
+          else if (strcasecmp (part, "CIPHER-ALL") == 0)
             {
                   bulk_fn (&(*priority_cache)->cipher,
                                 cipher_priority_normal);
             }
-          else if (strncasecmp (&broken_list[i][1], "KX-ALL", 6) == 0)
+          else if (strcasecmp (part, "KX-ALL") == 0)
             {
                   bulk_fn (&(*priority_cache)->kx,
                                 kx_priority_secure);
@@ -982,70 +992,43 @@
         }
       else if (broken_list[i][0] == '%')
         {
-          if (strcasecmp (&broken_list[i][1], "COMPAT") == 0)
+          part = &broken_list[i][1];
+          if (strcasecmp (part, "COMPAT") == 0)
             {
               ENABLE_COMPAT((*priority_cache));
             }
-          else if (strcasecmp (&broken_list[i][1], "NO_EXTENSIONS") == 0)
-            {
-              (*priority_cache)->no_extensions = 1;
-            }
-          else if (strcasecmp (&broken_list[i][1], "STATELESS_COMPRESSION") == 0)
-            {
-              (*priority_cache)->stateless_compression = 1;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "VERIFY_ALLOW_SIGN_RSA_MD5") == 0)
+          else if (strcasecmp (part, "VERIFY_ALLOW_SIGN_RSA_MD5") == 0)
             {
               prio_add (&(*priority_cache)->sign_algo, GNUTLS_SIGN_RSA_MD5);
               (*priority_cache)->additional_verify_flags |=
                 GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5;
             }
-          else if (strcasecmp (&broken_list[i][1],
-                               "VERIFY_DISABLE_CRL_CHECKS") == 0)
-            {
-              (*priority_cache)->additional_verify_flags |=
-                GNUTLS_VERIFY_DISABLE_CRL_CHECKS;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "SSL3_RECORD_VERSION") == 0)
+          else if (strcasecmp (part, "NO_EXTENSIONS") == 0)
+            (*priority_cache)->no_extensions = 1;
+          else if (strcasecmp (part, "STATELESS_COMPRESSION") == 0)
+            (*priority_cache)->stateless_compression = 1;
+          else if (strcasecmp (part, "VERIFY_DISABLE_CRL_CHECKS") == 0)
+            (*priority_cache)->additional_verify_flags |=
+              GNUTLS_VERIFY_DISABLE_CRL_CHECKS;
+          else if (strcasecmp (part, "SSL3_RECORD_VERSION") == 0)
             (*priority_cache)->ssl3_record_version = 1;
-          else if (strcasecmp (&broken_list[i][1],
-                               "LATEST_RECORD_VERSION") == 0)
+          else if (strcasecmp (part, "LATEST_RECORD_VERSION") == 0)
             (*priority_cache)->ssl3_record_version = 0;
-          else if (strcasecmp (&broken_list[i][1],
-                               "VERIFY_ALLOW_X509_V1_CA_CRT") == 0)
+          else if (strcasecmp (part, "VERIFY_ALLOW_X509_V1_CA_CRT") == 0)
             (*priority_cache)->additional_verify_flags |=
               GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
-          else if (strcasecmp (&broken_list[i][1],
-                               "UNSAFE_RENEGOTIATION") == 0)
-            {
-              (*priority_cache)->sr = SR_UNSAFE;
-            }
-          else if (strcasecmp (&broken_list[i][1], "SAFE_RENEGOTIATION") == 0)
-            {
-              (*priority_cache)->sr = SR_SAFE;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "PARTIAL_RENEGOTIATION") == 0)
-            {
-              (*priority_cache)->sr = SR_PARTIAL;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "DISABLE_SAFE_RENEGOTIATION") == 0)
-            {
-              (*priority_cache)->sr = SR_DISABLED;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "SERVER_PRECEDENCE") == 0)
-            {
-              (*priority_cache)->server_precedence = 1;
-            }
-          else if (strcasecmp (&broken_list[i][1],
-                               "NEW_PADDING") == 0)
-            {
-              (*priority_cache)->new_record_padding = 1;
-            }
+          else if (strcasecmp (part, "UNSAFE_RENEGOTIATION") == 0)
+            (*priority_cache)->sr = SR_UNSAFE;
+          else if (strcasecmp (part, "SAFE_RENEGOTIATION") == 0)
+            (*priority_cache)->sr = SR_SAFE;
+          else if (strcasecmp (part, "PARTIAL_RENEGOTIATION") == 0)
+            (*priority_cache)->sr = SR_PARTIAL;
+          else if (strcasecmp (part, "DISABLE_SAFE_RENEGOTIATION") == 0)
+            (*priority_cache)->sr = SR_DISABLED;
+          else if (strcasecmp (part, "SERVER_PRECEDENCE") == 0)
+            (*priority_cache)->server_precedence = 1;
+          else if (strcasecmp (part, "NEW_PADDING") == 0)
+            (*priority_cache)->new_record_padding = 1;
           else
             goto error;
         }
-------------- next part --------------
This patch changes lib/gnutls_priority.c:prio_remove() so that
instead of replacing the removed priority with the final priority,
the order of the priorities is kept intact by moving the entire tail
of the list, if necessary.

diff -Naur gnutls.orig/lib/gnutls_priority.c gnutls.new/lib/gnutls_priority.c
--- gnutls.orig/lib/gnutls_priority.c	2013-01-26 05:58:18.948730334 +0200
+++ gnutls.new/lib/gnutls_priority.c	2013-01-26 07:21:48.763014539 +0200
@@ -547,8 +547,10 @@
 
   if (pos >= 0)
     {
-      priority_list->priority[pos] = priority_list->priority[i - 1];
-      priority_list->priority[i - 1] = 0;
+      if (pos < i - 1)
+        memmove(priority_list->priority + pos + 1,
+                priority_list->priority + pos,
+                (i - 1 - pos) * sizeof priority_list->priority[0]);
       priority_list->algorithms--;
     }
 


From dkg at fifthhorseman.net  Sat Jan 26 05:59:55 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 25 Jan 2013 23:59:55 -0500
Subject: [gnutls-devel] why is gnutls_rehandshake() only for use by
	servers?
In-Reply-To: <87r4l88s2z.fsf@alice.fifthhorseman.net>
References: <87r4l88s2z.fsf@alice.fifthhorseman.net>
Message-ID: <87obgc8rp0.fsf@alice.fifthhorseman.net>

On Fri 2013-01-25 23:51:32 -0500, Daniel Kahn Gillmor wrote:

> What should a GnuTLS-based TLS client do if it wants to initiate a
> renegotiation?
>
> I'm probably missing something obvious, so please don't be afraid to
> spell it out :)

OK, i'm going to answer my own question: i think the client should just
invoke gnutls_handshake() directly.  I'm not sure why that didn't occur
to me earlier.  So in RFC-speak, gnutls_rehandshake() is basically "Send
a HelloRequest Message".

Sorry for the noise,

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

From nmav at gnutls.org  Sat Jan 26 11:24:38 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jan 2013 11:24:38 +0100
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
Message-ID: <5103AEE6.6050605@gnutls.org>

On 01/26/2013 06:38 AM, Jouko Orava wrote:

>> I think the idea of simplifying the rules is a nice one.
> 
> Thanks!
> 
> Perhaps the lib/gnutls_priority.c:prio_remove() and optional "+" in
> priority strings should be separated into simpler patches for now?


Yes that would be great.

> Suggested but untested patches are attached.


Ouch. I cannot test them now (may take some time), but if you add a test
in tests/ would speed up things. The test can simply use gnutls-cli -l
--priority XXX, for few typical strings and some corner cases, and
verify that the expected values are present.

 
> I'll post a separate message expanding on my ideas for enhancing the
> priority string parsing.

>>>   - Allow full cipher names, adding/removing cipher, mac, and kx

>> This is tricky. Although I don't think we are going to have a cipher
>> called SHA1, I was afraid of collisions and that's why we have this
>> awkward format. E.g. what does the +NULL mean? the NULL cipher? or
>> compression? How could you handle that?
> 
> No, I meant that users seem to expect being able to specify e.g.
> TLS_RSA_AES_256_CBC_SHA1 as a priority string. The untested patch
> is supposed to detect that string as it matches the name entry in
> cs_algorithms[], and add the cipher, mac, and kx from that entry
> to the respective priority lists.

> In other words, priority string
> 	TLS_RSA_AES_256_CBC_SHA1
> should have the same effect as
> 	+RSA:+AES_256_CBC:+SHA1

That's dangerous. TLS_RSA_AES_256_CBC is very different from +TLS1.0
+RSA +AES-256-CBC. The latter sets the order for the individual ciphers
while the former only for that specific ciphersuite. The idea of setting
priorities for individual ciphers was to avoid even introducing the
notion of ciphersuites to the users/admins. They don't need to know and
everyone (hopefully) knows the individual ciphers.


However, setting specific ciphersuites was my reason for switching to
priority strings (even though it was never implemented). It needs some
work, but the main idea is to generate the list of ciphersuite numbers
in gnutls_priority_set(), and later be used in the handshake.

Now the current behavior is to generate the ciphersuite numbers during
the handshake.

So if ciphersuite names are to be allowed in the string, the above has
to be done.

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-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 jaak.ristioja at cyber.ee  Sat Jan 26 11:45:47 2013
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Sat, 26 Jan 2013 12:45:47 +0200
Subject: [gnutls-devel] Errors building GnuTLS
Message-ID: <5103B3DB.7070602@cyber.ee>

Hello!

I'm trying to build GnuTLS (currently from git master), but I'm getting
some errors. Maybe I'm doing it wrong, but I did

  make autoreconf
  ./configure --disable-libdane --without-p11-kit
--disable-openpgp-authentication --disable-openssl-compatibility
--disable-dtls-srtp-support --disable-srp-authentication
--disable-psk-authentication --prefix=/home/jotik/develop/gnutls/prefix/
--disable-cxx --disable-crywrap --disable-guile --disable-nls
  make

The next error I'm getting is:

make[3]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/lib'
  CC     gnutls_ui.lo
gnutls_ui.c: In function 'gnutls_certificate_get_peers_subkey_id':
gnutls_ui.c:579:18: error: 'struct cert_auth_info_st' has no member
named 'subkey_id'

Please help!

Best regards,
Jaak Ristioja


From jouko.orava at helsinki.fi  Sat Jan 26 12:43:50 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Sat, 26 Jan 2013 13:43:50 +0200 (EET)
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <5103AEE6.6050605@gnutls.org>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
Message-ID: <alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>

> Ouch. I cannot test them now (may take some time), but if you add a test
> in tests/ would speed up things. The test can simply use gnutls-cli -l
> --priority XXX, for few typical strings and some corner cases, and
> verify that the expected values are present.

Right. I did not test the patch yet, because I wanted to make sure the
approach is acceptable first.

I do not want to hurry, because including the optional '+' patch
might make the latter part of the overall task here harder.
Currently, the syntax of the priority strings GnuTLS accepts is
very strict; we still have the option to make it a lot more versatile,
while keeping full compatibility with existing valid strings.
Making '+' optional makes that a lot harder.

> > In other words, priority string
> > 	TLS_RSA_AES_256_CBC_SHA1
> > should have the same effect as
> > 	+RSA:+AES_256_CBC:+SHA1
>
> That's dangerous. TLS_RSA_AES_256_CBC is very different from +TLS1.0
> +RSA +AES-256-CBC. The latter sets the order for the individual ciphers
> while the former only for that specific ciphersuite.

Yes, exactly. That's why I don't think my suggested patch
(that is, perhaps excluding the remove_prio() fix and making '+' optional)
should be considered further at all.

> The idea of setting
> priorities for individual ciphers was to avoid even introducing the
> notion of ciphersuites to the users/admins. They don't need to know and
> everyone (hopefully) knows the individual ciphers.

Unfortunately, in my experience -- meaning looking at what kind of issues
administrators I know are having -- users seems to be aware of
ciphersuites, whereas ciphers, message authentication codes, and key
exchange algorithms are just underlying details they find hard to grasp.

In other words, my experience is the exact opposite. They know the
ciphersuites, but not the individual ciphers or key exchange algorithms
or message authentication schemes, at all.

In practical terms, I see administrators wanting to specify something like
	Use AES_256_CBC with RSA key exchange and SHA256 MAC
	or AES_256_CBC with RSA key exchange and SHA1 MAC
	or CAMELLIA_256_CBC with RSA key exchange and SHA1 MAC
	or fail
	Use TLS1.0 or TLS1.2 (and no other versions)
	without compression
	using x.509 certificates
with the cipher suites taken from recommendations, logs, or internal
documentation. The string they seem to start with looks something like
	TLS_RSA_AES_256_CBC_SHA256:TLS_RSA_AES_256_CBC_SHA1:\
	TLS_RSA_CAMELLIA_256_CBC_SHA1:TLSv1.0:TLSv1.2

Usually the reasons for restricting the cipher suite is not
cryptographical, but practical; related to implementation issues
or organizational politics. (Unfortunate, I know. Actual security
seems to rarely be a true priority; the appearance of security
seems to be enough.)

> However, setting specific ciphersuites was my reason for switching to
> priority strings (even though it was never implemented). It needs some
> work, but the main idea is to generate the list of ciphersuite numbers
> in gnutls_priority_set(), and later be used in the handshake.
>
> Now the current behavior is to generate the ciphersuite numbers during
> the handshake.
>
> So if ciphersuite names are to be allowed in the string, the above has
> to be done.

Ah, I came to the same conclusion, I think.

Basically, the functionality of lib/algorithms/ciphersuites.c:
_gnutls_supported_ciphersuites() should be moved into
lib/gnutls_priority.c:gnutls_priority_init(), with
	priority_st cipher;
	priority_st mac;
	priority_st kx;
in struct gnutls_priority_st replaced with
	priority_st ciphersuite;

The ciphersuite integer keys could be e.g. 1 + index of cs_algorithm
entry, or perhaps (id[0] + 256*id[1]). I have no preference, but
I suspect the former will lead to cleaner code.

Right now, I'm still trying to write a set of logic rules how
the priority string should be parsed, so that it would be intuitive
and easy for users to understand, and construct, preferably
keeping the interpretation of current priority strings intact.
The code is straightforward to write after that.

Another option would be to revamp the priority string parsing
entirely, and move to one that allows reasonable compatibility
with OpenSSL priority strings. A lot of users would love that,
as it would reduce the configuration differences in applications
that can be linked against either one -- for example, OpenLDAP.

A third option would be to enhance the current priority string
parsing, but in a way that allows automatic conversion between
GnuTLS and OpenSSL priority strings, for example with a special
conversion tool. It might have to be linked against both libraries,
to be fully reliable, though, as it might have to examine the
internal data structures to find out if the two are really comparable.

Unless someone has already considered what the logical rules
for parsing the priority string (including cipher suite names)
should be, I shall try to cook some up, and report to the list.

Regards,
  Jouko


From jouko.orava at helsinki.fi  Sat Jan 26 13:53:00 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Sat, 26 Jan 2013 14:53:00 +0200 (EET)
Subject: [gnutls-devel] BNF of priority strings
Message-ID: <alpine.LRH.2.00.1301261446460.30132@ruuvi.it.helsinki.fi>

Hi,

As a step towards "better" priority string logic,
I built a BNF spec of the existing priority strings.

Three comments, though:

  1. Since the NULL MAC string is "MAC-NULL",
     it has to be specified as "MAC-MAC-NULL".
     I don't know if anyone ever needs to specify it, though.

  2. Commit 8d69e1bd9e61cc0b390ca987fd66ec2aad9c0d3c
     states that it adds elliptic curve SECP512R1,
     but it actually adds "SECP521R1". 512 != 521.
     Either the comment or the code is wrong.

  3. All "...-ALL" accept any extra suffix
     (not containing a colon). In other words,
     "CURVE-ALLISON" is the same as "CURVE-ALL",
     as the "...-ALL..." are checked before the
     more specific ones.
     In practice, any name starting with "ALL"
     is impossible to specify.

The BNF for specifying a priority string:

<priority_string> ::= <level>
                    | <level> { ":" <spec> }
                    | <spec> { ":" <spec> }

<level> ::= "NONE"
          | "NORMAL"
          | "PERFORMANCE"
          | "SECURE128"
          | "SECURE192"
          | "SECURE256"
          | "SUITEB128"
          | "SUITEB192"
          | "EXPORT"


<spec> ::= "+" <level>
         | "+" <all>
         | "-" <all> | "!" <all>
         | "+" <cipher>
         | "-" <cipher> | "!" <cipher>
         | "+" <mac>
         | "-" <mac> | "!" <mac>
         | "+" <kx>
         | "-" <kx> | "!" <kx>
         | "+" "VERS-" <vers>
         | "-" "VERS-" <vers> | "!" "VERS-" <vers>
         | "+" "COMP-" <comp>
         | "-" "COMP-" <comp> | "!" "COMP-" <comp>
         | "+" "CURVE-" <curve>
         | "-" "CURVE-" <curve> | "!" "CURVE-" <curve>
         | "+" "CTYPE-" <ctype>
         | "-" "CTYPE-" <ctype> | "!" "CTYPE-" <ctype>
         | "+" "SIGN-" <sign>
         | "-" "SIGN-" <sign> | "!" "SIGN-" <sign>
         | "%" <special>

<all> ::= "VERS-TLS-ALL" [ <padding> ]
        | "COMP-ALL" [ <padding> ]
        | "CURVE-ALL" [ <padding> ]
        | "CTYPE-ALL" [ <padding> ]
        | "SIGN-ALL" [ <padding> ]
        | "MAC-ALL" [ <padding> ]
        | "CIPHER-ALL" [ <padding> ]
        | "KX-ALL" [ <padding> ]

<cipher> ::= "AES-256-CBC"
           | "AES-192-CBC"
           | "AES-128-CBC"
           | "AES-128-GCM"
           | "AES-256-GCM"
           | "ARCFOUR-128"
           | "CAMELLIA-256-CBC"
           | "CAMELLIA-192-CBC"
           | "CAMELLIA-128-CBC"
           | "3DES-CBC"
           | "DES-CBC"
           | "ARCFOUR-40"
           | "RC2-40"
           | "IDEA-PGP-CFB"
           | "3DES-PGP-CFB"
           | "CAST5-PGP-CFB"
           | "BLOWFISH-PGP-CFB"
           | "SAFER-SK128-PGP-CFB"
           | "AES-128-PGP-CFB"
           | "AES-192-PGP-CFB"
           | "AES-256-PGP-CFB"
           | "TWOFISH-PGP-CFB"
           | "NULL"

<mac> ::= "SHA1"
        | "MD5"
        | "SHA256"
        | "SHA384"
        | "SHA512"
        | "SHA224"
        | "AEAD"
        | "MD2"
        | "RIPEMD160"
        | "MAC-NULL"

<kx> ::= "ANON-DH"
       | "ANON-ECDH"
       | "RSA"
       | "RSA-EXPORT"
       | "DHE-RSA"
       | "ECDHE-RSA"
       | "ECDHE-ECDSA"
       | "DHE-DSS"
       | "SRP-DSS"
       | "SRP-RSA"
       | "SRP"
       | "PSK"
       | "DHE-PSK"
       | "ECDHE-PSK"

<vers> ::= "SSL3.0"
         | "TLS1.0"
         | "TLS1.1"
         | "TLS1.2"
         | "DTLS0.9"
         | "DTLS1.0"

<comp> ::= "NULL"
         | "DEFLATE"

<curve> ::= "SECP192R1"
          | "SECP224R1"
          | "SECP256R1"
          | "SECP384R1"
          | "SECP521R1"

<ctype> ::= "X.509" | "X509"
          | "OPENPGP"

<sign> ::= "RSA-SHA1"
         |?"RSA-SHA224"
         | "RSA-SHA256"
         | "RSA-SHA384"
         | "RSA-SHA512"
         | "RSA-RMD160"
         | "DSA-SHA1"
         | "DSA-SHA224"
         | "DSA-SHA256"
         | "RSA-MD5"
         | "RSA-MD2"
         | "ECDSA-SHA1"
         | "ECDSA-SHA224"
         |?"ECDSA-SHA256"
         | "ECDSA-SHA384"
         | "ECDSA-SHA512"
         | "GOST R 34.10-2001"
         | "GOST R 34.10-94"

<special> ::= "COMPAT"
            | "NO_EXTENSIONS"
            | "STATELESS_COMPRESSION"
            | "VERIFY_ALLOW_SIGN_RSA_MD5"
            | "VERIFY_DISABLE_CRL_CHECKS"
            | "SSL3_RECORD_VERSION"
            | "LATEST_RECORD_VERSION"
            | "VERIFY_ALLOW_X509_V1_CA_CRT"
            | "VERIFY_DISABLE_CRL_CHECKS"
            | "SSL3_RECORD_VERSION"
            | "LATEST_RECORD_VERSION"
            | "VERIFY_ALLOW_X509_V1_CA_CRT"
            | "UNSAFE_RENEGOTIATION"
            | "SAFE_RENEGOTIATION"
            | "PARTIAL_RENEGOTIATION"
            | "DISABLE_SAFE_RENEGOTIATION"
            | "SERVER_PRECEDENCE"
            | "NEW_PADDING"

<padding> ::= any number of characters except colon ':'

Regards,
  Jouko Orava


From nmav at gnutls.org  Sat Jan 26 14:00:50 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jan 2013 14:00:50 +0100
Subject: [gnutls-devel] Errors building GnuTLS
In-Reply-To: <5103B3DB.7070602@cyber.ee>
References: <5103B3DB.7070602@cyber.ee>
Message-ID: <5103D382.6090200@gnutls.org>

On 01/26/2013 11:45 AM, Jaak Ristioja wrote:

> Hello!
> 
> I'm trying to build GnuTLS (currently from git master), but I'm getting
> some errors. Maybe I'm doing it wrong, but I did
> 
>   make autoreconf
>   ./configure --disable-libdane --without-p11-kit
> --disable-openpgp-authentication --disable-openssl-compatibility
> --disable-dtls-srtp-support --disable-srp-authentication
> --disable-psk-authentication --prefix=/home/jotik/develop/gnutls/prefix/
> --disable-cxx --disable-crywrap --disable-guile --disable-nls
>   make
> 
> The next error I'm getting is:
> 
> make[3]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/lib'
>   CC     gnutls_ui.lo
> gnutls_ui.c: In function 'gnutls_certificate_get_peers_subkey_id':
> gnutls_ui.c:579:18: error: 'struct cert_auth_info_st' has no member
> named 'subkey_id'


Hello,
 These disable options are not actively maintained and their status
depends on patches received by the ones who actually use it. Usually on
the errors you see, it is sufficient to disable the corresponding
function or code by using and ifdef of the feature it is related to.


I've now fixed the issue you quote. For other issues, or when in doubt
feel free to ask.

regards,
Nikos


From nmav at gnutls.org  Sat Jan 26 14:28:05 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jan 2013 14:28:05 +0100
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
	<alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
Message-ID: <5103D9E5.5030303@gnutls.org>

On 01/26/2013 12:43 PM, Jouko Orava wrote:


>> The idea of setting
>> priorities for individual ciphers was to avoid even introducing the
>> notion of ciphersuites to the users/admins. They don't need to know and
>> everyone (hopefully) knows the individual ciphers.
> Unfortunately, in my experience -- meaning looking at what kind of issues
> administrators I know are having -- users seems to be aware of
> ciphersuites, whereas ciphers, message authentication codes, and key
> exchange algorithms are just underlying details they find hard to grasp.


Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
should be clearly advertised by the applications. Otherwise they are
going to search google on what to put on this priority string field and
end up with obscure strings that make no much sense (that is the
impression I get from watching people configure mod_ssl).

> In other words, my experience is the exact opposite. They know the
> ciphersuites, but not the individual ciphers or key exchange algorithms
> or message authentication schemes, at all.

> In practical terms, I see administrators wanting to specify something like
> 	Use AES_256_CBC with RSA key exchange and SHA256 MAC
> 	or AES_256_CBC with RSA key exchange and SHA1 MAC
> 	or CAMELLIA_256_CBC with RSA key exchange and SHA1 MAC


Do they want to specify that, or do they want to set a certain security
level? I think the reason they try to set that is because of how mod_ssl
expects things. As an administrator I wouldn't want to specify that
stuff. I'd like to specify a certain security level such as SECURE128 or
SECURE192.

[possibly in some later version of gnutls such priority strings should enforce

the acceptable certificate and DH key size - possibly using new strings]

>> So if ciphersuite names are to be allowed in the string, the above has
>> to be done.
> 
> Ah, I came to the same conclusion, I think.
> 
> Basically, the functionality of lib/algorithms/ciphersuites.c:
> _gnutls_supported_ciphersuites() should be moved into
> lib/gnutls_priority.c:gnutls_priority_init(), with
> 	priority_st cipher;
> 	priority_st mac;
> 	priority_st kx;
> in struct gnutls_priority_st replaced with
> 	priority_st ciphersuite;
> 
> The ciphersuite integer keys could be e.g. 1 + index of cs_algorithm
> entry, or perhaps (id[0] + 256*id[1]). I have no preference, but
> I suspect the former will lead to cleaner code.


Yes. Note that during the handshake, the server and the client would
need to process this list and remove the ciphersuites that are not
compatible with their keys (but if an index is used as you propose that
would be pretty efficient).

> Another option would be to revamp the priority string parsing
> entirely, and move to one that allows reasonable compatibility
> with OpenSSL priority strings. A lot of users would love that,
> as it would reduce the configuration differences in applications
> that can be linked against either one -- for example, OpenLDAP.


No, openssl priority strings aren't any better (and are harder to
understand if you know what's going on). OpenLDAP with gnutls is a long
story. They use gnutls but they expect the openssl behavior and API.
Gnutls isn't an LGPL port of openssl. It's another library and I don't
think there is any reason to change that.

> A third option would be to enhance the current priority string
> parsing, but in a way that allows automatic conversion between
> GnuTLS and OpenSSL priority strings, for example with a special
> conversion tool. It might have to be linked against both libraries,
> to be fully reliable, though, as it might have to examine the
> internal data structures to find out if the two are really comparable.


That would be interesting for programs that switched from openssl to
gnutls, but I think this no longer happens. Programs now either start
with gnutls or not. In any case, that again couldn't be part of gnutls.
It could be part of gnutls-openssl library or so.

> Unless someone has already considered what the logical rules
> for parsing the priority string (including cipher suite names)
> should be, I shall try to cook some up, and report to the list.


Thank you.

regards,
Nikos


From nmav at gnutls.org  Sat Jan 26 14:35:19 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jan 2013 14:35:19 +0100
Subject: [gnutls-devel] BNF of priority strings
In-Reply-To: <alpine.LRH.2.00.1301261446460.30132@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301261446460.30132@ruuvi.it.helsinki.fi>
Message-ID: <5103DB97.1000207@gnutls.org>

On 01/26/2013 01:53 PM, Jouko Orava wrote:

> Hi,
> 
> As a step towards "better" priority string logic,
> I built a BNF spec of the existing priority strings.
> 
> Three comments, though:
> 
>   1. Since the NULL MAC string is "MAC-NULL",
>      it has to be specified as "MAC-MAC-NULL".
>      I don't know if anyone ever needs to specify it, though.


Nice catch, but it was intentional. MAC-NULL cannot be set in TLS (there
are no ciphersuites with such MAC).

>   2. Commit 8d69e1bd9e61cc0b390ca987fd66ec2aad9c0d3c
>      states that it adds elliptic curve SECP512R1,
>      but it actually adds "SECP521R1". 512 != 521.
>      Either the comment or the code is wrong.


It's a typo on the commit message. The curve is 521 bits long.

>   3. All "...-ALL" accept any extra suffix
>      (not containing a colon). In other words,
>      "CURVE-ALLISON" is the same as "CURVE-ALL",
>      as the "...-ALL..." are checked before the
>      more specific ones.
>      In practice, any name starting with "ALL"
>      is impossible to specify.


I think that this could be easily changed, or not?

> The BNF for specifying a priority string:


Looks correct to me.

An interesting use for your BNF description would be to be used to check
the current priority parsing code. That would be if there is a tool that
takes BNF and outputs valid random strings.

regards,
Nikos


From will at thaiglish.com  Sat Jan 26 18:40:23 2013
From: will at thaiglish.com (William McGovern)
Date: Sat, 26 Jan 2013 09:40:23 -0800
Subject: [gnutls-devel] gnutls_cipher_decrypt2() is broken for AES-GCM
Message-ID: <6F242550-1097-40C6-8DA6-BAE952422B63@thaiglish.com>

Hello,

It seems that gnutls_cipher_decrypt2() does not work for the AES-GCM
ciphers and does not generate any data in the output buffer or return
any error code. In-place decryption of the same ciphertext with
gnutls_cipher_decrypt() works correctly.

This is seen with GnuTLS 3.1.6 on Mac OS X 10.8.2 as installed
by homebrew on platforms with and without AES-NI support.

I believe my code is correct but let me know if I missed anything :-)

- Will

Here is a test case that illustrates the defect:

/*
 * Test case illustrating bug in gnutls_cipher_decrypt2() with AES-GCM.
 *
 * VERSION: GnuTLS 3.1.6
 * 
 * DEFECT: The gnutls_cipher_decrypt2() function does not correctly decrypt
 *         data for the GNUTLS_CIPHER_AES_[128|256]_GCM
 *         ciphers. The output buffer for the decrypted data is not modified.
 *
 *  NOTES: In-place decryption using gnutls_cipher_decrypt() on the same
 *         ciphertext generated by gnutls_cipher_encrypt2() correctly
 *         decrypts the data in-place. Also, switching the cipher to CBC
 *         mode (and commenting out the AAD and AuthTag calls) shows that
 *         gnutls_cipher_decrypt2() works for CBC. It appears that the
 *         defect is isolated to the GCM mode with or without AES-NI.
 *
 *   ENVS: Mac OS X 10.8.2 : Intel Core i7-2600 (AES-NI)
 *         Mac OS X 10.8.2 : Intel Xeon X5482   (No AES-NI)
 *
 *  BUILD: cc -Wall -o test_case test_case.c -lgnutls
 *    RUN: ./test_case
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <gnutls/gnutls.h>
#include <gnutls/crypto.h>

#define CIPHER GNUTLS_CIPHER_AES_128_GCM

#define KEY_LEN   32
#define IV_LEN    12
#define AAD_LEN   64
#define DATA_LEN  1024
#define TAG_LEN   16

int
main(void)
{
    gnutls_cipher_hd_t h;
    gnutls_datum_t     keyDatum, ivDatum;
    void              *key, *iv, *aad, *pt1, *pt2, *ct, *tag1, *tag2;
    int                rc;

    key  = malloc(KEY_LEN);
    iv   = malloc(IV_LEN);
    aad  = malloc(AAD_LEN);
    pt1  = malloc(DATA_LEN);
    pt2  = malloc(DATA_LEN);
    ct   = malloc(DATA_LEN);
    tag1 = malloc(TAG_LEN);
    tag2 = malloc(TAG_LEN);
    assert(key  != NULL);
    assert(iv   != NULL);
    assert(aad  != NULL);
    assert(pt1  != NULL);
    assert(pt2  != NULL);
    assert(ct   != NULL);
    assert(tag1 != NULL);
    assert(tag2 != NULL);

    /* Construct datums for gnutls_cipher_init(). */
    keyDatum.data = key;
    keyDatum.size = KEY_LEN;
    ivDatum.data  = iv;
    ivDatum.size  = IV_LEN;

     /* Initialize input buffers (random) and zero output buffers. */
    gnutls_global_init();
    gnutls_rnd(GNUTLS_RND_RANDOM, key, KEY_LEN);
    gnutls_rnd(GNUTLS_RND_RANDOM, iv,  IV_LEN);
    gnutls_rnd(GNUTLS_RND_RANDOM, aad, AAD_LEN);
    gnutls_rnd(GNUTLS_RND_RANDOM, pt1, DATA_LEN);
    memset(pt2,  0, DATA_LEN);
    memset(tag1, 0, TAG_LEN);
    memset(tag2, 0, TAG_LEN);

    /* Encrypt data from pt1 -> ct */
    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
    assert(rc == 0);
    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_encrypt2(h, pt1, DATA_LEN, ct, DATA_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_tag(h, tag1, TAG_LEN);
    assert(rc == 0);
    gnutls_cipher_deinit(h);

    /* Decrypt data from ct -> pt2 */
    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
    assert(rc == 0);
    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_decrypt2(h, ct, DATA_LEN, pt2, DATA_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
    assert(rc == 0);
    gnutls_cipher_deinit(h);

    /* Verify decrypted data matches original plaintext (pt2 == pt1). */
    if (memcmp(pt1, pt2, DATA_LEN) != 0) {
        fprintf(stderr, "ERROR: Out-of-place decrypted data mismatch\n");
    } else {
        fprintf(stderr, "OK: Out-of-place decrypted data matches\n");
    }
    /* Verify authentication tags match. */
    if (memcmp(tag1, tag2, TAG_LEN) != 0) {
        fprintf(stderr, "ERROR: Out-of-place authentication tag mismatch\n");
    } else {
        fprintf(stderr, "OK: Out-of-place authentication tags match\n");
    }

    /* Decrypt data in-place in ct. */
    memset(tag2, 0, TAG_LEN);
    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
    assert(rc == 0);
    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_decrypt(h, ct, DATA_LEN);
    assert(rc == 0);
    rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
    assert(rc == 0);
    gnutls_cipher_deinit(h);

    /* Verify decrypted data matches original plaintext (pt2 == pt1). */
    if (memcmp(pt1, ct, DATA_LEN) != 0) {
        fprintf(stderr, "ERROR: In-place decrypted data mismatch\n");
    } else {
        fprintf(stderr, "OK: In-place decrypted data matches\n");
    }
 
    /* Verify authentication tags match. */
    if (memcmp(tag1, tag2, TAG_LEN) != 0) {
        fprintf(stderr, "ERROR: In-place authentication tag mismatch\n");
    } else {
        fprintf(stderr, "OK: In-place authentication tags match\n");
    }
    return 0;
}



From will at thaiglish.com  Sat Jan 26 19:26:43 2013
From: will at thaiglish.com (William McGovern)
Date: Sat, 26 Jan 2013 10:26:43 -0800
Subject: [gnutls-devel] gnutls_cipher_decrypt2() is broken for AES-GCM
In-Reply-To: <6F242550-1097-40C6-8DA6-BAE952422B63@thaiglish.com>
References: <6F242550-1097-40C6-8DA6-BAE952422B63@thaiglish.com>
Message-ID: <04304C0E-F0C0-461B-A269-6B92C8EF55AC@thaiglish.com>

Forgot to include the output of this test case:

$ ./test_case 
ERROR: Out-of-place decrypted data mismatch
ERROR: Out-of-place authentication tag mismatch
OK: In-place decrypted data matches
OK: In-place authentication tags match

On Jan 26, 2013, at 9:40 AM, William McGovern <will at thaiglish.com> wrote:

> Hello,
> 
> It seems that gnutls_cipher_decrypt2() does not work for the AES-GCM
> ciphers and does not generate any data in the output buffer or return
> any error code. In-place decryption of the same ciphertext with
> gnutls_cipher_decrypt() works correctly.
> 
> This is seen with GnuTLS 3.1.6 on Mac OS X 10.8.2 as installed
> by homebrew on platforms with and without AES-NI support.
> 
> I believe my code is correct but let me know if I missed anything :-)
> 
> - Will
> 
> Here is a test case that illustrates the defect:
> 
> /*
> * Test case illustrating bug in gnutls_cipher_decrypt2() with AES-GCM.
> *
> * VERSION: GnuTLS 3.1.6
> * 
> * DEFECT: The gnutls_cipher_decrypt2() function does not correctly decrypt
> *         data for the GNUTLS_CIPHER_AES_[128|256]_GCM
> *         ciphers. The output buffer for the decrypted data is not modified.
> *
> *  NOTES: In-place decryption using gnutls_cipher_decrypt() on the same
> *         ciphertext generated by gnutls_cipher_encrypt2() correctly
> *         decrypts the data in-place. Also, switching the cipher to CBC
> *         mode (and commenting out the AAD and AuthTag calls) shows that
> *         gnutls_cipher_decrypt2() works for CBC. It appears that the
> *         defect is isolated to the GCM mode with or without AES-NI.
> *
> *   ENVS: Mac OS X 10.8.2 : Intel Core i7-2600 (AES-NI)
> *         Mac OS X 10.8.2 : Intel Xeon X5482   (No AES-NI)
> *
> *  BUILD: cc -Wall -o test_case test_case.c -lgnutls
> *    RUN: ./test_case
> */
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <assert.h>
> #include <gnutls/gnutls.h>
> #include <gnutls/crypto.h>
> 
> #define CIPHER GNUTLS_CIPHER_AES_128_GCM
> 
> #define KEY_LEN   32
> #define IV_LEN    12
> #define AAD_LEN   64
> #define DATA_LEN  1024
> #define TAG_LEN   16
> 
> int
> main(void)
> {
>    gnutls_cipher_hd_t h;
>    gnutls_datum_t     keyDatum, ivDatum;
>    void              *key, *iv, *aad, *pt1, *pt2, *ct, *tag1, *tag2;
>    int                rc;
> 
>    key  = malloc(KEY_LEN);
>    iv   = malloc(IV_LEN);
>    aad  = malloc(AAD_LEN);
>    pt1  = malloc(DATA_LEN);
>    pt2  = malloc(DATA_LEN);
>    ct   = malloc(DATA_LEN);
>    tag1 = malloc(TAG_LEN);
>    tag2 = malloc(TAG_LEN);
>    assert(key  != NULL);
>    assert(iv   != NULL);
>    assert(aad  != NULL);
>    assert(pt1  != NULL);
>    assert(pt2  != NULL);
>    assert(ct   != NULL);
>    assert(tag1 != NULL);
>    assert(tag2 != NULL);
> 
>    /* Construct datums for gnutls_cipher_init(). */
>    keyDatum.data = key;
>    keyDatum.size = KEY_LEN;
>    ivDatum.data  = iv;
>    ivDatum.size  = IV_LEN;
> 
>     /* Initialize input buffers (random) and zero output buffers. */
>    gnutls_global_init();
>    gnutls_rnd(GNUTLS_RND_RANDOM, key, KEY_LEN);
>    gnutls_rnd(GNUTLS_RND_RANDOM, iv,  IV_LEN);
>    gnutls_rnd(GNUTLS_RND_RANDOM, aad, AAD_LEN);
>    gnutls_rnd(GNUTLS_RND_RANDOM, pt1, DATA_LEN);
>    memset(pt2,  0, DATA_LEN);
>    memset(tag1, 0, TAG_LEN);
>    memset(tag2, 0, TAG_LEN);
> 
>    /* Encrypt data from pt1 -> ct */
>    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
>    assert(rc == 0);
>    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_encrypt2(h, pt1, DATA_LEN, ct, DATA_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_tag(h, tag1, TAG_LEN);
>    assert(rc == 0);
>    gnutls_cipher_deinit(h);
> 
>    /* Decrypt data from ct -> pt2 */
>    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
>    assert(rc == 0);
>    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_decrypt2(h, ct, DATA_LEN, pt2, DATA_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
>    assert(rc == 0);
>    gnutls_cipher_deinit(h);
> 
>    /* Verify decrypted data matches original plaintext (pt2 == pt1). */
>    if (memcmp(pt1, pt2, DATA_LEN) != 0) {
>        fprintf(stderr, "ERROR: Out-of-place decrypted data mismatch\n");
>    } else {
>        fprintf(stderr, "OK: Out-of-place decrypted data matches\n");
>    }
>    /* Verify authentication tags match. */
>    if (memcmp(tag1, tag2, TAG_LEN) != 0) {
>        fprintf(stderr, "ERROR: Out-of-place authentication tag mismatch\n");
>    } else {
>        fprintf(stderr, "OK: Out-of-place authentication tags match\n");
>    }
> 
>    /* Decrypt data in-place in ct. */
>    memset(tag2, 0, TAG_LEN);
>    rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
>    assert(rc == 0);
>    rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_decrypt(h, ct, DATA_LEN);
>    assert(rc == 0);
>    rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
>    assert(rc == 0);
>    gnutls_cipher_deinit(h);
> 
>    /* Verify decrypted data matches original plaintext (pt2 == pt1). */
>    if (memcmp(pt1, ct, DATA_LEN) != 0) {
>        fprintf(stderr, "ERROR: In-place decrypted data mismatch\n");
>    } else {
>        fprintf(stderr, "OK: In-place decrypted data matches\n");
>    }
> 
>    /* Verify authentication tags match. */
>    if (memcmp(tag1, tag2, TAG_LEN) != 0) {
>        fprintf(stderr, "ERROR: In-place authentication tag mismatch\n");
>    } else {
>        fprintf(stderr, "OK: In-place authentication tags match\n");
>    }
>    return 0;
> }
> 
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel
> 



From will at thaiglish.com  Sat Jan 26 19:04:49 2013
From: will at thaiglish.com (William McGovern)
Date: Sat, 26 Jan 2013 10:04:49 -0800
Subject: [gnutls-devel] gnutls_cipher_decrypt2() is broken for AES-GCM
Message-ID: <0C19205C-DB31-4D9A-887C-8280D8455953@thaiglish.com>

Apologies if this is a double post. I sent this to bugs at gnutls.org but didn't
see the message show up on the list but maybe the list archiver has not
caught up yet...

Hello,

It seems that gnutls_cipher_decrypt2() does not work for the AES-GCM
ciphers and does not generate any data in the output buffer or return
any error code. In-place decryption of the same ciphertext with
gnutls_cipher_decrypt() works correctly.

This is seen with GnuTLS 3.1.6 on Mac OS X 10.8.2 as installed
by homebrew on platforms with and without AES-NI support.

I believe my code is correct but let me know if I missed anything :-)

- Will

Here is a test case that illustrates the defect:

/*
* Test case illustrating bug in gnutls_cipher_decrypt2() with AES-GCM.
*
* VERSION: GnuTLS 3.1.6
* 
* DEFECT: The gnutls_cipher_decrypt2() function does not correctly decrypt
*         data for the GNUTLS_CIPHER_AES_[128|256]_GCM
*         ciphers. The output buffer for the decrypted data is not modified.
*
*  NOTES: In-place decryption using gnutls_cipher_decrypt() on the same
*         ciphertext generated by gnutls_cipher_encrypt2() correctly
*         decrypts the data in-place. Also, switching the cipher to CBC
*         mode (and commenting out the AAD and AuthTag calls) shows that
*         gnutls_cipher_decrypt2() works for CBC. It appears that the
*         defect is isolated to the GCM mode with or without AES-NI.
*
*   ENVS: Mac OS X 10.8.2 : Intel Core i7-2600 (AES-NI)
*         Mac OS X 10.8.2 : Intel Xeon X5482   (No AES-NI)
*
*  BUILD: cc -Wall -o test_case test_case.c -lgnutls
*    RUN: ./test_case
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <gnutls/gnutls.h>
#include <gnutls/crypto.h>

#define CIPHER GNUTLS_CIPHER_AES_128_GCM

#define KEY_LEN   32
#define IV_LEN    12
#define AAD_LEN   64
#define DATA_LEN  1024
#define TAG_LEN   16

int
main(void)
{
   gnutls_cipher_hd_t h;
   gnutls_datum_t     keyDatum, ivDatum;
   void              *key, *iv, *aad, *pt1, *pt2, *ct, *tag1, *tag2;
   int                rc;

   key  = malloc(KEY_LEN);
   iv   = malloc(IV_LEN);
   aad  = malloc(AAD_LEN);
   pt1  = malloc(DATA_LEN);
   pt2  = malloc(DATA_LEN);
   ct   = malloc(DATA_LEN);
   tag1 = malloc(TAG_LEN);
   tag2 = malloc(TAG_LEN);
   assert(key  != NULL);
   assert(iv   != NULL);
   assert(aad  != NULL);
   assert(pt1  != NULL);
   assert(pt2  != NULL);
   assert(ct   != NULL);
   assert(tag1 != NULL);
   assert(tag2 != NULL);

   /* Construct datums for gnutls_cipher_init(). */
   keyDatum.data = key;
   keyDatum.size = KEY_LEN;
   ivDatum.data  = iv;
   ivDatum.size  = IV_LEN;

    /* Initialize input buffers (random) and zero output buffers. */
   gnutls_global_init();
   gnutls_rnd(GNUTLS_RND_RANDOM, key, KEY_LEN);
   gnutls_rnd(GNUTLS_RND_RANDOM, iv,  IV_LEN);
   gnutls_rnd(GNUTLS_RND_RANDOM, aad, AAD_LEN);
   gnutls_rnd(GNUTLS_RND_RANDOM, pt1, DATA_LEN);
   memset(pt2,  0, DATA_LEN);
   memset(tag1, 0, TAG_LEN);
   memset(tag2, 0, TAG_LEN);

   /* Encrypt data from pt1 -> ct */
   rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
   assert(rc == 0);
   rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_encrypt2(h, pt1, DATA_LEN, ct, DATA_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_tag(h, tag1, TAG_LEN);
   assert(rc == 0);
   gnutls_cipher_deinit(h);

   /* Decrypt data from ct -> pt2 */
   rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
   assert(rc == 0);
   rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_decrypt2(h, ct, DATA_LEN, pt2, DATA_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
   assert(rc == 0);
   gnutls_cipher_deinit(h);

   /* Verify decrypted data matches original plaintext (pt2 == pt1). */
   if (memcmp(pt1, pt2, DATA_LEN) != 0) {
       fprintf(stderr, "ERROR: Out-of-place decrypted data mismatch\n");
   } else {
       fprintf(stderr, "OK: Out-of-place decrypted data matches\n");
   }
   /* Verify authentication tags match. */
   if (memcmp(tag1, tag2, TAG_LEN) != 0) {
       fprintf(stderr, "ERROR: Out-of-place authentication tag mismatch\n");
   } else {
       fprintf(stderr, "OK: Out-of-place authentication tags match\n");
   }

   /* Decrypt data in-place in ct. */
   memset(tag2, 0, TAG_LEN);
   rc = gnutls_cipher_init(&h, CIPHER, &keyDatum, &ivDatum);
   assert(rc == 0);
   rc = gnutls_cipher_add_auth(h, aad, AAD_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_decrypt(h, ct, DATA_LEN);
   assert(rc == 0);
   rc = gnutls_cipher_tag(h, tag2, TAG_LEN);
   assert(rc == 0);
   gnutls_cipher_deinit(h);

   /* Verify decrypted data matches original plaintext (pt2 == pt1). */
   if (memcmp(pt1, ct, DATA_LEN) != 0) {
       fprintf(stderr, "ERROR: In-place decrypted data mismatch\n");
   } else {
       fprintf(stderr, "OK: In-place decrypted data matches\n");
   }

   /* Verify authentication tags match. */
   if (memcmp(tag1, tag2, TAG_LEN) != 0) {
       fprintf(stderr, "ERROR: In-place authentication tag mismatch\n");
   } else {
       fprintf(stderr, "OK: In-place authentication tags match\n");
   }
   return 0;
}



From jouko.orava at helsinki.fi  Sun Jan 27 08:45:08 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Sun, 27 Jan 2013 09:45:08 +0200 (EET)
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <5103D9E5.5030303@gnutls.org>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
	<alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
	<5103D9E5.5030303@gnutls.org>
Message-ID: <alpine.LRH.2.00.1301270855550.25179@ruuvi.it.helsinki.fi>

On Sat, 26 Jan 2013, Nikos Mavrogiannopoulos wrote:
> Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
> should be clearly advertised by the applications.

Right, and that's what I too recommend for users. For example, for the
OpenLDAP bug I recently reported (libldap crashes in starttls if linked
against GnuTLS and given an invalid priority string), I suggest using
"SECURE256" in particular.

The problems with priority strings only occur when there are extraneous
requirements, for example to use a specific cipher suite, or to not use
a specific ciphers or cipher suites.
Often these are political, not technical.

> Do they want to specify that, or do they want to set a certain security
> level? I think the reason they try to set that is because of how mod_ssl
> expects things. As an administrator I wouldn't want to specify that
> stuff. I'd like to specify a certain security level such as SECURE128 or
> SECURE192.

A vast majority of users should ever use the level in the priority
strings, I agree.

However, when that is not sufficient, yes, the users do wish to specify
individual cipher suites.

A particular example is where an LDAP server has to support a large number
of cipher suites due to a wide variety of clients and connections.
(For example, some clients are known to be in a trusted part of a network,
 others use e.g. wireless.)

Restricting the cipher suites on the server is not feasible,
so it has to be done on a per-client (per client type) basis.

Again, most of that is not really a security issue, but political.

For example, if an organization can configure all their workstations
connected wirelessly to use TLS_RSA_CAMELLIA_256_CBC_SHA1 on TLS1.0
connections only, it is simple to document, monitor (ie. only one cipher,
mac, kx, and TLS version to monitor for security advisories), and
report to non-technical pointy-haired bosses.

Let me reiterate: I find the levels extremely useful, and will always
use and recommend them myself. However, for the other cases,
like requiring a specific cipher suite, GnuTLS priority strings
are very complicated to get exactly right.

(For Ubuntu, which still uses GnuTLS-2.12, with the OpenLDAP StartTLS
 bug when compiled against GnuTLS, I had to write a small ldapsearch-like
 program that also accepts the priority string as a command line
 parameter, to experimentally find a suitable priority string
 for a colleague.)

> Yes. Note that during the handshake, the server and the client would
> need to process this list and remove the ciphersuites that are not
> compatible with their keys (but if an index is used as you propose that
> would be pretty efficient).

My thoughts exactly.

gnutls_priority_init() would still have to internally keep cipher, mac,
and kx priority lists, in case the priority string specifies those,
and select applicable cipher suites added to the list.
That is not a problem, as it is just a variant of the code in
lib/algorithms/ciphersuites.c:_gnutls_supported_ciphersuites().

The only real problem I can see is in finding out a suitable set
of logical rules. For example, if the cipher suite specifies both
cipher suites, and cipher algorithms, how these interact?

I'm leaning towards adding cipher suites based on cipher-mac-kx separately
from named cipher suites, but removal being common, and operating only
up to that point in the priority string. It seems to feel most intuitive,
and lead to sane code.

> > Another option would be to revamp the priority string parsing
> > entirely, and move to one that allows reasonable compatibility
> > with OpenSSL priority strings.
>
> No, openssl priority strings aren't any better (and are harder to
> understand if you know what's going on). OpenLDAP with gnutls is a long
> story. They use gnutls but they expect the openssl behavior and API.
> Gnutls isn't an LGPL port of openssl. It's another library and I don't
> think there is any reason to change that.

Yes, I'm not really in favour of that option myself, either.
I just wanted to state it, because it is an option often expressed in
bug reports and similar complaints with e.g. OpenLDAP.

I'd much rather have a clear set of logical rules,
that would be easy to use.

> > A third option would be to enhance the current priority string
> > parsing, but in a way that allows automatic conversion between
> > GnuTLS and OpenSSL priority strings
>
> That would be interesting for programs that switched from openssl to
> gnutls, but I think this no longer happens. Programs now either start
> with gnutls or not. In any case, that again couldn't be part of gnutls.
> It could be part of gnutls-openssl library or so.

I was thinking more about larger organizations, where most of the servers
tend to be of the RHEL/CentOS/ScientificLinux variety (using OpenSSL),
and workstations of the Debian/Ubuntu/Mint variety (using GnuTLS),
and keeping configurations compatible.

Given the configured priority string on one, the tool could describe
the effects in human-readable terms, and show compatible rule in the
other. Preferably with recommendations (like "PERFORMANCE" or "SECURE256"
for GnuTLS).

Best regards,
  Jouko


From jouko.orava at helsinki.fi  Sun Jan 27 09:17:59 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Sun, 27 Jan 2013 10:17:59 +0200 (EET)
Subject: [gnutls-devel] BNF of priority strings
In-Reply-To: <5103DB97.1000207@gnutls.org>
References: <alpine.LRH.2.00.1301261446460.30132@ruuvi.it.helsinki.fi>
	<5103DB97.1000207@gnutls.org>
Message-ID: <alpine.LRH.2.00.1301270945390.25179@ruuvi.it.helsinki.fi>

> >   1. Since the NULL MAC string is "MAC-NULL",
> >      it has to be specified as "MAC-MAC-NULL".
> >      I don't know if anyone ever needs to specify it, though.
>
> Nice catch, but it was intentional. MAC-NULL cannot be set in TLS (there
> are no ciphersuites with such MAC).

Right. The only use case I could think of was "!MAC-MAC-NULL",
a paranoid never-allow-NULL-MAC.

> >   2. Commit 8d69e1bd9e61cc0b390ca987fd66ec2aad9c0d3c
>
> It's a typo on the commit message. The curve is 521 bits long.

Ah, okay. I only just found a PDF that explained that the
recommended set is 112 128 160 192 224 256 384 521 bits,
so I guess the 512 is a common typo.

> >   3. All "...-ALL" accept any extra suffix
>
> I think that this could be easily changed, or not?

Very easy, as it is just a strncasecmp() -> strcasecmp().

My only worry is that it might stop existing priority strings from
working. On the other hand, it'd only break silly strings, not
sensible ones.

> An interesting use for your BNF description would be to be used to check
> the current priority parsing code. That would be if there is a tool that
> takes BNF and outputs valid random strings.

I don't think that's necessary, as the code is quite straightforward and
clean; aside from what I reported, I could see no anomalies or likely
culprits. A lot of the code in gnutls_priority_init() repeats, after all.

What I do suspect, though, is that most priority strings that are more
complex than just a level, do not actually have the effects that the
users think they have. The interaction with the separate priority lists
and the resulting cipher suite set is quite complex, when the priority
string contains both additions and removals.

To find it out, one would need to extract the relevant code,
including lib/algorithms/, and evaluate the cipher suite set
to see what actually becomes acceptable..

It would be worthwhile if and only if there was an archive of existing
priority strings to test, I think.

Best regards,
  Jouko


From nmav at gnutls.org  Mon Jan 28 01:55:36 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Jan 2013 01:55:36 +0100
Subject: [gnutls-devel] gnutls_cipher_decrypt2() is broken for AES-GCM
In-Reply-To: <6F242550-1097-40C6-8DA6-BAE952422B63@thaiglish.com>
References: <6F242550-1097-40C6-8DA6-BAE952422B63@thaiglish.com>
Message-ID: <5105CC88.2070302@gnutls.org>

On 01/26/2013 06:40 PM, William McGovern wrote:

> Hello,
> 
> It seems that gnutls_cipher_decrypt2() does not work for the AES-GCM
> ciphers and does not generate any data in the output buffer or return
> any error code. In-place decryption of the same ciphertext with
> gnutls_cipher_decrypt() works correctly.


Thank you for reporting and for the code to reproduce. Indeed
gnutls_cipher_decrypt2() had a bug with AEAD ciphers. I've fixed that in
master.

https://gitorious.org/gnutls/gnutls/commit/bbb36bd8d5586d15f040d8415e5490d3bf75de71

regards,
Nikos


From nmav at gnutls.org  Mon Jan 28 02:17:48 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Jan 2013 02:17:48 +0100
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <alpine.LRH.2.00.1301270855550.25179@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
	<alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
	<5103D9E5.5030303@gnutls.org>
	<alpine.LRH.2.00.1301270855550.25179@ruuvi.it.helsinki.fi>
Message-ID: <5105D1BC.5020904@gnutls.org>

On 01/27/2013 08:45 AM, Jouko Orava wrote:

> On Sat, 26 Jan 2013, Nikos Mavrogiannopoulos wrote:
>> Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
>> should be clearly advertised by the applications.
> 
> Right, and that's what I too recommend for users. For example, for the
> OpenLDAP bug I recently reported (libldap crashes in starttls if linked
> against GnuTLS and given an invalid priority string), I suggest using
> "SECURE256" in particular.


SECURE256 is pretty high security for today's standards. Most probably
with such a priority string you wouldn't be able to connect to many servers.

> The only real problem I can see is in finding out a suitable set
> of logical rules. For example, if the cipher suite specifies both
> cipher suites, and cipher algorithms, how these interact?

> I'm leaning towards adding cipher suites based on cipher-mac-kx separately
> from named cipher suites, but removal being common, and operating only
> up to that point in the priority string. It seems to feel most intuitive,
> and lead to sane code.

It could be two different modes. One that you specify explicitly
ciphersuites, and the other that is like now (level+ciphers,macs etc.).

Does this make sense?

>>> A third option would be to enhance the current priority string
>>> parsing, but in a way that allows automatic conversion between
>>> GnuTLS and OpenSSL priority strings
>> That would be interesting for programs that switched from openssl to
>> gnutls, but I think this no longer happens. Programs now either start
>> with gnutls or not. In any case, that again couldn't be part of gnutls.
>> It could be part of gnutls-openssl library or so.
> I was thinking more about larger organizations, where most of the servers
> tend to be of the RHEL/CentOS/ScientificLinux variety (using OpenSSL),
> and workstations of the Debian/Ubuntu/Mint variety (using GnuTLS),
> and keeping configurations compatible.
> Given the configured priority string on one, the tool could describe
> the effects in human-readable terms, and show compatible rule in the
> other. Preferably with recommendations (like "PERFORMANCE" or "SECURE256"
> for GnuTLS).


It sounds reasonable.

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-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 jouko.orava at helsinki.fi  Mon Jan 28 07:54:12 2013
From: jouko.orava at helsinki.fi (Jouko Orava)
Date: Mon, 28 Jan 2013 08:54:12 +0200 (EET)
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <5105D1BC.5020904@gnutls.org>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
	<alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
	<5103D9E5.5030303@gnutls.org>
	<alpine.LRH.2.00.1301270855550.25179@ruuvi.it.helsinki.fi>
	<5105D1BC.5020904@gnutls.org>
Message-ID: <alpine.LRH.2.00.1301280701380.737@ruuvi.it.helsinki.fi>

> It could be two different modes. One that you specify explicitly
> ciphersuites, and the other that is like now (level+ciphers,macs etc.).
>
> Does this make sense?

Absolutely, and that's also the reason I haven't yet tested the patches I
proposed earlier (making '+' optional, for example).

Here's the logic rules I've been considering.
I'm not entirely happy with it, and I think it needs further work.
It is quite possibly too complicated (for users).
(I do believe the implementation would be straightforward, though.)

	"!" <ciphersuite>
	"!" <protocol>
	"!" <certificate>
	"!" <compression>
	"!" <signature>
	"!" <cipher>
	"!" <mac>
	"!" <key exchange>
		Completely disallow (ban).
		Applies as if these were listed last in the string.

	"!" <level>
		Ban all cipher suites in <level>
		from the current priority set.
		(Other features of <level> are ignored.)

	"-" <ciphersuite>
	"-" <protocol>
	"-" <certificate>
	"-" <compression>
	"-" <signature>
	"-" "%" <option>
	"-" <cipher>
	"-" <mac>
	"-" <key exchange>
		Remove from the current priority set.
		Applies only to the left in the string,
		up to the last <level> encountered.

	"-" <level>
		Remove all cipher suites in <level> from
		the current priority set.
		(Other features of <level> are ignored.)

	<level>
	<ciphersuite>
	<protocol>
	<certificate>
	<compression>
	<signature>
	"%" <option>
		Add to current priority set.

	<cipher>
	<mac>
	<key exchange>
		Add to temporary priority lists.
		At the end of string, or at the next full cipher
		suite name (added, removed, or banned), the
		temporary lists will be converted to cipher suites,
		and added to the priority set.
		(Cipher suites that match any of the "!" bans will
		 not be added to the priority sets, of course.)

All strings are case sensitive.

Instead of "-ALL" suffixes, catch-alls could use an asterisk "*".
For example, any TLSv1 protocol could be "TLSv1.*".

"NONE" should include "no compression". Compression can be required
by explicitly banning or removing "no compression".

To distinguish between the existing parsing, this format would
require a start marker, for example "@" or "New".
Anything not accepted by the existing parser would be acceptable.
As it would be at the beginning of the string, it would be very easy to
factor out the common (splitting) code but keep the other parsing
separate, making for cleaner code without unnecessary repetition.

Thoughts? Comments? Better ideas?

Best regards,
  Jouko


From tim.ruehsen at gmx.de  Mon Jan 28 10:55:09 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 28 Jan 2013 10:55:09 +0100
Subject: [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:05:52 2013
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 28 Jan 2013 11:05:52 +0100
Subject: [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 jaak.ristioja at cyber.ee  Mon Jan 28 11:17:03 2013
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Mon, 28 Jan 2013 12:17:03 +0200
Subject: [gnutls-devel] Errors building GnuTLS
In-Reply-To: <5103D382.6090200@gnutls.org>
References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org>
Message-ID: <5106501F.5030601@cyber.ee>

On 26.01.2013 15:00, Nikos Mavrogiannopoulos wrote:
> On 01/26/2013 11:45 AM, Jaak Ristioja wrote:
>> I'm trying to build GnuTLS (currently from git master), but I'm getting
>> some errors. Maybe I'm doing it wrong, but I did
>>
>>   make autoreconf
>>   ./configure --disable-libdane --without-p11-kit
>> --disable-openpgp-authentication --disable-openssl-compatibility
>> --disable-dtls-srtp-support --disable-srp-authentication
>> --disable-psk-authentication --prefix=/home/jotik/develop/gnutls/prefix/
>> --disable-cxx --disable-crywrap --disable-guile --disable-nls
>>   make
>>
>> The next error I'm getting is:
>>
>> make[3]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/lib'
>>   CC     gnutls_ui.lo
>> gnutls_ui.c: In function 'gnutls_certificate_get_peers_subkey_id':
>> gnutls_ui.c:579:18: error: 'struct cert_auth_info_st' has no member
>> named 'subkey_id'
> 
> 
> Hello,
>  These disable options are not actively maintained and their status
> depends on patches received by the ones who actually use it. Usually on
> the errors you see, it is sufficient to disable the corresponding
> function or code by using and ifdef of the feature it is related to.
> 
> 
> I've now fixed the issue you quote. For other issues, or when in doubt
> feel free to ask.

Thanks! The fix worked for that error. :) Here's what I get next on one
of my systems:

make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src'
  CCLD   danetool
  CCLD   certtool
danetool.o: In function `dane_info':
/home/jotik/develop/gnutls/gnutls.git/src/danetool.c:397: undefined
reference to `gnutls_hex_encode'
certtool-common.o: In function `load_secret_key':
/home/jotik/develop/gnutls/gnutls.git/src/certtool-common.c:97:
undefined reference to `gnutls_hex_decode'
collect2: ld returned 1 exit status
make[4]: *** [danetool] Error 1
make[4]: *** Waiting for unfinished jobs....
certtool.o: In function `detailed_verification':
/home/jotik/develop/gnutls/gnutls.git/src/certtool.c:1989: undefined
reference to `gnutls_hex_encode'
certtool-common.o: In function `load_secret_key':
/home/jotik/develop/gnutls/gnutls.git/src/certtool-common.c:97:
undefined reference to `gnutls_hex_decode'
collect2: ld returned 1 exit status
make[4]: *** [certtool] Error 1

Looks like another bug.

In addition is there a way to ./configure GnuTLS not to build these
tools? My goal is just to build a simple library.

Best regards,
Jaak


From nmav at gnutls.org  Mon Jan 28 12:11:36 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Jan 2013 12:11:36 +0100
Subject: [gnutls-devel] Errors building GnuTLS
In-Reply-To: <5106501F.5030601@cyber.ee>
References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org>
	<5106501F.5030601@cyber.ee>
Message-ID: <CAJU7zaKOTk296OkvMicx76Veaj6AQ7gxeBAY-H59MT5fLMvYSQ@mail.gmail.com>

On Mon, Jan 28, 2013 at 11:17 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
> On 26.01.2013 15:00, Nikos Mavrogiannopoulos wrote:
>> On 01/26/2013 11:45 AM, Jaak Ristioja wrote:
>>> I'm trying to build GnuTLS (currently from git master), but I'm getting
>>> some errors. Maybe I'm doing it wrong, but I did
[...]
>> I've now fixed the issue you quote. For other issues, or when in doubt
>> feel free to ask.
> Thanks! The fix worked for that error. :) Here's what I get next on one
> of my systems:
> make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src'
>   CCLD   danetool
>   CCLD   certtool
> danetool.o: In function `dane_info':
[...]
> In addition is there a way to ./configure GnuTLS not to build these
> tools? My goal is just to build a simple library.

There is no option to disable the programs, but I would accept any
patches for that.
However, you can just ignore these errors and install the libraries
you're interested at (e.g., cd lib && make install)

regards,
Nikos


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-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 09:17:47 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 29 Jan 2013 03:17:47 -0500
Subject: [gnutls-devel] gnutls-cli-debug failing with IPv6-only hosts?
Message-ID: <871ud4768k.fsf@alice.fifthhorseman.net>

i have a server listening only on the IPv6 loopback (not on IPv4). (This
is with GnuTLS 3.1.6)

/etc/hosts has these two lines in it:

127.0.0.1 localhost
::1       localhost


In this situation, if i try to connect on "localhost", gnutls-cli-debug
fails with a misleading error message, while "::1" works fine.

0 dkg at alice:~$ gnutls-cli-debug -p 9932 localhost
Resolving 'localhost'...
Connecting to '::1:9932'...
connect: Connection refused
1 dkg at alice:~$ gnutls-cli-debug -p 9932 ::1
Resolving '::1'...
Connecting to '::1:9932'...
Checking for SSL 3.0 support... yes
[...]


if i run "strace gnutls-cli-debug -p 9932 localhost", then i can see
that it's actually trying to connect on IPv4 as well as IPv6, even
though it doesn't report that on stdout:

0 dkg at alice:~$ strace gnutls-cli-debug -p 9932 localhost
execve("/usr/bin/gnutls-cli-debug", ["gnutls-cli-debug", "-p", "9932", "localhost"], [/* 40 vars */]) = 0
brk(0)                                  = 0x2424000
[...]
write(1, "Connecting to '::1:9932'...\n", 28Connecting to '::1:9932'...
) = 28
connect(4, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 5
connect(5, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(9932), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
close(6)                                = 0
dup(2)                                  = 6
fcntl(6, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(6, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 11), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f65c428d000
lseek(6, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(6, "connect: Connection refused\n", 28connect: Connection refused
) = 28
close(6)                                = 0
munmap(0x7f65c428d000, 4096)            = 0
exit_group(1)                           = ?
1 dkg at alice:~$ 



And attempts to increase verbosity don't help explain that it's trying
to connect via IPv4 and failing too:

1 dkg at alice:~$ gnutls-cli-debug -p 9932 localhost -VVVVVVVVVVVV
Resolving 'localhost'...
Connecting to '::1:9932'...
connect: Connection refused
1 dkg at alice:~$ 

Looking at it with ltrace, i see the following:

connect(4, 0xb9ace0, 28, 0x409d4c, 5)                                                                                                      = 0
socket(10, 1, 6)                                                                                                                           = 5
getnameinfo(0x00b9ad40, 28, "::1", 4096, NULL, 0, 1)                                                                                       = 0
connect(5, 0xb9ad40, 28, 0, 0xfefefefefefefeff)                                                                                            = 0
socket(2, 1, 6)                                                                                                                            = 6
getnameinfo(0x00b9ac90, 16, "::1", 4096, NULL, 0, 1)                                                                                       = 0
connect(6, 0xb9ac90, 16, 0, 0xfefefefefefefeff)                                                                                            = -1
close(6)                                                                                                                                   = 0
perror("connect"connect: Connection refused
)                                                                                                                          = <void>
+++ exited (status 1) +++
0 dkg at alice:~$ 


I think that IPv6 addrinfo's are 28 bytes long, but IPv4 are 16 bytes.

This makes me think that there's a bug in getnameinfo, that it could be
passed an AF_INET IPv4 address with the NI_NUMERICHOST, and still have
it respond "::1", even though an IPv4 address clearly shouldn't be
mapped to a name of "::1".

This is happening around line 268 of src/cli-debug.c, fwiw.

Any ideas?  Should i take this up with libc folks instead?

       --dkg
-------------- 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/73b24baa/attachment.pgp>

From nmav at gnutls.org  Tue Jan 29 09:29:50 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Jan 2013 09:29:50 +0100
Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string
 requirements
In-Reply-To: <alpine.LRH.2.00.1301280701380.737@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301240329380.25159@ruuvi.it.helsinki.fi>
	<5102ECF2.80801@gnutls.org>
	<alpine.LRH.2.00.1301260648560.29292@ruuvi.it.helsinki.fi>
	<5103AEE6.6050605@gnutls.org>
	<alpine.LRH.2.00.1301261236530.6471@ruuvi.it.helsinki.fi>
	<5103D9E5.5030303@gnutls.org>
	<alpine.LRH.2.00.1301270855550.25179@ruuvi.it.helsinki.fi>
	<5105D1BC.5020904@gnutls.org>
	<alpine.LRH.2.00.1301280701380.737@ruuvi.it.helsinki.fi>
Message-ID: <5107887E.7040708@gnutls.org>

On 01/28/2013 07:54 AM, Jouko Orava wrote:

>> It could be two different modes. One that you specify explicitly
>> ciphersuites, and the other that is like now (level+ciphers,macs etc.).
>>
>> Does this make sense?
> 
> Absolutely, and that's also the reason I haven't yet tested the patches I
> proposed earlier (making '+' optional, for example).
> 
> Here's the logic rules I've been considering.
> I'm not entirely happy with it, and I think it needs further work.
> It is quite possibly too complicated (for users).
> (I do believe the implementation would be straightforward, though.)
> 
> 	"!" <ciphersuite>
> 	"!" <protocol>
> 	"!" <certificate>
> 	"!" <compression>
> 	"!" <signature>
> 	"!" <cipher>
> 	"!" <mac>
> 	"!" <key exchange>
> 		Completely disallow (ban).
> 		Applies as if these were listed last in the string.
> 
> 	"!" <level>
> 		Ban all cipher suites in <level>
> 		from the current priority set.
> 		(Other features of <level> are ignored.)


What is the purpose of being able to remove ciphersuites from a level?

> Instead of "-ALL" suffixes, catch-alls could use an asterisk "*".
> For example, any TLSv1 protocol could be "TLSv1.*".


That is more intuitive and could be added to the old format as well, in
a backwards compatible way.

> "NONE" should include "no compression". Compression can be required
> by explicitly banning or removing "no compression".


Why is that? None should be really none, so that you can specify exactly
what you need. That's how it is used now.

> To distinguish between the existing parsing, this format would
> require a start marker, for example "@" or "New".


I'd propose the new string to be simpler:
> 	x <ciphersuite>
> 	x <protocol>
> 	x <certificate>
> 	x <compression>
> 	x <signature>
>       % <cmd>
x = + | " "

That is you'll choose the new format to specify ciphersuites, and use
the old format if you want to specify individual algorithms/levels.

I wouldn't like to have more than a way to do the same thing.

regards,
Nikos


From nmav at gnutls.org  Tue Jan 29 09:31:42 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Jan 2013 09:31:42 +0100
Subject: [gnutls-devel] BNF of priority strings
In-Reply-To: <alpine.LRH.2.00.1301270945390.25179@ruuvi.it.helsinki.fi>
References: <alpine.LRH.2.00.1301261446460.30132@ruuvi.it.helsinki.fi>
	<5103DB97.1000207@gnutls.org>
	<alpine.LRH.2.00.1301270945390.25179@ruuvi.it.helsinki.fi>
Message-ID: <510788EE.3090906@gnutls.org>

On 01/27/2013 09:17 AM, Jouko Orava wrote:

> I don't think that's necessary, as the code is quite straightforward and
> clean; aside from what I reported, I could see no anomalies or likely
> culprits. A lot of the code in gnutls_priority_init() repeats, after all.
> 
> What I do suspect, though, is that most priority strings that are more
> complex than just a level, do not actually have the effects that the
> users think they have. The interaction with the separate priority lists
> and the resulting cipher suite set is quite complex, when the priority
> string contains both additions and removals.


Yes, that needs to be fixed.



From nmav at gnutls.org  Tue Jan 29 10:02:44 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Jan 2013 10:02:44 +0100
Subject: [gnutls-devel] gnutls-cli-debug failing with IPv6-only hosts?
In-Reply-To: <871ud4768k.fsf@alice.fifthhorseman.net>
References: <871ud4768k.fsf@alice.fifthhorseman.net>
Message-ID: <51079034.3080607@gnutls.org>

On 01/29/2013 09:17 AM, Daniel Kahn Gillmor wrote:

> i have a server listening only on the IPv6 loopback (not on IPv4). (This
> is with GnuTLS 3.1.6)
> 
> /etc/hosts has these two lines in it:
> 
> 127.0.0.1 localhost
> ::1       localhost
> if i run "strace gnutls-cli-debug -p 9932 localhost", then i can see
> that it's actually trying to connect on IPv4 as well as IPv6, even
> though it doesn't report that on stdout:
> 0 dkg at alice:~$ strace gnutls-cli-debug -p 9932 localhost
> execve("/usr/bin/gnutls-cli-debug", ["gnutls-cli-debug", "-p", "9932", "localhost"], [/* 40 vars */]) = 0
> brk(0)                                  = 0x2424000
> [...]
> write(1, "Connecting to '::1:9932'...\n", 28Connecting to '::1:9932'...
> ) = 28
> connect(4, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 5
> connect(5, {sa_family=AF_INET6, sin6_port=htons(9932), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
> connect(6, {sa_family=AF_INET, sin_port=htons(9932), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)


It seems a break is needed if connect succeeds and possibly always print
the correct host to connect to.

Would something like the attached patch work better?

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20130129/0174d068/attachment.txt>

From jaak.ristioja at cyber.ee  Tue Jan 29 10:38:25 2013
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Tue, 29 Jan 2013 11:38:25 +0200
Subject: [gnutls-devel] Errors building GnuTLS
In-Reply-To: <CAJU7zaKOTk296OkvMicx76Veaj6AQ7gxeBAY-H59MT5fLMvYSQ@mail.gmail.com>
References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org>
	<5106501F.5030601@cyber.ee>
	<CAJU7zaKOTk296OkvMicx76Veaj6AQ7gxeBAY-H59MT5fLMvYSQ@mail.gmail.com>
Message-ID: <51079891.4090807@cyber.ee>

On 28.01.2013 13:11, Nikos Mavrogiannopoulos wrote:
> On Mon, Jan 28, 2013 at 11:17 AM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
>> On 26.01.2013 15:00, Nikos Mavrogiannopoulos wrote:
>>> On 01/26/2013 11:45 AM, Jaak Ristioja wrote:
>>>> I'm trying to build GnuTLS (currently from git master), but I'm getting
>>>> some errors. Maybe I'm doing it wrong, but I did
> [...]
>>> I've now fixed the issue you quote. For other issues, or when in doubt
>>> feel free to ask.
>> Thanks! The fix worked for that error. :) Here's what I get next on one
>> of my systems:
>> make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src'
>>   CCLD   danetool
>>   CCLD   certtool
>> danetool.o: In function `dane_info':
> [...]
>> In addition is there a way to ./configure GnuTLS not to build these
>> tools? My goal is just to build a simple library.
> 
> There is no option to disable the programs, but I would accept any
> patches for that.
> However, you can just ignore these errors and install the libraries
> you're interested at (e.g., cd lib && make install)

I'm not very proficient with autotools, but here's my attempt to provide
some patches for this:

  https://gitorious.org/gnutls/gnutls/merge_requests/2

Best regards,
Jaak