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 . A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid Nikos Mavrogiannopoulos 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: 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 _______________________________________________________ Reply to this item at: _______________________________________________ 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 . A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid Nikos Mavrogiannopoulos 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: 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: References: 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 . A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid Nikos Mavrogiannopoulos 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: 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 _______________________________________________________ Reply to this item at: _______________________________________________ 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: _______________________________________________ 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 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: 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 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: References: <50F8516D.9080700@gnutls.org> 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 --- 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 > --- > 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: 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: On Mon, Jan 21, 2013 at 10:41 AM, Tim Ruehsen 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: 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 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: References: <50F8516D.9080700@gnutls.org> <201301211041.27942.tim.ruehsen@gmx.de> 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 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: References: 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: 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: <5102ECF2.80801@gnutls.org> Message-ID: > 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: 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: References: <5102ECF2.80801@gnutls.org> 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> <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: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> Message-ID: > 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: 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: ::= | { ":" } | { ":" } ::= "NONE" | "NORMAL" | "PERFORMANCE" | "SECURE128" | "SECURE192" | "SECURE256" | "SUITEB128" | "SUITEB192" | "EXPORT" ::= "+" | "+" | "-" | "!" | "+" | "-" | "!" | "+" | "-" | "!" | "+" | "-" | "!" | "+" "VERS-" | "-" "VERS-" | "!" "VERS-" | "+" "COMP-" | "-" "COMP-" | "!" "COMP-" | "+" "CURVE-" | "-" "CURVE-" | "!" "CURVE-" | "+" "CTYPE-" | "-" "CTYPE-" | "!" "CTYPE-" | "+" "SIGN-" | "-" "SIGN-" | "!" "SIGN-" | "%" ::= "VERS-TLS-ALL" [ ] | "COMP-ALL" [ ] | "CURVE-ALL" [ ] | "CTYPE-ALL" [ ] | "SIGN-ALL" [ ] | "MAC-ALL" [ ] | "CIPHER-ALL" [ ] | "KX-ALL" [ ] ::= "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" ::= "SHA1" | "MD5" | "SHA256" | "SHA384" | "SHA512" | "SHA224" | "AEAD" | "MD2" | "RIPEMD160" | "MAC-NULL" ::= "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" ::= "SSL3.0" | "TLS1.0" | "TLS1.1" | "TLS1.2" | "DTLS0.9" | "DTLS1.0" ::= "NULL" | "DEFLATE" ::= "SECP192R1" | "SECP224R1" | "SECP256R1" | "SECP384R1" | "SECP521R1" ::= "X.509" | "X509" | "OPENPGP" ::= "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" ::= "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" ::= 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: References: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> 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: References: 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 #include #include #include #include #include #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 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 > #include > #include > #include > #include > #include > > #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 #include #include #include #include #include #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: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> Message-ID: 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: <5103DB97.1000207@gnutls.org> Message-ID: > > 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: References: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> 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> <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 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: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> <5105D1BC.5020904@gnutls.org> Message-ID: > 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.) "!" "!" "!" "!" "!" "!" "!" "!" Completely disallow (ban). Applies as if these were listed last in the string. "!" Ban all cipher suites in from the current priority set. (Other features of are ignored.) "-" "-" "-" "-" "-" "-" "%"