From nmav at gnutls.org  Thu Oct  2 17:03:39 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 2 Oct 2014 17:03:39 +0200
Subject: [gnutls-devel] [PATCH] Check the credentials getter functions
 as part of the unit tests
In-Reply-To: <1411674782.1339.13.camel@waverley>
References: <ebe7aab56bdabc81e8d08a1624fb319846d452be.1411503220.git.armin@arbur.net>
 <1411547875.2495.3.camel@nomad.lan>
 <1411674782.1339.13.camel@waverley>
Message-ID: <CAJU7zaKaurgEewKg8UfHAC7REXVkw98-5bGm4RQj16uLi0RDyw@mail.gmail.com>

On Thu, Sep 25, 2014 at 9:53 PM, Armin Burgmeier <armin at arbur.net> wrote:
>> >  tests/openpgp-auth.c |  47 ++++++++++++++++++++++
>> >  tests/x509cert.c     | 107 ++++++++++++++++++++++++++++++++++++++++++++++++---
>> >  2 files changed, 149 insertions(+), 5 deletions(-)
>>
>> Thank you. I've applied the complete patch set.
> Thanks! I suppose the ticket on savannah could then be closed as well.

I realized that gnutls_x509_trust_list_iter_get_ca() is incomplete.
When the trust list is on a pkcs11 trust module, iteration wouldn't
work.

That's seems to be easily done (at the cost of a very large iterator),
using the same enumeration as in
gnutls_x509_trust_list_add_trust_file(). That is using
gnutls_pkcs11_obj_list_import_url2() and then converting each one to
certificate using gnutls_x509_crt_import_pkcs11(). I could schedule to
do it, but if you can do it, it would be real help.

regards,
Nikos


From armin at arbur.net  Thu Oct  2 17:44:28 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Thu, 02 Oct 2014 11:44:28 -0400
Subject: [gnutls-devel] [PATCH] Check the credentials getter functions
 as part of the unit tests
In-Reply-To: <CAJU7zaKaurgEewKg8UfHAC7REXVkw98-5bGm4RQj16uLi0RDyw@mail.gmail.com>
References: <ebe7aab56bdabc81e8d08a1624fb319846d452be.1411503220.git.armin@arbur.net>
 <1411547875.2495.3.camel@nomad.lan> <1411674782.1339.13.camel@waverley>
 <CAJU7zaKaurgEewKg8UfHAC7REXVkw98-5bGm4RQj16uLi0RDyw@mail.gmail.com>
Message-ID: <1412264668.1346.4.camel@waverley>

On Thu, 2014-10-02 at 17:03 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Sep 25, 2014 at 9:53 PM, Armin Burgmeier <armin at arbur.net> wrote:
> >> >  tests/openpgp-auth.c |  47 ++++++++++++++++++++++
> >> >  tests/x509cert.c     | 107 ++++++++++++++++++++++++++++++++++++++++++++++++---
> >> >  2 files changed, 149 insertions(+), 5 deletions(-)
> >>
> >> Thank you. I've applied the complete patch set.
> > Thanks! I suppose the ticket on savannah could then be closed as well.
> 
> I realized that gnutls_x509_trust_list_iter_get_ca() is incomplete.
> When the trust list is on a pkcs11 trust module, iteration wouldn't
> work.
> 
> That's seems to be easily done (at the cost of a very large iterator),
> using the same enumeration as in
> gnutls_x509_trust_list_add_trust_file(). That is using
> gnutls_pkcs11_obj_list_import_url2() and then converting each one to
> certificate using gnutls_x509_crt_import_pkcs11(). I could schedule to
> do it, but if you can do it, it would be real help.

Okay, I'll try to do it on the weekend or early next week.

Cheers,
Armin



From ludo at gnu.org  Sat Oct  4 23:36:33 2014
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Sat, 04 Oct 2014 23:36:33 +0200
Subject: [gnutls-devel] Guile patches committed
In-Reply-To: <1412103277.2908.1.camel@nomad.lan> (Nikos Mavrogiannopoulos's
 message of "Tue, 30 Sep 2014 20:54:37 +0200")
References: <87wq8vohpx.fsf@gnu.org> <1411405464.3469.6.camel@nomad.lan>
 <87k34vmv0b.fsf@gnu.org> <1411416782.5630.1.camel@nomad.lan>
 <87lhp1bbc2.fsf@gnu.org> <1412103277.2908.1.camel@nomad.lan>
Message-ID: <87y4svfrfi.fsf@gnu.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On Tue, 2014-09-30 at 13:24 +0200, Ludovic Court?s wrote:
>> Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:
>> 
>> > If you checkout the web-pages branch you'll see the source code of the
>> > web pages.
>> 
>> I?ve now added the GnuTLS-Guile manual.  Could you upload it?
>
> Hi,
>  I've regenerated the html and uploaded (it's automatically done every
> few hours) it but there is something wrong with the CSS (you can see the
> style difference between the two manuals). I think using
> --css-include=texinfo.css (the one in doc) would suffice.

I just did that and pushed to ?web-pages?.

Thanks,
Ludo?.


From armin at arbur.net  Mon Oct  6 21:36:47 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Mon, 06 Oct 2014 15:36:47 -0400
Subject: [gnutls-devel] [PATCH] Check the credentials getter functions
 as part of the unit tests
In-Reply-To: <1412264668.1346.4.camel@waverley>
References: <ebe7aab56bdabc81e8d08a1624fb319846d452be.1411503220.git.armin@arbur.net>
 <1411547875.2495.3.camel@nomad.lan> <1411674782.1339.13.camel@waverley>
 <CAJU7zaKaurgEewKg8UfHAC7REXVkw98-5bGm4RQj16uLi0RDyw@mail.gmail.com>
 <1412264668.1346.4.camel@waverley>
Message-ID: <1412624207.26289.1.camel@arbur.net>

On Thu, 2014-10-02 at 11:44 -0400, Armin Burgmeier wrote:
> On Thu, 2014-10-02 at 17:03 +0200, Nikos Mavrogiannopoulos wrote:
> > On Thu, Sep 25, 2014 at 9:53 PM, Armin Burgmeier <armin at arbur.net> wrote:
> > >> >  tests/openpgp-auth.c |  47 ++++++++++++++++++++++
> > >> >  tests/x509cert.c     | 107 ++++++++++++++++++++++++++++++++++++++++++++++++---
> > >> >  2 files changed, 149 insertions(+), 5 deletions(-)
> > >>
> > >> Thank you. I've applied the complete patch set.
> > > Thanks! I suppose the ticket on savannah could then be closed as well.
> > 
> > I realized that gnutls_x509_trust_list_iter_get_ca() is incomplete.
> > When the trust list is on a pkcs11 trust module, iteration wouldn't
> > work.
> > 
> > That's seems to be easily done (at the cost of a very large iterator),
> > using the same enumeration as in
> > gnutls_x509_trust_list_add_trust_file(). That is using
> > gnutls_pkcs11_obj_list_import_url2() and then converting each one to
> > certificate using gnutls_x509_crt_import_pkcs11(). I could schedule to
> > do it, but if you can do it, it would be real help.
> 
> Okay, I'll try to do it on the weekend or early next week.

while looking at the code you pointed to, I am not sure I understand the
following:

When adding a PKCS11 URL with gnutls_x509_trust_list_add_trust_file(),
basically all that is done is that the pkcs11_token field in the trust
list structure is set.

However, when using gnutls_x509_trust_list_remove_trust_file() to remove
a PKCS11 URL, the code imports all certificates from the URL and then
tries to remove them from the hash table. However, they have never been
added to the hash table? Is that such that the CA certificates are added
to the blacklist? In any case, the pkcs11_token field is not reset. Is
that correct?

Armin



From nmav at gnutls.org  Mon Oct  6 23:09:05 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 06 Oct 2014 23:09:05 +0200
Subject: [gnutls-devel] [PATCH] Check the credentials getter functions
 as part of the unit tests
In-Reply-To: <1412624207.26289.1.camel@arbur.net>
References: <ebe7aab56bdabc81e8d08a1624fb319846d452be.1411503220.git.armin@arbur.net>
 <1411547875.2495.3.camel@nomad.lan> <1411674782.1339.13.camel@waverley>
 <CAJU7zaKaurgEewKg8UfHAC7REXVkw98-5bGm4RQj16uLi0RDyw@mail.gmail.com>
 <1412264668.1346.4.camel@waverley> <1412624207.26289.1.camel@arbur.net>
Message-ID: <1412629745.5129.9.camel@nomad.lan>

On Mon, 2014-10-06 at 15:36 -0400, Armin Burgmeier wrote:

> > Okay, I'll try to do it on the weekend or early next week.
> 
> while looking at the code you pointed to, I am not sure I understand the
> following:
> 
> When adding a PKCS11 URL with gnutls_x509_trust_list_add_trust_file(),
> basically all that is done is that the pkcs11_token field in the trust
> list structure is set.
> 
> However, when using gnutls_x509_trust_list_remove_trust_file() to remove
> a PKCS11 URL, the code imports all certificates from the URL and then
> tries to remove them from the hash table. However, they have never been
> added to the hash table? Is that such that the CA certificates are added
> to the blacklist? In any case, the pkcs11_token field is not reset. Is
> that correct?

That is a bug. It seems that when the add_trust_file() was updated to
keep the URL the remove trust file wasn't updated. I should check to it.

regards,
Nikos




From armin at arbur.net  Mon Oct  6 23:24:11 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Mon, 6 Oct 2014 17:24:11 -0400
Subject: [gnutls-devel] [PATCH 2/3] Also iterate over the CA certificates in
	a PKCS11 token
In-Reply-To: <cover.1412631297.git.armin@arbur.net>
References: <cover.1412631297.git.armin@arbur.net>
Message-ID: <caafa4b3a041226e0c4cc0308fc7873aa751a13d.1412631297.git.armin@arbur.net>

Signed-off-by: Armin Burgmeier <armin at arbur.net>
---
 lib/x509/verify-high.c | 130 ++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 113 insertions(+), 17 deletions(-)

diff --git a/lib/x509/verify-high.c b/lib/x509/verify-high.c
index 9b0ee12..dda958b 100644
--- a/lib/x509/verify-high.c
+++ b/lib/x509/verify-high.c
@@ -57,6 +57,12 @@ struct node_st {
 struct gnutls_x509_trust_list_iter {
 	unsigned int node_index;
 	unsigned int ca_index;
+
+#ifdef ENABLE_PKCS11
+	gnutls_pkcs11_obj_t* pkcs11_list;
+	unsigned int pkcs11_index;
+	unsigned int pkcs11_size;
+#endif
 };
 
 #define DEFAULT_SIZE 127
@@ -294,6 +300,47 @@ gnutls_x509_trust_list_add_cas(gnutls_x509_trust_list_t list,
 	return i;
 }
 
+static int
+advance_iter(gnutls_x509_trust_list_t list,
+             gnutls_x509_trust_list_iter_t iter)
+{
+	int ret;
+
+	if (iter->node_index < list->size) {
+		++iter->ca_index;
+
+		/* skip entries */
+		while (iter->node_index < list->size &&
+		       iter->ca_index >= list->node[iter->node_index].trusted_ca_size) {
+			++iter->node_index;
+			iter->ca_index = 0;
+		}
+
+		if (iter->node_index < list->size)
+			return 0;
+	}
+
+#ifdef ENABLE_PKCS11
+	if (list->pkcs11_token != NULL) {
+		if (iter->pkcs11_list == NULL) {
+			ret = gnutls_pkcs11_obj_list_import_url2(&iter->pkcs11_list, &iter->pkcs11_size,
+			    list->pkcs11_token, GNUTLS_PKCS11_OBJ_ATTR_CRT_TRUSTED_CA, 0);
+			if (ret < 0)
+				return gnutls_assert_val(ret);
+
+			if (iter->pkcs11_size > 0)
+				return 0;
+		} else if (iter->pkcs11_index < iter->pkcs11_size) {
+			++iter->pkcs11_index;
+			if (iter->pkcs11_index < iter->pkcs11_size)
+				return 0;
+		}
+	}
+#endif
+
+	return gnutls_assert_val(GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE);
+}
+
 /**
  * gnutls_x509_trust_list_iter_get_ca:
  * @list: The structure of the list
@@ -322,7 +369,7 @@ gnutls_x509_trust_list_iter_get_ca(gnutls_x509_trust_list_t list,
 {
 	int ret;
 
-	/* advance to next entry */
+	/* initialize iterator */
 	if (*iter == NULL) {
 		*iter = gnutls_malloc(sizeof (struct gnutls_x509_trust_list_iter));
 		if (*iter == NULL)
@@ -330,31 +377,71 @@ gnutls_x509_trust_list_iter_get_ca(gnutls_x509_trust_list_t list,
 
 		(*iter)->node_index = 0;
 		(*iter)->ca_index = 0;
-	} else {
-		++(*iter)->ca_index;
+
+#ifdef ENABLE_PKCS11
+		(*iter)->pkcs11_list = NULL;
+		(*iter)->pkcs11_size = 0;
+		(*iter)->pkcs11_index = 0;
+#endif
+
+		/* Advance iterator to the first valid entry */
+		if (list->node[0].trusted_ca_size == 0) {
+			ret = advance_iter(list, *iter);
+			if (ret != 0) {
+				gnutls_x509_trust_list_iter_deinit(*iter);
+				*iter = NULL;
+
+				*crt = NULL;
+				return gnutls_assert_val(ret);
+			}
+		}
 	}
 
-	/* skip empty nodes */
-	while ((*iter)->ca_index >= list->node[(*iter)->node_index].trusted_ca_size) {
-		++(*iter)->node_index;
-		(*iter)->ca_index = 0;
+	/* obtain the certificate at the current iterator position */
+	if ((*iter)->node_index < list->size) {
+		ret = gnutls_x509_crt_init(crt);
+		if (ret < 0)
+			return gnutls_assert_val(ret);
 
-		if ((*iter)->node_index >= list->size) {
-			gnutls_free(*iter);
-			*iter = NULL;
+		ret = _gnutls_x509_crt_cpy(*crt, list->node[(*iter)->node_index].trusted_cas[(*iter)->ca_index]);
+		if (ret < 0) {
+			gnutls_x509_crt_deinit(*crt);
+			return gnutls_assert_val(ret);
+		}
+	}
+#ifdef ENABLE_PKCS11
+	else if ( (*iter)->pkcs11_index < (*iter)->pkcs11_size) {
+		ret = gnutls_x509_crt_init(crt);
+		if (ret < 0)
+			return gnutls_assert_val(ret);
 
-			*crt = NULL;
-			return gnutls_assert_val(GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE);
+		ret = gnutls_x509_crt_import_pkcs11(*crt, (*iter)->pkcs11_list[(*iter)->pkcs11_index]);
+		if (ret < 0) {
+			gnutls_x509_crt_deinit(*crt);
+			return gnutls_assert_val(ret);
 		}
 	}
+#endif
 
-	ret = gnutls_x509_crt_init(crt);
-	if (ret < 0)
-		return gnutls_assert_val(ret);
+	else {
+		/* iterator is at end */
+		gnutls_x509_trust_list_iter_deinit(*iter);
+		*iter = NULL;
 
-	ret = _gnutls_x509_crt_cpy(*crt, list->node[(*iter)->node_index].trusted_cas[(*iter)->ca_index]);
-	if (ret < 0) {
+		*crt = NULL;
+		return gnutls_assert_val(GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE);
+	}
+
+	/* Move iterator to the next position.
+	 * GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned if the iterator
+	 * has been moved to the end position. That is okay, we return the
+	 * certificate that we read and when this function is called again we
+	 * report GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE to our caller. */
+	ret = advance_iter(list, *iter);
+	if (ret	< 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
 		gnutls_x509_crt_deinit(*crt);
+		*crt = NULL;
+
 		return gnutls_assert_val(ret);
 	}
 
@@ -374,6 +461,15 @@ void gnutls_x509_trust_list_iter_deinit(gnutls_x509_trust_list_iter_t iter)
 	if (!iter)
 		return;
 
+#ifdef ENABLE_PKCS11
+	if (iter->pkcs11_size > 0) {
+		unsigned i;
+		for (i = 0; i < iter->pkcs11_size; ++i)
+			gnutls_pkcs11_obj_deinit(iter->pkcs11_list[i]);
+		gnutls_free(iter->pkcs11_list);
+	}
+#endif
+
 	gnutls_free(iter);
 }
 
-- 
2.1.1



From armin at arbur.net  Mon Oct  6 23:34:57 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Mon, 6 Oct 2014 17:34:57 -0400
Subject: [gnutls-devel] [PATCH 0/3] Support PKCS11 tokens when iterating a
	trust list
Message-ID: <cover.1412631297.git.armin@arbur.net>

These patches add the missing functionality to also iterate the CAs of a
PKCS11 token when iterating over the CAs stored in a trust list.

Armin Burgmeier (3):
  Return an error if multiple PKCS11 URLs are added to a trust list
  Also iterate over the CA certificates in a PKCS11 token
  Add a test for PKCS11 CA iteration

 lib/x509/verify-high.c           | 130 ++++++++++++++++++++++++++++++++++-----
 lib/x509/verify-high2.c          |   2 +
 tests/suite/pkcs11-chainverify.c |  31 ++++++++++
 3 files changed, 146 insertions(+), 17 deletions(-)

-- 
2.1.1



From armin at arbur.net  Mon Oct  6 23:22:28 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Mon, 6 Oct 2014 17:22:28 -0400
Subject: [gnutls-devel] [PATCH 1/3] Return an error if multiple PKCS11 URLs
 are added to a trust list
In-Reply-To: <cover.1412631297.git.armin@arbur.net>
References: <cover.1412631297.git.armin@arbur.net>
Message-ID: <0d5226301ae3764567dcc377c67551492a1fcd33.1412631297.git.armin@arbur.net>

Before, the new URL would overwrite the old URL, and the memory of theold URL
would be leaked. It is documented that only one URL can be used, so it should
be safe to reject any attempt to add another one.

Signed-off-by: Armin Burgmeier <armin at arbur.net>
---
 lib/x509/verify-high2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/x509/verify-high2.c b/lib/x509/verify-high2.c
index 776a854..e6dd884 100644
--- a/lib/x509/verify-high2.c
+++ b/lib/x509/verify-high2.c
@@ -258,6 +258,8 @@ gnutls_x509_trust_list_add_trust_file(gnutls_x509_trust_list_t list,
 		if (strncmp(ca_file, "pkcs11:", 7) == 0) {
 			unsigned pcrt_list_size = 0;
 
+			if (list->pkcs11_token != NULL)
+				return gnutls_assert_val(GNUTLS_E_INVALID_REQUEST);
 			list->pkcs11_token = gnutls_strdup(ca_file);
 
 			/* enumerate the certificates */
-- 
2.1.1



From armin at arbur.net  Mon Oct  6 23:28:46 2014
From: armin at arbur.net (Armin Burgmeier)
Date: Mon, 6 Oct 2014 17:28:46 -0400
Subject: [gnutls-devel] [PATCH 3/3] Add a test for PKCS11 CA iteration
In-Reply-To: <cover.1412631297.git.armin@arbur.net>
References: <cover.1412631297.git.armin@arbur.net>
Message-ID: <11d763e6e6124d95d1838129a50d66bcfcab62e2.1412631297.git.armin@arbur.net>

Signed-off-by: Armin Burgmeier <armin at arbur.net>
---
 tests/suite/pkcs11-chainverify.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/tests/suite/pkcs11-chainverify.c b/tests/suite/pkcs11-chainverify.c
index b88df08..50c7de6 100644
--- a/tests/suite/pkcs11-chainverify.c
+++ b/tests/suite/pkcs11-chainverify.c
@@ -143,6 +143,11 @@ void doit(void)
 		gnutls_datum_t tmp;
 		size_t j;
 
+		gnutls_x509_trust_list_iter_t get_ca_iter;
+		gnutls_datum_t get_ca_datum_test;
+		gnutls_datum_t get_ca_datum;
+		gnutls_x509_crt_t get_ca_crt;
+
 		if (debug)
 			printf("Chain '%s' (%d)...\n", chains[i].name,
 			       (int) i);
@@ -248,6 +253,32 @@ void doit(void)
 			exit(1);
 		}
 
+		/* test trust list iteration */
+		get_ca_iter = NULL;
+		while (gnutls_x509_trust_list_iter_get_ca(tl, &get_ca_iter, &get_ca_crt) == 0) {
+			ret = gnutls_x509_crt_export2(get_ca_crt, GNUTLS_X509_FMT_PEM, &get_ca_datum_test);
+			if (ret < 0) {
+				fail("gnutls_x509_crt_export2: %s\n", gnutls_strerror(ret));
+				exit(1);
+			}
+
+			ret = gnutls_x509_crt_export2(ca, GNUTLS_X509_FMT_PEM, &get_ca_datum);
+			if (ret < 0) {
+				fail("gnutls_x509_crt_export2: %s\n", gnutls_strerror(ret));
+				exit(1);
+			}
+
+			if (get_ca_datum_test.size != get_ca_datum.size ||
+			    memcmp(get_ca_datum_test.data, get_ca_datum.data, get_ca_datum.size) != 0) {
+				fail("gnutls_x509_trist_list_iter_get_ca: Unexpected certificate (%u != %u):\n\n%s\n\nvs.\n\n%s", get_ca_datum.size, get_ca_datum_test.size, get_ca_datum.data, get_ca_datum_test.data);
+				exit(1);
+			}
+
+			gnutls_free(get_ca_datum.data);
+			gnutls_free(get_ca_datum_test.data);
+			gnutls_x509_crt_deinit(get_ca_crt);
+		}
+
 		vdata[0].type = GNUTLS_DT_KEY_PURPOSE_OID;
 		vdata[0].data = (void *)chains[i].purpose;
 
-- 
2.1.1



From nmav at gnutls.org  Tue Oct  7 15:38:35 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 7 Oct 2014 15:38:35 +0200
Subject: [gnutls-devel] [PATCH 0/3] Support PKCS11 tokens when iterating
 a trust list
In-Reply-To: <cover.1412631297.git.armin@arbur.net>
References: <cover.1412631297.git.armin@arbur.net>
Message-ID: <CAJU7zaJFSgE15VOrqCE5bLZ2vqHcn+EiFWj36BjK96oBBGTnvw@mail.gmail.com>

On Mon, Oct 6, 2014 at 11:34 PM, Armin Burgmeier <armin at arbur.net> wrote:
> These patches add the missing functionality to also iterate the CAs of a
> PKCS11 token when iterating over the CAs stored in a trust list.
>
> Armin Burgmeier (3):
>   Return an error if multiple PKCS11 URLs are added to a trust list
>   Also iterate over the CA certificates in a PKCS11 token
>   Add a test for PKCS11 CA iteration

Patches applied. Thank you.

Nikos


From nmav at gnutls.org  Mon Oct 13 08:45:22 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 13 Oct 2014 08:45:22 +0200
Subject: [gnutls-devel] gnutls 3.1.27
Message-ID: <1413182722.18260.0.camel@nomad.lan>

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


* Version 3.1.27 (released 2014-10-13)

** libgnutls: Fixed issue with unexpected non-fatal errors resetting the
handshake's hash buffer, in applications using the heartbeat extension
or DTLS. Reported by Joeri de Ruiter.

** libgnutls: Corrected gnutls_x509_crl_verify() which would always report
a CRL signature as invalid. Reported by Armin Burgmeier.

** tools: updated libopts.

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


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

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

Here are the XZ and LZIP compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos




From nmav at gnutls.org  Mon Oct 13 08:46:33 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 13 Oct 2014 08:46:33 +0200
Subject: [gnutls-devel] gnutls 3.2.19
Message-ID: <1413182793.18260.2.camel@nomad.lan>

Hello,
 I've just released gnutls 3.2.19. This is a bugfix release on the
previous stable branch.

* Version 3.2.19 (released 2014-10-13)

** libgnutls: Fixes in the transparent import of PKCS #11 certificates.
Reported by Joseph Peruski.

** libgnutls: Fixed issue with unexpected non-fatal errors resetting the
handshake's hash buffer, in applications using the heartbeat extension
or DTLS. Reported by Joeri de Ruiter.

** libgnutls: fix issue in DTLS retransmission when session tickets
were in use; reported by Manuel P?gouri?-Gonnard.

** libgnutls: Prevent abort() in library if getrusage() fails. Try to
detect instead which of RUSAGE_THREAD and RUSAGE_SELF would work.

** guile: new 'set-session-server-name!' procedure; see the manual for
details.

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


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

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

Here are the XZ and LZIP compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos




From nmav at gnutls.org  Mon Oct 13 08:48:36 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 13 Oct 2014 08:48:36 +0200
Subject: [gnutls-devel] gnutls 3.3.9
Message-ID: <1413182916.18260.4.camel@nomad.lan>

Hello, 
 I've just released gnutls 3.3.9. This is a bug-fix release on
the stable branch. With this release the 3.3.x branch becomes the stable
branch.

* Version 3.3.9 (released 2014-10-13)

** libgnutls: Fixes in the transparent import of PKCS #11 certificates.
Reported by Joseph Peruski.

** libgnutls: Fixed issue with unexpected non-fatal errors resetting the
handshake's hash buffer, in applications using the heartbeat extension
or DTLS. Reported by Joeri de Ruiter.

** libgnutls: When both a trust module and additional CAs are present 
account the latter as well; reported by David Woodhouse.

** libgnutls: added GNUTLS_TL_GET_COPY flag for
gnutls_x509_trust_list_get_issuer(). That allows the function to be used
in a thread safe way when PKCS #11 trust modules are in use.

** libgnutls: fix issue in DTLS retransmission when session tickets
were in use; reported by Manuel P?gouri?-Gonnard.

** libgnutls-dane: Do not require the CA on a ca match to be direct CA.

** libgnutls: Prevent abort() in library if getrusage() fails. Try to
detect instead which of RUSAGE_THREAD and RUSAGE_SELF would work.

** guile: new 'set-session-server-name!' procedure; see the manual for
details.

** certtool: The authority key identifier will be set in a certificate only
if the CA's subject key identifier is set.

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


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

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

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.9.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.9.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.9.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.9.tar.lz.sig

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

regards,
Nikos




From INVALID.NOREPLY at gnu.org  Mon Oct 13 09:56:43 2014
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 13 Oct 2014 07:56:43 +0000
Subject: [gnutls-devel] [sr #108665] secp256k1 support wish
Message-ID: <20141013-075642.sv0.22056@savannah.gnu.org>

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

                 Summary: secp256k1 support wish
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Mon 13 Oct 2014 07:56:42 AM UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 1 - Wish
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: myrond at gmail.com
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Wishlist of secp256k1 support




    _______________________________________________________

Reply to this item at:

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

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



From nmav at gnutls.org  Mon Oct 13 13:33:03 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 13 Oct 2014 13:33:03 +0200
Subject: [gnutls-devel] CFP: Security Devroom @ FOSDEM'15
Message-ID: <CAJU7za+S6TJA+=4GcMDoTh-3SE05=_ZPeYXg5sUGzUY13862Uw@mail.gmail.com>

CFP: Security Devroom @ FOSDEM'15
AKA "Hardware and Software isolation mechanisms"


Next FOSDEM [1] will, again, have a security devroom, this time on the
topic of "Hardware and Software isolation mechanisms". We'd like to
invite submissions of talks and presentations from developers,
security researchers and other interested representatives of open
source and free software and hardware projects.

This is the call for talks and presentations that will take place in
the Security devroom at FOSDEM 2015.

Our topic this year:
As complex software tends to have bugs, methods to contain the damage
from a potentially serious bug (e.g., code injection, leak of memory
contents) are required. While such methods have been known and
available for a long time (HSMs and smart cards, privilege
separation), it is surprising that an attack like heartbleed required
the revocation of the private keys of a large part of the Internet.
For that reason Hardware and Software isolation mechanisms that could
mitigate such attacks, are again on the line, and the main theme of
this devroom.

For up-to-date submission and event information:
https://github.com/security-devroom/fosdem-2015

The security devroom will be held on Sunday 1st of February 2015 in
Brussels, Belgium at ULB room S.AW1.120 from 09:00 to 17:00.

I kindly ask you to forward this announcement to any relevant FOSS
project mailing list.

[1] https://fosdem.org/2015/
[2] https://github.com/security-devroom/fosdem-2015


From ludo at gnu.org  Tue Oct 14 22:38:44 2014
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Tue, 14 Oct 2014 22:38:44 +0200
Subject: [gnutls-devel] [PATCH] guile: Remove trailing zero in
	'gnutls_server_name_set' call.
Message-ID: <87r3ya1j57.fsf@gnu.org>

FYI I?ve just pushed this bug fix on ?master? (apologies for not
noticing the thinko in the first place!).

Nikos: could you backport it?

Thanks,
Ludo?.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 900 bytes
Desc: not available
URL: </pipermail/attachments/20141014/3d00d7a6/attachment.bin>

From nmav at gnutls.org  Wed Oct 15 15:25:34 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 15 Oct 2014 15:25:34 +0200
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
Message-ID: <CAJU7zaLCuh=sEEtg4MDiN+2ZuyoyDoEVCeQ9CCtJH+1uVEwL5w@mail.gmail.com>

Hello,
 Given the new and old attacks known for SSL 3.0, would it make sense
to disable SSL 3.0 in the default priority strings?

regards,
Nikos


From ametzler at bebt.de  Wed Oct 15 19:29:14 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 15 Oct 2014 19:29:14 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
Message-ID: <20141015172914.GB3039@downhill.g.la>

Hello,

the dtls test throws an error (exitstatus 3) on kfreebsd-*, where
3.3.8 succeeded. I am attaching the respective log.

If it helps I probably can do a git bisect, but not before the weekend.

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'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-fail_kfreebsd.gz
Type: application/gzip
Size: 3729 bytes
Desc: not available
URL: </pipermail/attachments/20141015/fc5a2ff4/attachment-0001.bin>

From tim.ruehsen at gmx.de  Wed Oct 15 21:22:12 2014
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Wed, 15 Oct 2014 21:22:12 +0200
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
In-Reply-To: <CAJU7zaLCuh=sEEtg4MDiN+2ZuyoyDoEVCeQ9CCtJH+1uVEwL5w@mail.gmail.com>
References: <CAJU7zaLCuh=sEEtg4MDiN+2ZuyoyDoEVCeQ9CCtJH+1uVEwL5w@mail.gmail.com>
Message-ID: <3474809.0glX9vOHCO@debian>

Am Mittwoch, 15. Oktober 2014, 15:25:34 schrieb Nikos Mavrogiannopoulos:
> Hello,
>  Given the new and old attacks known for SSL 3.0, would it make sense
> to disable SSL 3.0 in the default priority strings?
> 

Wget for example uses GnuTLS default settings as default.
Changing the default priority strings in GnuTLS gives the security benefit to 
Wget without changing Wget's code. That is a good reason to use GnuTLS (or 
other libraries) default settings in clients.

Some scenarios might break ... but since we all want to go away from SSLv3 
towards TLS (the sooner the better), it seems to be a good choice to me to 
change the default priority strings.

Just my opinion.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20141015/e695a472/attachment.sig>

From dkg at fifthhorseman.net  Wed Oct 15 22:00:17 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Oct 2014 16:00:17 -0400
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
In-Reply-To: <CAJU7zaLCuh=sEEtg4MDiN+2ZuyoyDoEVCeQ9CCtJH+1uVEwL5w@mail.gmail.com>
References: <CAJU7zaLCuh=sEEtg4MDiN+2ZuyoyDoEVCeQ9CCtJH+1uVEwL5w@mail.gmail.com>
Message-ID: <543ED251.20505@fifthhorseman.net>

On 10/15/2014 09:25 AM, Nikos Mavrogiannopoulos wrote:

>  Given the new and old attacks known for SSL 3.0, would it make sense
> to disable SSL 3.0 in the default priority strings?

Yes, i think so.  We could add SSL 3.0 into the %COMPAT%
pseudo-priority, but other than that, i don't think we should be
supporting SSLv3.0 by default any more.

	--dkg

PS i find i often need to refer to the full GnuTLS documentation when
i'm trying to cook up a new priority string.  Sometimes, i'm configuring
a machine that has a different version of GnuTLS than i have on my local
machine (where i have the full documentation installed)  Is the priority
string specification available in any of the manpages or as something
that one of the tools could emit by default?  (e.g. "gnutls-cli
--help-priority")  That would make it much easier in the future to know
how to craft a string that would interoperate with the version of gnutls
i'm testing with.

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

From dkg at fifthhorseman.net  Thu Oct 16 00:17:22 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Oct 2014 18:17:22 -0400
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
In-Reply-To: <SNT407-EAS814CC4C8867D3D32BF1E1392AA0@phx.gbl>
References: <SNT407-EAS814CC4C8867D3D32BF1E1392AA0@phx.gbl>
Message-ID: <543EF272.80003@fifthhorseman.net>

On 10/15/2014 05:40 PM, Peter Williams wrote:
> Some of us still use ssl v2
 [...]
> Dont rush, like lemmings.

we are well past the time that anyone who removes either sslv2 or sslv3
can be accused of "rushing" -- if you have special use cases that enable
you to privately use custom/non-standard protocols in ways that you
think are secure, that's fine.  No one will prevent you from doing that.

But please don't encourage the use of protocols with known problems on
the public 'net, where people need to interoperate with each other over
a known-hostile network.

	--dkg

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

From home_pw at msn.com  Wed Oct 15 23:40:15 2014
From: home_pw at msn.com (Peter Williams)
Date: Wed, 15 Oct 2014 14:40:15 -0700
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
Message-ID: <SNT407-EAS814CC4C8867D3D32BF1E1392AA0@phx.gbl>

Some of us still use ssl v2, between hsm and its client lib. But then the app protocol is not http (bring carefully thought out, to complement ssl features). One can force handshakes, to mac ciphertexr.

Lots of NSA deception & social engineering being used (to engineer upgrades...). Usual vendors and jounos being used, to manipulate the cryptonet.

Dont rush, like lemmings.



Sent from my Windows Phone
________________________________
From: Tim R?hsen<mailto:tim.ruehsen at gmx.de>
Sent: ?10/?15/?2014 12:22 PM
To: gnutls-devel at gnu.org<mailto:gnutls-devel at gnu.org>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0

Am Mittwoch, 15. Oktober 2014, 15:25:34 schrieb Nikos Mavrogiannopoulos:
> Hello,
>  Given the new and old attacks known for SSL 3.0, would it make sense
> to disable SSL 3.0 in the default priority strings?
>

Wget for example uses GnuTLS default settings as default.
Changing the default priority strings in GnuTLS gives the security benefit to
Wget without changing Wget's code. That is a good reason to use GnuTLS (or
other libraries) default settings in clients.

Some scenarios might break ... but since we all want to go away from SSLv3
towards TLS (the sooner the better), it seems to be a good choice to me to
change the default priority strings.

Just my opinion.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141015/8f4f800c/attachment.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at gnu.org
https://lists.gnu.org/mailman/listinfo/gnutls-devel

From home_pw at msn.com  Thu Oct 16 00:50:26 2014
From: home_pw at msn.com (Peter Williams)
Date: Wed, 15 Oct 2014 22:50:26 +0000
Subject: [gnutls-devel]
	=?utf-8?q?disabling_SSL_3=2E0_by_default_in_3=2E4?= =?utf-8?q?=2E0?=
Message-ID: <SNT407-EAS389C5A9029A931261389A6692AA0@phx.gbl>

Folks are ?Rushing? because, last week, this was not even on the radar - even though the use of standards committees to engineer-in cbc mode oracle attacks has been going on for 20 years. Same goes for the packet drivers and their careful reaction to inbound bit patterns that changes the code path takes, that then play the role of the JavaScript ?in the latest cbc mode oracle attack?.


And so it continues (in this or other guise). Strange that folks just WONT handshake, at the end of APDU exchange (since it has so little cost, 20 years on)


Don't really know what to recommend, when the ?trustworthy? technical standards forums (IETF) or their review processes (IESG) are themselves fundamentally untrustworthy, in any crypto matter. Everyone knows US delegation to ISO/ITU-T was always an arm of dept of state (and woe betide anyone expenses payment, if you stepped out of line?)


I asked Steve Kent once, exempting a French official report on the crash of a Russian jet at an air show (due to French spying) - why the report should be trusted - since it was an obvious cover up (and actively misrepresented culpability concerning deaths in the crowd).. His answer was - that ?official trust? exists to be manipulated - when one is dealing with national security issues. The ?investment? in standards was there to project such trust attacks, and engineer an deception-friendly environment, focused on human weakness, consumer or admin (or crypto officer) alike.



Have fun.





Sent from Surface Pro





From: Daniel Kahn Gillmor
Sent: ?Wednesday?, ?October? ?15?, ?2014 ?3?:?17? ?PM
To: Peter Williams, Tim R?hsen, gnutls-devel at gnu.org
Cc: GnuTLS development list





On 10/15/2014 05:40 PM, Peter Williams wrote:
> Some of us still use ssl v2
 [...]
> Dont rush, like lemmings.

we are well past the time that anyone who removes either sslv2 or sslv3
can be accused of "rushing" -- if you have special use cases that enable
you to privately use custom/non-standard protocols in ways that you
think are secure, that's fine.  No one will prevent you from doing that.

But please don't encourage the use of protocols with known problems on
the public 'net, where people need to interoperate with each other over
a known-hostile network.

        --dkg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141015/e40bd9cc/attachment-0001.html>

From tim.ruehsen at gmx.de  Thu Oct 16 12:35:45 2014
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Thu, 16 Oct 2014 12:35:45 +0200
Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0
In-Reply-To: <SNT407-EAS389C5A9029A931261389A6692AA0@phx.gbl>
References: <SNT407-EAS389C5A9029A931261389A6692AA0@phx.gbl>
Message-ID: <1946351.cakqe40cyb@debian>

Am Mittwoch, 15. Oktober 2014, 22:50:26 schrieb Peter Williams:
> Folks are ?Rushing? because, last week, this was not even on the radar -
> even though the use of standards committees to engineer-in cbc mode oracle
> attacks has been going on for 20 years. Same goes for the packet drivers
> and their careful reaction to inbound bit patterns that changes the code
> path takes, that then play the role of the JavaScript ?in the latest cbc
> mode oracle attack?.

It's time to rush because the threat just became *real*.
We (developers/coders) can't do much on 'unknown' threats.

 
> And so it continues (in this or other guise). Strange that folks just WONT
> handshake, at the end of APDU exchange (since it has so little cost, 20
> years on)
 
> 
> Don't really know what to recommend, when the ?trustworthy? technical
> standards forums (IETF) or their review processes (IESG) are themselves
> fundamentally untrustworthy, in any crypto matter. Everyone knows US
> delegation to ISO/ITU-T was always an arm of dept of state (and woe betide
> anyone expenses payment, if you stepped out of line?)
 
> 
> I asked Steve Kent once, exempting a French official report on the crash of
> a Russian jet at an air show (due to French spying) - why the report should
> be trusted - since it was an obvious cover up (and actively misrepresented
> culpability concerning deaths in the crowd).. His answer was - that
> ?official trust? exists to be manipulated - when one is dealing with
> national security issues. The ?investment? in standards was there to
> project such trust attacks, and engineer an deception-friendly environment,
> focused on human weakness, consumer or admin (or crypto officer) alike.
 
Lies everywhere ;-) You simple can't distinguish between a lie and the truth. 
So I simply can't take *anything* of this into my calculations.

However, if your conclusion is 'not to rush'... how long should we wait before 
you don't call it 'rushing' any more ? What is your plan ? Firing FUD and tell 
people to sit and wait ? Hmm, maybe I got something wrong... but I can't find 
anything *useful* within your writing, sorry.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20141016/861e3aac/attachment.sig>

From nmav at gnutls.org  Thu Oct 16 12:59:48 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Oct 2014 12:59:48 +0200
Subject: [gnutls-devel] priority strings [was: disabling SSL 3.0 by default
	in 3.4.0]
Message-ID: <CAJU7zaLOHn2Qtijtkhb27fD_KzcnxA4U_X-wphWw32wnyxVjGQ@mail.gmail.com>

On Wed, Oct 15, 2014 at 10:00 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:

> PS i find i often need to refer to the full GnuTLS documentation when
> i'm trying to cook up a new priority string.  Sometimes, i'm configuring
> a machine that has a different version of GnuTLS than i have on my local
> machine (where i have the full documentation installed)  Is the priority
> string specification available in any of the manpages or as something
> that one of the tools could emit by default?  (e.g. "gnutls-cli
> --help-priority")  That would make it much easier in the future to know
> how to craft a string that would interoperate with the version of gnutls
> i'm testing with.

No, but it is probably a good idea to have it. I'll see to it.

regards,
Nikos


From home_pw at msn.com  Thu Oct 16 17:12:22 2014
From: home_pw at msn.com (Peter Williams)
Date: Thu, 16 Oct 2014 15:12:22 +0000
Subject: [gnutls-devel]
	=?utf-8?q?disabling_SSL_3=2E0_by_default_in_3=2E4?= =?utf-8?q?=2E0?=
Message-ID: <SNT407-EAS66D943BA3A151D3DB3EE8892AB0@phx.gbl>

last email, on a non topic.


Why the ?rush? now  - when there was no imperative last month to disable sslv3 (when the same class of attack on steam based cbc-modes existed, same traffic levels (almost zero), same level of noted web-exploitation (none))? Answer! Because cybercommand is calling the shots, and running a drill!


anyway, its good that folk know generally realize that certain US defense and national security vendors (or their civilian proxies), who contributed to SSL v3 20 years ago, did so with FULL KNOWLEDGE of what they were doing.


One should assume it goes on today, with the same intensity - doing whatever it takes to subvert commodity-upgrade crypto at the design or more likely the implementation level. And that starts with subverting the leadership folk (what?s new!)


One might wish to chat to cisco engineers, who were ?required? to alter the router?s key management protocol, which consisted of layered signed and encrypted PKCS7 APDUs, over ssl v3 for anti-replay; for a good case study of crypto subversion using cbc-exploits similar to those ?suddenly? used against ssl v3. What?s worse, ?for compatibility?, it now comes with WINDOWS SERVER? Of course, one REALLY wants it applied to key management (vs. cat picture downloading). If you go log searching for historical exploit evidence, start there (not on cat downloading sites).


But, now I?m preaching on CBC, so I stop.  Its all ?commodity crypto?, and thus a toy to make folk feel good.



Sent from Windows Mail





From: Tim R?hsen
Sent: ?Thursday?, ?October? ?16?, ?2014 ?3?:?35? ?AM
To: gnutls-devel at gnu.org
Cc: peter Msn, Daniel Kahn Gillmor, GnuTLS development list





Am Mittwoch, 15. Oktober 2014, 22:50:26 schrieb Peter Williams:
> Folks are ?Rushing? because, last week, this was not even on the radar -
> even though the use of standards committees to engineer-in cbc mode oracle
> attacks has been going on for 20 years. Same goes for the packet drivers
> and their careful reaction to inbound bit patterns that changes the code
> path takes, that then play the role of the JavaScript ?in the latest cbc
> mode oracle attack?.

It's time to rush because the threat just became *real*.
We (developers/coders) can't do much on 'unknown' threats.

 
> And so it continues (in this or other guise). Strange that folks just WONT
> handshake, at the end of APDU exchange (since it has so little cost, 20
> years on)
 
> 
> Don't really know what to recommend, when the ?trustworthy? technical
> standards forums (IETF) or their review processes (IESG) are themselves
> fundamentally untrustworthy, in any crypto matter. Everyone knows US
> delegation to ISO/ITU-T was always an arm of dept of state (and woe betide
> anyone expenses payment, if you stepped out of line?)
 
> 
> I asked Steve Kent once, exempting a French official report on the crash of
> a Russian jet at an air show (due to French spying) - why the report should
> be trusted - since it was an obvious cover up (and actively misrepresented
> culpability concerning deaths in the crowd).. His answer was - that
> ?official trust? exists to be manipulated - when one is dealing with
> national security issues. The ?investment? in standards was there to
> project such trust attacks, and engineer an deception-friendly environment,
> focused on human weakness, consumer or admin (or crypto officer) alike.
 
Lies everywhere ;-) You simple can't distinguish between a lie and the truth. 
So I simply can't take *anything* of this into my calculations.

However, if your conclusion is 'not to rush'... how long should we wait before 
you don't call it 'rushing' any more ? What is your plan ? Firing FUD and tell 
people to sit and wait ? Hmm, maybe I got something wrong... but I can't find 
anything *useful* within your writing, sorry.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141016/137ac723/attachment.html>

From nmav at gnutls.org  Thu Oct 16 19:59:17 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Oct 2014 19:59:17 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <20141015172914.GB3039@downhill.g.la>
References: <20141015172914.GB3039@downhill.g.la>
Message-ID: <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>

On Wed, Oct 15, 2014 at 7:29 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> the dtls test throws an error (exitstatus 3) on kfreebsd-*, where
> 3.3.8 succeeded. I am attaching the respective log.
> If it helps I probably can do a git bisect, but not before the weekend.

Didn't have time to check. I bisect would be great.

regards,
Nikos


From ametzler at bebt.de  Sat Oct 18 08:25:02 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 18 Oct 2014 08:25:02 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
References: <20141015172914.GB3039@downhill.g.la>
 <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
Message-ID: <20141018062502.GB3609@downhill.g.la>

On 2014-10-16 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Wed, Oct 15, 2014 at 7:29 PM, Andreas Metzler <ametzler at bebt.de> wrote:
>> the dtls test throws an error (exitstatus 3) on kfreebsd-*, where
>> 3.3.8 succeeded. I am attaching the respective log.
>> If it helps I probably can do a git bisect, but not before the weekend.

> Didn't have time to check. I bisect would be great.
[...]

Hello,

the first failing commit is this one:
| commit 74344ab30e166fc83fe21cbb671aef745a310259
| Date:   Thu Oct 2 14:10:16 2014 +0200
| 
|     tests: added -r option to dtls-stress
| 
|     That allows it to replay messages in a kind of arbitrary way.
 
hth, 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 n.mavrogiannopoulos at gmail.com  Sat Oct 18 10:44:19 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 18 Oct 2014 10:44:19 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <20141018062502.GB3609@downhill.g.la>
References: <20141015172914.GB3039@downhill.g.la>
 <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
 <20141018062502.GB3609@downhill.g.la>
Message-ID: <62909380-e2c1-4abb-9bea-018bd7b975eb@email.android.com>

Its a new test added and may have issues on that system. you may ignore it ans If you could send me the debugging output of a run I will check it.

On 18 October 2014 08:25:02 CEST, Andreas Metzler <ametzler at bebt.de> wrote:
>On 2014-10-16 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Wed, Oct 15, 2014 at 7:29 PM, Andreas Metzler <ametzler at bebt.de>
>wrote:
>>> the dtls test throws an error (exitstatus 3) on kfreebsd-*, where
>>> 3.3.8 succeeded. I am attaching the respective log.
>>> If it helps I probably can do a git bisect, but not before the
>weekend.
>
>> Didn't have time to check. I bisect would be great.
>[...]
>
>Hello,
>
>the first failing commit is this one:
>| commit 74344ab30e166fc83fe21cbb671aef745a310259
>| Date:   Thu Oct 2 14:10:16 2014 +0200
>| 
>|     tests: added -r option to dtls-stress
>| 
>|     That allows it to replay messages in a kind of arbitrary way.
> 
>hth, cu Andreas

-- 
Sent fron my mobile. Please excuse my brevity.


From ametzler at bebt.de  Sat Oct 18 13:18:38 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 18 Oct 2014 13:18:38 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <62909380-e2c1-4abb-9bea-018bd7b975eb@email.android.com>
References: <20141015172914.GB3039@downhill.g.la>
 <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
 <20141018062502.GB3609@downhill.g.la>
 <62909380-e2c1-4abb-9bea-018bd7b975eb@email.android.com>
Message-ID: <20141018111838.GA1270@downhill.g.la>

On 2014-10-18 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> Its a new test added and may have issues on that system. you may ignore it ans If you could send me the debugging output of a run I will check it.
[...]

Thanks find attached the output of
---------
{ ./dtls-stress -full -shello 01234 -sfinished 01 -cfinished 01234 CCertificate CKeyExchange CCertificateVerify CChangeCipherSpec CFinished -d 1024 ; echo dtls-stress exit code $? ; } 2>&1 | tee /tmp/dtls-stress-part-1

{ ./dtls-stress -d 1024 -full -r -shello 42130 -sfinished 10 -cfinished 43210 SHello SKeyExchange SHelloDone CKeyExchange CChangeCipherSpec CFinished SChangeCipherSpec SCertificate SFinished ; echo dtls-stress exit code $? ; } 2>&1 | tee /tmp/dtls-stress-part-2
---------

on both regular linux i586 and kfreebsd.

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'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-test-output.tar.gz
Type: application/gzip
Size: 31770 bytes
Desc: not available
URL: </pipermail/attachments/20141018/40101e0d/attachment-0001.bin>

From hemangi.dharap at hp.com  Fri Oct 17 16:41:46 2014
From: hemangi.dharap at hp.com (Dharap, Hemangi)
Date: Fri, 17 Oct 2014 14:41:46 +0000
Subject: [gnutls-devel] POODLE: SSLv3.0 vulnerability (CVE-2014-3566)
Message-ID: <CECDD70B89C4BE4FABA44747263EEF6F1D03B1E2@G5W2732.americas.hpqcorp.net>

Hello,

Could you please advise whether GnuTLS is affected by the POODLE SSL V3.0 vulnerability? If it is affected, could you please share with us the fix availability plans? Many thanks!

Regards,
Hemangi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141017/4ea1723c/attachment.html>

From dev at cor0.com  Fri Oct 17 22:19:19 2014
From: dev at cor0.com (dev)
Date: Fri, 17 Oct 2014 16:19:19 -0400 (EDT)
Subject: [gnutls-devel] [gnutls-help] gnutls 3.3.9
In-Reply-To: <1413182916.18260.4.camel@nomad.lan>
References: <1413182916.18260.4.camel@nomad.lan>
Message-ID: <1204426961.49599.1413577159550.JavaMail.vpopmail@webmail2.networksolutionsemail.com>



On October 13, 2014 at 2:48 AM Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:
> Hello,
>  I've just released gnutls 3.3.9. This is a bug-fix release on
> the stable branch. With this release the 3.3.x branch becomes the
> stable
> branch.
>
> * Version 3.3.9 (released 2014-10-13)

Fails to build in the usual way and in the usual place on Solaris 10 :


$ tail -20  ../gnutls-3.3.9_SunOS5.10_sparcv9_001.build.log
  CC       tpm.lo
  CC       fips.lo
  CC       safe-memset.lo
  CC       inet_pton.lo
  CC       gnutls_srp.lo
  CC       gnutls_psk.lo
  CCLD     libgnutls.la
Undefined                       first referenced
 symbol                             in file
inet_aton
                          x509/.libs/libgnutls_x509.a(rfc2818_hostname.o)
 (symbol belongs to implicit dependency /lib/64/libnsl.so.1)
ld: fatal: symbol referencing errors. No output written to
.libs/libgnutls.so.28.41.1
gmake[4]: *** [libgnutls.la] Error 2
gmake[4]: Leaving directory
`/usr/local/build/gnutls-3.3.9_SunOS5.10_sparcv9_001/lib'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/usr/local/build/gnutls-3.3.9_SunOS5.10_sparcv9_001/lib'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/local/build/gnutls-3.3.9_SunOS5.10_sparcv9_001/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/local/build/gnutls-3.3.9_SunOS5.10_sparcv9_001'
gmake: *** [all] Error 2
$


One of these days I will dig around and find whatever linkage options
are needed and perhaps get them sorted out in the mysterious Makefile
down in ./lib

Dennis


From nmav at gnutls.org  Mon Oct 20 15:06:56 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 20 Oct 2014 15:06:56 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <20141018111838.GA1270@downhill.g.la>
References: <20141015172914.GB3039@downhill.g.la>
 <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
 <20141018062502.GB3609@downhill.g.la>
 <62909380-e2c1-4abb-9bea-018bd7b975eb@email.android.com>
 <20141018111838.GA1270@downhill.g.la>
Message-ID: <CAJU7zaJWiSBik=pv+xBqWfbEkyTWSD+ZQaSaRedciOq-mqS1Vw@mail.gmail.com>

On Sat, Oct 18, 2014 at 1:18 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> On 2014-10-18 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
>> Its a new test added and may have issues on that system. you may ignore it ans If you could send me the debugging output of a run I will check it.
> [...]
>
> Thanks find attached the output of
> ---------
> { ./dtls-stress -full -shello 01234 -sfinished 01 -cfinished 01234 CCertificate CKeyExchange CCertificateVerify CChangeCipherSpec CFinished -d 1024 ; echo dtls-stress exit code $? ; } 2>&1 | tee /tmp/dtls-stress-part-1
>
> { ./dtls-stress -d 1024 -full -r -shello 42130 -sfinished 10 -cfinished 43210 SHello SKeyExchange SHelloDone CKeyExchange CChangeCipherSpec CFinished SChangeCipherSpec SCertificate SFinished ; echo dtls-stress exit code $? ; } 2>&1 | tee /tmp/dtls-stress-part-2
> ---------
> on both regular linux i586 and kfreebsd.

Thanks, it seems that in the kfreebsd code the replayed packet is only
sent for some reason but not the intended one. It may have to do with
limitation on send buffers? In any case I've applied this [0] but not
sure whether it would fix the issue.

[0]. https://gitorious.org/gnutls/gnutls/commit/1b56251d8bcb34fd18e34bc0e44a5e83f750d1d8


From ametzler at bebt.de  Mon Oct 20 19:33:27 2014
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 20 Oct 2014 19:33:27 +0200
Subject: [gnutls-devel] gnutls 3.3.9 - dtls testsuite error on kfreebsd*
In-Reply-To: <CAJU7zaJWiSBik=pv+xBqWfbEkyTWSD+ZQaSaRedciOq-mqS1Vw@mail.gmail.com>
References: <20141015172914.GB3039@downhill.g.la>
 <CAJU7zaJxgQuFNjH=5F7V1tEhs2N+ggd+kEUPPwJYf-APpVCKvg@mail.gmail.com>
 <20141018062502.GB3609@downhill.g.la>
 <62909380-e2c1-4abb-9bea-018bd7b975eb@email.android.com>
 <20141018111838.GA1270@downhill.g.la>
 <CAJU7zaJWiSBik=pv+xBqWfbEkyTWSD+ZQaSaRedciOq-mqS1Vw@mail.gmail.com>
Message-ID: <20141020173327.GB1317@downhill.g.la>

On 2014-10-20 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sat, Oct 18, 2014 at 1:18 PM, Andreas Metzler <ametzler at bebt.de> wrote:
[...]
> Thanks, it seems that in the kfreebsd code the replayed packet is only
> sent for some reason but not the intended one. It may have to do with
> limitation on send buffers? In any case I've applied this [0] but not
> sure whether it would fix the issue.

> [0]. https://gitorious.org/gnutls/gnutls/commit/1b56251d8bcb34fd18e34bc0e44a5e83f750d1d8

Hello,

it does not seem to fix the issue, the output changes a little bit
though.

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'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-test-output.v2.tar.gz
Type: application/gzip
Size: 9404 bytes
Desc: not available
URL: </pipermail/attachments/20141020/7a318bf5/attachment-0001.bin>

From jonbae77 at gmail.com  Wed Oct 22 11:25:52 2014
From: jonbae77 at gmail.com (Jon bae)
Date: Wed, 22 Oct 2014 11:25:52 +0200
Subject: [gnutls-devel] gnutls and the actual mingw-w64
Message-ID: <54477820.5040500@gmail.com>

Hello gnutls team,
I use gnutls for my automatic build system witch use msys2 and mingw-w64:
https://github.com/jb-alvarado/media-autobuild_suite

Since some days I can not compile gnutls anymore. First I contact the 
developer from msys2, but they tell me is a bug in gnutls with the new 
mingw-w64 Version.

Here is the message what I get:

*make[4]: Entering directory '/build32/gnutls-3.3.9/lib/x509'
   CC       common.lo
In file included from ./../../gl/time.h:39:0,
                  from ./../../gl/sys/stat.h:44,
                  from ./../gnutls_int.h:52,
                  from common.c:23:
./../../gl/time.h:461:1: error: expected identifier or '(' before '{' token
  _GL_FUNCDECL_SYS (localtime_r, struct tm *, (time_t const *restrict
__timer,
  ^
./../../gl/time.h:483:1: error: expected identifier or '(' before '{' token
  _GL_FUNCDECL_SYS (gmtime_r, struct tm *, (time_t const *restrict __timer,
  ^
Makefile:1372: recipe for target 'common.lo' failed
make[4]: *** [common.lo] Error 1
make[4]: Leaving directory '/build32/gnutls-3.3.9/lib/x509'*



Regards

Jonathan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141022/750880a8/attachment.html>

From nmav at gnutls.org  Thu Oct 23 09:16:25 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 23 Oct 2014 09:16:25 +0200
Subject: [gnutls-devel] gnutls and the actual mingw-w64
In-Reply-To: <54477820.5040500@gmail.com>
References: <54477820.5040500@gmail.com>
Message-ID: <CAJU7zaK5RgxZEAS7Kq+tPqHH-OWLL78YWnqVaKFYN=Od7vkC-Q@mail.gmail.com>

On Wed, Oct 22, 2014 at 11:25 AM, Jon bae <jonbae77 at gmail.com> wrote:
> Hello gnutls team,
> I use gnutls for my automatic build system witch use msys2 and mingw-w64:
> https://github.com/jb-alvarado/media-autobuild_suite
> Since some days I can not compile gnutls anymore. First I contact the
> developer from msys2, but they tell me is a bug in gnutls with the new
> mingw-w64 Version.

Hi,
 That looks like a gnulib issue. I'll update gnulib in the 3.3 branch,
but you may try yourself by following the glimport rule in cfg.mk.

regards,
Nikos


From INVALID.NOREPLY at gnu.org  Thu Oct 23 23:29:19 2014
From: INVALID.NOREPLY at gnu.org (bitto)
Date: Thu, 23 Oct 2014 21:29:19 +0000
Subject: [gnutls-devel] [sr #108674] Request for feature, support for SSLv23
Message-ID: <20141023-212918.sv97177.57261@savannah.gnu.org>

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

                 Summary: Request for feature, support for SSLv23
                 Project: GnuTLS
            Submitted by: bitto
            Submitted on: Thu 23 Oct 2014 21:29:18 GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 6 - Security
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

As the new poodle exploit is out.
Please implement SSLv23 with TLS1.2 support.

Error message;
Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2





    _______________________________________________________

Reply to this item at:

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

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



From INVALID.NOREPLY at gnu.org  Fri Oct 24 10:45:19 2014
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 24 Oct 2014 08:45:19 +0000
Subject: [gnutls-devel] [sr #108674] Request for feature, support for SSLv23
In-Reply-To: <20141023-212918.sv97177.57261@savannah.gnu.org>
References: <20141023-212918.sv97177.57261@savannah.gnu.org>
Message-ID: <20141024-114519.sv707.7119@savannah.gnu.org>

Update of sr #108674 (project gnutls):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

I don't quite understand the proposal here. GnuTLS implements TLS 1.2 support
several years now. SSLv23 is just a string for openssl that has no meaning in
gnutls. If you want to use TLS 1.2 please read the gnutls manual. It is
enabled by default.


    _______________________________________________________

Reply to this item at:

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

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



From nmav at gnutls.org  Fri Oct 24 15:42:29 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 24 Oct 2014 15:42:29 +0200
Subject: [gnutls-devel] status on encrypt-then-mac (RFC7366)
Message-ID: <CAJU7zaLdmdfWDO2=TJ7Mg+du7aiq56CpHpRDtApWB9Qv2q398g@mail.gmail.com>

Hi,
 I've implemented the encrypt-then-mac RFC in a special branch [0],
but I've realized that the existing deployed servers on the internet
that were advertized in [1] do not actually follow the protocol
described in the document. This was also noticed by the NSS people in
[2],  so I'm indefinitely postponing the merge of that TLS extension
to gnutls 3.4, until there no issues with interoperability.

regards,
Nikos


[0]. https://www.gitorious.org/gnutls/gnutls/commit/cfc5cb2032a61566599b91f3b2ed5a182216ae24
[1]. http://www.ietf.org/mail-archive/web/tls/current/msg12664.html
[2]. https://bugzilla.mozilla.org/show_bug.cgi?id=972145