From danut_12 at yahoo.com  Tue Oct  2 11:59:21 2012
From: danut_12 at yahoo.com (slobozian daniel)
Date: Tue, 2 Oct 2012 10:59:21 +0100 (BST)
Subject: p11tool token management
Message-ID: <1349171961.80693.YahooMailNeo@web29502.mail.ird.yahoo.com>

Hello,
?
???? I'm trying to use
p11tool for a server application. I need it to stock server's private key and?to
communicate with the server application that uses gnutls API.? I don?t
have a hardware smart card. Therefore I want to use a software p11. I supposed
that p11tool allows me to do that because the command --list-tokens shows me 5
existing tokens (My machine is on ubuntu 12.04). But there is no option to
create a token, only to initialize.
??? My first question is if
it is possible to stock a private key and a certificate with p11tool without a
hardware device. If so do I have to install any other software in order to
create a software token? If, on the other hand, it?s not possible to do that
with p11tool, can I still use gnutls to connect to a local software P11?
?
Thank you in advance for your answer
Regards,
Daniel Slobozian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121002/eac79e59/attachment.htm>

From nmav at gnutls.org  Wed Oct  3 14:23:15 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 3 Oct 2012 14:23:15 +0200
Subject: p11tool token management
In-Reply-To: <1349171961.80693.YahooMailNeo@web29502.mail.ird.yahoo.com>
References: <1349171961.80693.YahooMailNeo@web29502.mail.ird.yahoo.com>
Message-ID: <CAJU7zaKmFFuXdpXc4xOWs_v=Pqg9asv87yiRbyb7MnamZN9gSw@mail.gmail.com>

On Tue, Oct 2, 2012 at 11:59 AM, slobozian daniel <danut_12 at yahoo.com> wrote:
> Hello,
>
>      I'm trying to use p11tool for a server application. I need it to stock
> server's private key and to communicate with the server application that
> uses gnutls API.  I don?t have a hardware smart card. Therefore I want to
> use a software p11.

Which one? There are several software PKCS #11 tokens. Which one do you use?

> I supposed that p11tool allows me to do that because the
> command --list-tokens shows me 5 existing tokens (My machine is on ubuntu
> 12.04).

You can check which software modules you have by checking
/etc/pkcs11/modules. Those are the ones that are loaded by p11-kit.

> But there is no option to create a token, only to initialize.

You cannot create tokens using PKCS #11. PKCS #11 is a smart card API,
and it is not easy to create smart cards from software :)

>     My first question is if it is possible to stock a private key and a
> certificate with p11tool without a hardware device. If so do I have to
> install any other software in order to create a software token? If, on the

You'll have to install a software token. I cannot recommend any
because I don't know them, but check for soft-hsm or so.

regards,
Nikos



From danut_12 at yahoo.com  Thu Oct  4 10:59:38 2012
From: danut_12 at yahoo.com (slobozian daniel)
Date: Thu, 4 Oct 2012 09:59:38 +0100 (BST)
Subject: p11tool token management
In-Reply-To: <CAJU7zaKmFFuXdpXc4xOWs_v=Pqg9asv87yiRbyb7MnamZN9gSw@mail.gmail.com>
References: <1349171961.80693.YahooMailNeo@web29502.mail.ird.yahoo.com>
	<CAJU7zaKmFFuXdpXc4xOWs_v=Pqg9asv87yiRbyb7MnamZN9gSw@mail.gmail.com>
Message-ID: <1349341178.90316.YahooMailNeo@web29506.mail.ird.yahoo.com>

Hello,

Thank you for your answers. You were very helpful. I have some errors when using gnutls 3.1.1 APIbut i will post them in another thread.

regards,
Daniel Slobozian



________________________________
 From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
To: slobozian daniel <danut_12 at yahoo.com> 
Cc: "help-gnutls at gnu.org" <help-gnutls at gnu.org> 
Sent: Wednesday, October 3, 2012 2:23 PM
Subject: Re: p11tool token management
 
On Tue, Oct 2, 2012 at 11:59 AM, slobozian daniel <danut_12 at yahoo.com> wrote:
> Hello,
>
>? ? ? I'm trying to use p11tool for a server application. I need it to stock
> server's private key and to communicate with the server application that
> uses gnutls API.? I don?t have a hardware smart card. Therefore I want to
> use a software p11.

Which one? There are several software PKCS #11 tokens. Which one do you use?

> I supposed that p11tool allows me to do that because the
> command --list-tokens shows me 5 existing tokens (My machine is on ubuntu
> 12.04).

You can check which software modules you have by checking
/etc/pkcs11/modules. Those are the ones that are loaded by p11-kit.

> But there is no option to create a token, only to initialize.

You cannot create tokens using PKCS #11. PKCS #11 is a smart card API,
and it is not easy to create smart cards from software :)

>? ?  My first question is if it is possible to stock a private key and a
> certificate with p11tool without a hardware device. If so do I have to
> install any other software in order to create a software token? If, on the

You'll have to install a software token. I cannot recommend any
because I don't know them, but check for soft-hsm or so.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121004/f6d3e13a/attachment.htm>

From danut_12 at yahoo.com  Thu Oct  4 11:46:19 2012
From: danut_12 at yahoo.com (slobozian daniel)
Date: Thu, 4 Oct 2012 10:46:19 +0100 (BST)
Subject: gnutls_3.1.1issues
Message-ID: <1349343979.81220.YahooMailNeo@web29503.mail.ird.yahoo.com>

Hello,

I encountered some issues while using gnutls 3.1.1 API on Ubuntu 12.04 with VirtualBox.?
Software
that I installed:
????????? m4??????????????????????? ? ?????????? 1.4.16
????????? gmp????????????????????? ? ??????????? 5.0.5
????????? nettle??????????????????? ???????????? 2.5
????????? p11-kit???????????????? ? ?????????? 0.13
????????? trousers?????????????? ???????????? 0.3.9
????????? tasn1??????????????????? ???????????? 2.13
????????? gnutls?????????????????? ???????????? 3.1.1
cfd

The first issue? appeared while using the functiongnutls_x509_crt_init.? Here is what I did:

gnutls_x509_crt_t
gnutls_certificate;
if(gnutls_x509_crt_init(&gnutls_certificate)<0)
??????????????? {
?????????????????????????????? CRYPTO_ERROR("Certificate
init failed");
?????????????????????????????? return FAILURE;
??????????????? }
Thefunctionreturns a negative value. I launched my code with gdb and got the stack trace.Itseems that _gnutls_get_pkix() returned a NULL valuebut I dont know why.

Here is the stack:


gnutls_x509_crt_init
(cert=0xbffff288) at x509.c:47
47??????????? {
48??????????? ? gnutls_x509_crt_t tmp = gnutls_calloc (1, sizeof (gnutls_x509_crt_int));
51??????????? ? if (!tmp)
54??????????? ? result = asn1_create_element (_gnutls_get_pkix
(),"PKIX1.Certificate", &tmp->cert);
?
??????????????? asn1_create_element
(definitions=0x0, source_name=0x8139b9f "PKIX1.Certificate",
element=0x8174c70) at structure.c:667
??????????????? 667????????? {
??????????????? 671????????? ? dest_node =
_asn1_copy_structure2 (definitions, source_name);
?
?????????????????????????????? _asn1_copy_structure2
(source_name=0x8139b9f "PKIX1.Certificate", root=0x0) at
structure.c:448
?????????????????????????????? 448????????? ? source_node = asn1_find_node (root, source_name);
?
?????????????????????????????????????????????? asn1_find_node
(pointer=0x0, name=0x8139b9f "PKIX1.Certificate") at parser_aux.c:94
?????????????????????????????????????????????? 94??????????? {
?????????????????????????????????????????????? 99??????????? ? if (pointer == NULL)
?????????????????????????????????????????????? 103????????? ??? return NULL;
?????????????????????????????????????????????? 186????????? }
?
?????????????????????????????? 450????????? ? return _asn1_copy_structure3 (source_node);
?
?????????????????????????????????????????????? _asn1_copy_structure3
(source_node=0x0) at structure.c:376
?????????????????????????????????????????????? 376????????? {
?????????????????????????????????????????????? 381????????? ??? return NULL;
?????????????????????????????????????????????? 380????????? ? if (source_node == NULL)
?????????????????????????????????????????????? 440????????? }
?
??????????????? 673????????? ? if (dest_node ==
NULL)
??????????????? 674????????? ??? return
ASN1_ELEMENT_NOT_FOUND;
??????????????? 684????????? }
?
56??????????? ? if (result != ASN1_SUCCESS)
58??????????? ????? gnutls_assert ();
59??????????? ????? gnutls_free (tmp);
60??????????? ????? return _gnutls_asn2err (result);
61??????????? }

The second issue appeared while using the function gnutls_rnd. Here is what i did:
unsigned char noncebuf[128];
gnutls_datum_t nonce = { noncebuf, sizeof (noncebuf) };
gnutls_rnd (GNUTLS_RND_RANDOM, nonce.data, nonce.size);

The program ends with a segmentation fault.

Here is the stack trace:

gnutls_rnd (level=GNUTLS_RND_RANDOM,
data=0xbffff24c, len=128) at random.c:73
73?????????? {
74?????????? ? return _gnutls_rnd(level, data, len);
?
_gnutls_rnd (len=128,
data=0xbffff24c, level=GNUTLS_RND_RANDOM) at ./random.h:36
36?????????? ? if (len > 0)
38?????????? ????? return _gnutls_rnd_ops.rnd (gnutls_rnd_ctx, level, data, len);
?
wrap_nettle_rnd (_ctx=0x0, level=1,
data=0xbffff24c, datasize=128) at rnd.c:445
445???????? {
448???????? ? RND_LOCK;
?
gnutls_system_mutex_lock (priv=0x8173080) at
system.c:230
230??????? {
231??????? ? if (pthread_mutex_lock ((pthread_mutex_t *) *
priv))
?
Program received signal SIGSEGV,
Segmentation fault.
0xb7f2dcb7 in pthread_mutex_lock ()
from /lib/i386-linux-gnu/libpthread.so.0
Single stepping until exit from
function pthread_mutex_lock, which has no line number information.
Program terminated with signal
SIGSEGV, Segmentation fault.



Thank you in advance for your answer
Regards,
Daniel Slobozian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121004/8bc36425/attachment.htm>

From nmav at gnutls.org  Thu Oct  4 19:22:42 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 04 Oct 2012 19:22:42 +0200
Subject: gnutls_3.1.1issues
In-Reply-To: <1349343979.81220.YahooMailNeo@web29503.mail.ird.yahoo.com>
References: <1349343979.81220.YahooMailNeo@web29503.mail.ird.yahoo.com>
Message-ID: <506DC5E2.4040304@gnutls.org>

On 10/04/2012 11:46 AM, slobozian daniel wrote:

> Hello,
> 
> I encountered some issues while using gnutls 3.1.1 API on Ubuntu 12.04 with VirtualBox. 
> Software
> The first issue  appeared while using the functiongnutls_x509_crt_init.  Here is what I did:


You need to use gnutls_global_init(). Check the example programs in the
manual.

regards,
Nikos



From ali.khalfan at gmail.com  Thu Oct  4 23:22:07 2012
From: ali.khalfan at gmail.com (Ali Khalfan)
Date: Fri, 05 Oct 2012 00:22:07 +0300
Subject: insufficient credentials for that request
In-Reply-To: <5064314F.6080007@gmail.com>
References: <5064314F.6080007@gmail.com>
Message-ID: <506DFDFF.5080708@gmail.com>

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

I fixed this by installing the latest release (3.1.2),  maybe openvas5
has an issue with gnutls-2.8



- -------- Original Message --------
Subject: insufficient credentials for that request
From: Ali Khalfan <ali.khalfan at gmail.com>
To: GnuTLS mailing list <help-gnutls at gnu.org>
Date: Thu Sep 27 2012 13:58:23 GMT+0300 (AST)

> I have got gnutls-serv running as such :
> 
> sudo gnutls-serv -d 15 --x509keyfile serverkey.pem --x509certfile 
> servercert.pem --x509cafile cacert.pem -p 9393
> 
> 
> 
> I am trying to run another program that connects to port 9393  and
> I get an insufficient credentials error  as shown in the debug
> message below
> 
> Can anyone shed some light on this ?
> 
> 
> 
> * Accepted connection from IPv4 127.0.0.1 port 50607 on Thu Sep 27 
> 13:49:49 2012 |<2>| ASSERT: gnutls_constate.c:695 |<4>|
> REC[0x9be18a0]: Allocating epoch #1 |<7>| READ: Got 5 bytes from
> 0x5 |<7>| READ: read 5 bytes from 0x5 |<7>| RB: Have 0 bytes into
> buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>|
> REC[0x9be18a0]: Expected Packet[0] Handshake(22) with length: 1 
> |<4>| REC[0x9be18a0]: Received Packet[0] Handshake(22) with length:
> 108 |<7>| READ: Got 108 bytes from 0x5 |<7>| READ: read 108 bytes
> from 0x5 |<7>| RB: Have 5 bytes into buffer. Adding 108 bytes. 
> |<7>| RB: Requested 113 bytes |<4>| REC[0x9be18a0]: Decrypted
> Packet[0] Handshake(22) with length: 108 |<6>| BUF[HSK]: Inserted
> 108 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) 
> |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x9be18a0]:
> CLIENT HELLO was received [108 bytes] |<6>| BUF[REC][HD]: Read 104
> bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>|
> BUF[HSK]: Inserted 104 bytes of Data |<3>| HSK[0x9be18a0]: Client's
> version: 3.3 |<2>| ASSERT: gnutls_db.c:326 |<2>| ASSERT:
> gnutls_db.c:246 |<2>| EXT[0x9be18a0]: Parsing extension 'SAFE
> RENEGOTIATION/65281' (1 bytes) |<2>| EXT[0x9be18a0]: Parsing
> extension 'SIGNATURE ALGORITHMS/13' (16 bytes) |<2>| EXT[SIGA]:
> rcvd signature algo (4.1) RSA-SHA256 |<2>| EXT[SIGA]: rcvd
> signature algo (4.2) DSA-SHA256 |<2>| EXT[SIGA]: rcvd signature
> algo (4.3) GOST R 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo
> (5.1) RSA-SHA384 |<2>| EXT[SIGA]: rcvd signature algo (5.3) GOST R
> 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo (6.1) RSA-SHA512 
> |<2>| EXT[SIGA]: rcvd signature algo (6.3) GOST R 34.10-94 |<2>|
> ASSERT: gnutls_handshake.c:3348 |<1>| Could not find an appropriate
> certificate: Insufficient credentials for that request.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQbf3/AAoJEF9xp9NDNF0kJqoP/3N6lRb1Gml0mTRFdW2yVjSS
535eEt1jBAEB8sglOFJCBg90WpblMq8r7eK0qMA+/gClwB6BER510FSUpbxU0RoK
As1a2HOdxOuMvj3bkYh80b4KNXy6QoB+OsWPZ0vEECdVvtqoSofP2pA8hDVfALmE
vWd4NRu9Q9/xx7f54mIOIy6QOsuTVnZgJuMpW/KoE9emrltBAKDGQoR/DGjCVqLQ
qnGGqAOc6Qiijiqg4iI+lDQHl63SOfRo7vfKvaMgW91uG/XGs0MQaG3UHxxXvG6j
3NTbyMBFWuACrMFMHhkvhaNeVDftU4uustGS9Uv4HD03tYq+lhctpB7OWmjJjmyS
59gXqFAW8heW0hG90jxlTzB+N3hptXU4jFjwiL5zchHdJTY93uVqPUoW4HsQhlnE
Xa3GkeHNYaDEzAn5uNBZCWHazr3CmTX2xfVnknU866ZQmONdDdEtmKIMHl1V8PBP
K617CAZEAWLeYU5tFYnIMKjPLNEkXOpVY2vZMFsW6ZMU0SYGM4t2FKdRPKueTV29
a9oLPWlV07ndR8Lo7RZ6iuRaIIMisofH6qDf0Z+U+8Pnum5/iRpU2aWwE2wDqrwH
fJVVPXsMCrEDvMmPCsUJuHbVufN4esNzMdZIUC+rgQ/IKdWyZhy/aH+SDl2d3gfX
9e8tLjpHxKUL6DGZDXkz
=iKJO
-----END PGP SIGNATURE-----



From danut_12 at yahoo.com  Mon Oct  8 15:57:47 2012
From: danut_12 at yahoo.com (slobozian daniel)
Date: Mon, 8 Oct 2012 14:57:47 +0100 (BST)
Subject: gnutls_3.1.1issues
In-Reply-To: <506DC5E2.4040304@gnutls.org>
References: <1349343979.81220.YahooMailNeo@web29503.mail.ird.yahoo.com>
	<506DC5E2.4040304@gnutls.org>
Message-ID: <1349704667.41837.YahooMailNeo@web29502.mail.ird.yahoo.com>

Thanks for the info, it did the trick.

regards,
Daniel Slobozian



________________________________
 From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
To: slobozian daniel <danut_12 at yahoo.com> 
Cc: "help-gnutls at gnu.org" <help-gnutls at gnu.org> 
Sent: Thursday, October 4, 2012 7:22 PM
Subject: Re: gnutls_3.1.1issues
 
On 10/04/2012 11:46 AM, slobozian daniel wrote:

> Hello,
> 
> I encountered some issues while using gnutls 3.1.1 API on Ubuntu 12.04 with VirtualBox. 
> Software
> The first issue? appeared while using the functiongnutls_x509_crt_init.? Here is what I did:


You need to use gnutls_global_init(). Check the example programs in the
manual.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121008/219ab50d/attachment.htm>

From mk at cognitivedissonance.ca  Tue Oct  9 23:18:09 2012
From: mk at cognitivedissonance.ca (MK)
Date: Tue, 9 Oct 2012 17:18:09 -0400
Subject: gnutls_x509_privkey_import_openssl
Message-ID: <20121009171809.119877e06c8798a8e6ebe510@cognitivedissonance.ca>

Hi gang!

I just started using gnuTLS, and one of the first things I needed to do
was incorporate a certificate with encrypted key generated by openSSL.
This seemed like a very simple task, here's a minimal reproduction of
the technique I used to decrypt the original key:

void usage (const char *name) {
	fprintf(stderr, 
		"Usage: %s [password] < keyfile.in > keyfile.out\n",
		name
	);
	exit(0);
}

int main (int argc, const char *argv[]) {
	if (argc != 2) usage(argv[0]);

	unsigned char buffer[4096] = { 0 };
	int i = 0,
		c = fgetc(stdin);

	while (c != EOF) {
		buffer[i++] = c;
		c = fgetc(stdin);
	}

	const gnutls_datum_t raw = {
		.data = buffer,
		.size = i
	};

	gnutls_x509_privkey_t decrypted;
	int check = gnutls_x509_privkey_import_openssl(decrypted, &raw,
		argv[1]);
	if (check) fatal("Import error", check);     

Feeding in the key file resulted in GNUTLS_E_DECRYPTION_FAILED.  Since
the key can be decrypted other ways (eg, via "openssl -rsa") and used
successfully, I realized perhaps I should just use the encrypted data
in the file sans header*, but this led to GNUTLS_E_PARSING_ERROR.
Glancing at the gnutls source, that bail appears to happen before
DECRYPTION_FAILED, so I presume I am correct to feed in the entire file.

So I'm at a loss -- what am I doing wrong?  I'm using 3.1.2 built from
source.

* the header being:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC

Thanks -- Mark

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From joke at seiken.de  Wed Oct 10 19:18:03 2012
From: joke at seiken.de (Joke de Buhr)
Date: Wed, 10 Oct 2012 19:18:03 +0200
Subject: Get OpenPGP subkeyid used for authentication
Message-ID: <1620282.6FLb0la66N@oberon>

Hi,

is there a way to query the OpenPGP subkey used for authentication?

The Certificate used for authentication can be retrieved on the remote side via 
gnutls_certificate_get_peers() but the preferred subkey information isn't set 
on the remote side. I can't find any function to query subkey information.

Since is it possible to specify different subkeys used for authentication the 
remote side should be able to retrieve information about the subkey being used 
to check if this specific subkey hasn't been revoked.


regards
Joke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 729 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20121010/b6cb367e/attachment.pgp>

From nmav at gnutls.org  Wed Oct 10 20:16:34 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 10 Oct 2012 20:16:34 +0200
Subject: gnutls_x509_privkey_import_openssl
In-Reply-To: <20121009171809.119877e06c8798a8e6ebe510@cognitivedissonance.ca>
References: <20121009171809.119877e06c8798a8e6ebe510@cognitivedissonance.ca>
Message-ID: <5075BB82.5090505@gnutls.org>

On 10/09/2012 11:18 PM, MK wrote:

> Hi gang!
> 
> I just started using gnuTLS, and one of the first things I needed to do
> was incorporate a certificate with encrypted key generated by openSSL.
> This seemed like a very simple task, here's a minimal reproduction of
> the technique I used to decrypt the original key:


Ouch. It seems there was a bug in the openssl key import. I've committed
a fix and added a test case:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=f16ef39ef0303b02d7fa590a37820440c466ce8d

Could you try whether this solves the issue you see?

In general try to avoid the custom openssl format. The PKCS #8 format is
standardized and can be handled by more tools.

regards,
Nikos



From nmav at gnutls.org  Thu Oct 11 20:15:57 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 11 Oct 2012 20:15:57 +0200
Subject: Get OpenPGP subkeyid used for authentication
In-Reply-To: <1620282.6FLb0la66N@oberon>
References: <1620282.6FLb0la66N@oberon>
Message-ID: <50770CDD.1000809@gnutls.org>

On 10/10/2012 07:18 PM, Joke de Buhr wrote:

> Hi,
> 
> is there a way to query the OpenPGP subkey used for authentication?
> The Certificate used for authentication can be retrieved on the remote side via 
> gnutls_certificate_get_peers() but the preferred subkey information isn't set 
> on the remote side. I can't find any function to query subkey information.


You're right. There isn't such a function. The information is stored but
there is no function to export it. I'll add one in the upcoming release.

regards,
Nikos



From mk at cognitivedissonance.ca  Fri Oct 12 13:38:41 2012
From: mk at cognitivedissonance.ca (MK)
Date: Fri, 12 Oct 2012 07:38:41 -0400
Subject: Error in documentation
Message-ID: <20121012073841.13bbde4307405f34e02a4c01@cognitivedissonance.ca>

In the description of gnutls_global_set_audit_log_func, it says:

gnutls_audit_log_func is of the form, void (*gnutls_audit_log_func)
( gnutls_session_t, int level, const char*); 

This isn't true and leads to a compiler warning (good thing you defined
a type for the pointer!) and of course confusing behaviour.

gnutls_audit_log_func is actually defined in gnutls.h as:

void (*gnutls_audit_log_func) (gnutls_session_t, const char *)

Thanks -- MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From mk at cognitivedissonance.ca  Fri Oct 12 13:47:08 2012
From: mk at cognitivedissonance.ca (MK)
Date: Fri, 12 Oct 2012 07:47:08 -0400
Subject: gnutls_x509_privkey_import_openssl
In-Reply-To: <5075BB82.5090505@gnutls.org>
References: <20121009171809.119877e06c8798a8e6ebe510@cognitivedissonance.ca>
	<5075BB82.5090505@gnutls.org>
Message-ID: <20121012074708.e89856db4a0f08da32bf4086@cognitivedissonance.ca>

On Wed, 10 Oct 2012 20:16:34 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 10/09/2012 11:18 PM, MK wrote:

> > I just started using gnuTLS, and one of the first things I needed
> > to do was incorporate a certificate with encrypted key generated by
> > openSSL. This seemed like a very simple task, here's a minimal
> > reproduction of the technique I used to decrypt the original key:
> 
> Ouch. It seems there was a bug in the openssl key import. I've
> committed a fix and added a test case:
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=f16ef39ef0303b02d7fa590a37820440c466ce8d
> 
> Could you try whether this solves the issue you see?

I did, but no such luck.   Since this certificate isn't used online
now, I can give you the offending key:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,796F30DEA7F15E31

hBun6pD+9XVA4XoHZ58k339vRvJpT/7nCx0/TInkbxSLyGY/WPAeyRdiF/UGQOl9
04RDRrvilarqVk/DaLCzyrUv2bGtTPcvD3SK5lfoqqz+1ASBFyfNn9pQ0LNIfF7S
l55bZgTAYGxgQgCTJeAF9rfVu2kCMLVJbyvOfDf3a+h+PeDTyQheszOams5EWlv9
nXJbzGwYmok4ifGP3iIDvIxDbPCbbrbaK7fUY2NdXQeXm1A6098hHnifTjAzI3kQ
4k8+fuAuyLdwobom6fdHxGwQyUvKoxfjReOf1qE7O8bvVJ6fSolP2sxyLRlmt9K5
cOtEh1yS8FMSK8Rt3URv8Bc+swfemMGObh7MgICCas+0NYdejFNA9ODBxrIqxMs7
H5iMJBHQZ9hV34C0qmpyb+BbkRf9xurrfg9ORZjPZ6YuEKsew+oOvlnzi/Q/nB0g
lPwAZLjfoS2Osn9dtKFy3JC/i2IfnyKsoUP+zgJG+rOVUllpeL0w1O6wZ9CTudAB
P9jWTuIhyWi9RhBTKnqN+aI1/Tn1V7GSnD9G6mQR4uQ3JXSFBnfn7Mr9c+p9Vcnb
2zJ3f4+szAu63Iklnq1tK4LFbhFmxuohe6jdEQiAlnp//aelok/m4bYXhMIuuVK1
cOWxCUV3z+5+s4txGohM/88Z1VGF2E0Twrignthov1epFQoZY9bAW9Px+6RwaFhd
EMVayEPz+nwO8WepBArOVUpRzmH6pyo23NxZBQHVVW3ovyo48PTRKPNlN/aBtdC4
4l3xaS0zYVmW7j0txz+hkQSgkUsI6M0tuFKOkn4ue6g=
-----END RSA PRIVATE KEY-----

This was generated by openssl.

Here's an interesting thing; there was a tiny discrepancy in the patch
which made it fail on tests/Makefile.am:

-	 mini-dtls-heartbeat mini-x509-callbacks
+	 mini-dtls-heartbeat mini-x509-callbacks key-openssl

In my 3.1.2 tarball, that line is just "mini-dtls-heartbeat", so I
added the "mini-x509-callbacks".  However, make check then failed with:

make[3]: *** No rule to make target `mini-x509-callbacks.c', needed by
`mini-x509-callbacks.o'.  Stop.

I don't have much experience with autotools, so I tried a couple other
guesses but could not get it to apply.  Sorry.

> In general try to avoid the custom openssl format. The PKCS #8 format
> is standardized and can be handled by more tools.

Absolutely.  It's actually not necessary for me to incorporate the
openssl import, so no problem (for me, at least...).

MK

> 
> regards,
> Nikos
> 


-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From nmav at gnutls.org  Fri Oct 12 19:08:15 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 12 Oct 2012 19:08:15 +0200
Subject: gnutls 3.0.25
Message-ID: <50784E7F.6060206@gnutls.org>

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

* Version 3.0.25 (released 2012-10-12)

** libgnutls: Fixed the receipt of session tickets during session
resumption. Reported by danblack at http://savannah.gnu.org/support/?108146

** libgnutls: Added gnutls_ocsp_resp_check_crt() to check whether the
OCSP response corresponds to the given certificate.

** libgnutls: Several updates in the OpenPGP code. The generating code
is fully RFC6091 compliant and RFC5081 support is only supported in
client mode.

** API and ABI modifications:
gnutls_ocsp_resp_check_crt: Added



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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.25.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  Fri Oct 12 19:20:38 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 12 Oct 2012 19:20:38 +0200
Subject: gnutls 3.1.3
Message-ID: <50785166.2050200@gnutls.org>

Hello,
 I've just released gnutls 3.1.3. This release includes initial support
for the DANE protocol and the OCSP status request TLS extension. The
DANE protocol is an IETF protocol to verify certificates using DNSSEC.

* Version 3.1.3 (released 2012-10-12)

** libgnutls: Added support for the OCSP Certificate Status
extension.

** libgnutls: gnutls_certificate_verify_peers2() will use the OCSP
certificate status extension in verification.

** libgnutls: Bug fixes in gnutls_x509_privkey_import_openssl().

** libgnutls: Increased maximum password length in the PKCS #12
functions.

** libgnutls: Fixed the receipt of session tickets during session
resumption. Reported by danblack at http://savannah.gnu.org/support/?108146

** libgnutls: Added functions to export structures in an allocated buffer.

** libgnutls: Added gnutls_ocsp_resp_check_crt() to check whether the
OCSP response corresponds to the given certificate.

** libgnutls: In client side gnutls_init() enables the session ticket
and OCSP certificate status request extensions by default. The flag
GNUTLS_NO_EXTENSIONS can be used to prevent that.

** libgnutls: Several updates in the OpenPGP code. The generating code
is fully RFC6091 compliant and RFC5081 support is only supported in
client mode.

** libgnutls-dane: Added. It is a library to provide DANE with DNSSEC
certificate verification.

** gnutls-cli: Added --dane option to enable DANE certificate verification.

** danetool: Added tool to generate DANE TLSA Resource Records (RR).

** API and ABI modifications:
gnutls_certificate_get_peers_subkey_id: Added
gnutls_certificate_set_ocsp_status_request_function: Added
gnutls_certificate_set_ocsp_status_request_file: Added
gnutls_ocsp_status_request_enable_client: Added
gnutls_ocsp_status_request_get: Added
gnutls_ocsp_resp_check_crt: Added
gnutls_dh_params_export2_pkcs3: Added
gnutls_pubkey_export2: Added
gnutls_x509_crt_export2: Added
gnutls_x509_dn_export2: Added
gnutls_x509_crl_export2: Added
gnutls_pkcs7_export2: Added
gnutls_x509_privkey_export2: Added
gnutls_x509_privkey_export2_pkcs8: Added
gnutls_x509_crq_export2: Added
gnutls_openpgp_crt_export2: Added
gnutls_openpgp_privkey_export2: Added
gnutls_pkcs11_obj_export2: Added
gnutls_pkcs12_export2: Added
gnutls_pubkey_import_openpgp_raw: Added
gnutls_pubkey_import_x509_raw: Added
dane_state_init: Added
dane_state_deinit: Added
dane_query_tlsa: Added
dane_query_status: Added
dane_query_entries: Added
dane_query_data: Added
dane_query_deinit: Added
dane_verify_session_crt: Added
dane_verify_crt: Added
dane_strerror: Added


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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.3.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 mk at cognitivedissonance.ca  Sat Oct 13 00:30:17 2012
From: mk at cognitivedissonance.ca (MK)
Date: Fri, 12 Oct 2012 18:30:17 -0400
Subject: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
Message-ID: <20121012183017.f61bb6af0daafea7a1ab6ee0@cognitivedissonance.ca>

I'm trying to use tls in an existing http server.  Unfortunately, the
inital handshake always craps out with GNUTLS_E_GOT_APPLICATION_DATA.

The server is a non-blocking async/single-thread model written in a
combination of perl and (Inline::)C.   The secure socket module is kind
of tightly coupled in the sense that it is an alternative at the bottom
of a socket class hierarchy, fulfilling read and write methods left
abstract higher up, so I have not included any code here.  However, I
follow the same sequence of calls as used in the "x509 echo server"
example from the gnutls docs (which does not reproduce the problem).

The only even remotely related thing I've found online is from the
devel list archive:

http://lists.gnu.org/archive/html/gnutls-devel/2009-07/msg00014.html

Which gave me various flail-my-arms-while-drowning ideas such as trying
to purge the connection with gnutls_record_recv, but before I
run-around-like-a-headless-chicken I thought I'd ask here for more
educated guesses.

Note that the server has been in use online for a while and extensively
tested sans tls. 

Sincerely, Mark E.

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From nmav at gnutls.org  Sat Oct 13 12:51:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Oct 2012 12:51:22 +0200
Subject: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
In-Reply-To: <20121012183017.f61bb6af0daafea7a1ab6ee0@cognitivedissonance.ca>
References: <20121012183017.f61bb6af0daafea7a1ab6ee0@cognitivedissonance.ca>
Message-ID: <507947AA.10604@gnutls.org>

On 10/13/2012 12:30 AM, MK wrote:

> I'm trying to use tls in an existing http server.  Unfortunately, the
> inital handshake always craps out with GNUTLS_E_GOT_APPLICATION_DATA.


Cannot really tell. Check what is occurring with wireshark. It seems the
client starts sending application data without starting a handshake.

If this is not the case then either you call gnutls_handshake() even the
handshake has terminated, or the handshake receives packets out-of-order.

regards,
Nikos



From cloos at jhcloos.com  Sat Oct 13 22:10:10 2012
From: cloos at jhcloos.com (James Cloos)
Date: Sat, 13 Oct 2012 16:10:10 -0400
Subject: dametool cert file format
Message-ID: <m37gqu2kw4.fsf@carbon.jhcloos.org>

Using base64 encoded cert and key files I get ASN1 parser: Error in TAG
errors when I try to use danetool to generate TLSA RRs.

I've tried a number of invocations (host names changed):

:; danetool --tlsa-rr --host foo.example.net --load-certificate=foo_example_net_cert.pem 
danetool: crt_import: ASN1 parser: Error in TAG.

:; danetool --tlsa-rr --host foo.example.net --load-pubkey=foo_example_net_key.pem 
danetool: importing --load-pubkey: foo_example_net_key.pem: ASN1 parser: Error in TAG.

What kind of file does danetool expect?  I have RSA PRIVATE KEY,
CERTIFICATE REQUEST and CERTIFICATE files in pem format.

Also, the arg syntax-error report says:

  danetool [options] [url]
  danetool --help for usage instructions.

but --help suggests that there are no non-option args.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6



From nmav at gnutls.org  Sat Oct 13 22:33:07 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 13 Oct 2012 22:33:07 +0200
Subject: dametool cert file format
In-Reply-To: <m37gqu2kw4.fsf@carbon.jhcloos.org>
References: <m37gqu2kw4.fsf@carbon.jhcloos.org>
Message-ID: <5079D003.1090107@gnutls.org>

On 10/13/2012 10:10 PM, James Cloos wrote:

> Using base64 encoded cert and key files I get ASN1 parser: Error in TAG
> errors when I try to use danetool to generate TLSA RRs.
> 
> I've tried a number of invocations (host names changed):
> 
> :; danetool --tlsa-rr --host foo.example.net --load-certificate=foo_example_net_cert.pem 
> danetool: crt_import: ASN1 parser: Error in TAG.
> 
> :; danetool --tlsa-rr --host foo.example.net --load-pubkey=foo_example_net_key.pem 
> danetool: importing --load-pubkey: foo_example_net_key.pem: ASN1 parser: Error in TAG.
> 
> What kind of file does danetool expect?  I have RSA PRIVATE KEY,
> CERTIFICATE REQUEST and CERTIFICATE files in pem format.


Hello,
 Thanks for the report. It seems that I introduced a last minute bug and
the accepted format is DER only. You may use the tool with DER encoded
certificates (convert yours using certtool -i --infile xxx.pem --outder
--outfile xxx.der) or apply the following patch.

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

regards,
Nikos



From cloos at jhcloos.com  Sun Oct 14 00:19:32 2012
From: cloos at jhcloos.com (James Cloos)
Date: Sat, 13 Oct 2012 18:19:32 -0400
Subject: dametool cert file format
In-Reply-To: <5079D003.1090107@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 13 Oct 2012 22:33:07 +0200")
References: <m37gqu2kw4.fsf@carbon.jhcloos.org> <5079D003.1090107@gnutls.org>
Message-ID: <m37gqu10c2.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

NM> Thanks for the report. It seems that I introduced a last minute bug
NM> and the accepted format is DER only. You may use the tool with DER
NM> encoded certificates (convert yours using certtool -i --infile
NM> xxx.pem --outder --outfile xxx.der) or apply the following patch.

Ah.  I should've tested also with a der format file.

As it was, even after reading through the danetool src (I had read
through the libdane commits as they came in, after seeing your post on
the dane list) and running it in gdb it still looked to me like it were
"un-peming" the file before calling the der code.... :(

And thanks for the local-dns option to cli.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6



From mk at cognitivedissonance.ca  Sun Oct 14 17:57:12 2012
From: mk at cognitivedissonance.ca (MK)
Date: Sun, 14 Oct 2012 11:57:12 -0400
Subject: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
In-Reply-To: <507947AA.10604@gnutls.org>
References: <20121012183017.f61bb6af0daafea7a1ab6ee0@cognitivedissonance.ca>
	<507947AA.10604@gnutls.org>
Message-ID: <20121014115712.e0b39de4f64d7bf56e9ed682@cognitivedissonance.ca>

On Sat, 13 Oct 2012 12:51:22 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 10/13/2012 12:30 AM, MK wrote:
> 
> > I'm trying to use tls in an existing http server.  Unfortunately,
> > the inital handshake always craps out with
> > GNUTLS_E_GOT_APPLICATION_DATA.
> 
> 
> Cannot really tell. Check what is occurring with wireshark. It seems
> the client starts sending application data without starting a
> handshake.
> 
> If this is not the case then either you call gnutls_handshake() even
> the handshake has terminated, 

Thanks for confirming this was not just an undocumented gnutls oddity.
I wanted to get that possibility out of the way -- debugging stuff with
the C <-> perl layer is very primitive and tedious.

Your last guess was pretty close.   I know nothing about the TLS
protocol, but while I was looking at the packets in wireshark, I
realized I had misread something in the doc for gnutls_session_get_id:

"Session id is some data set by the server, that identify the current
session. In TLS 1.0 and SSL 3.0 session id is always less than 32
***bytes***."

Could have been bits, right?

I had a fetchId function and was using this as a return value if the
handshake wrapper succeeded, but that was returning 0 because the
get_id wrapper was returning 0 because the id didn't fit in an int64_t,
lol.  Since the sockets are non block, I was using 0 as the return
value from the handshake wrapper if it failed on EAGAIN, to
indicate we should retry after the next epoll cycle.  So I wasn't
asking for a handshake after a fail, I was asking for a second one
after success.

If you're still reading, I have an out-of-curiousity question about the
handshake. According to:

http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail

the handshake is:

ClientHello
ServerHello
ServerCertificate
ServerHelloDone
ClientKeyExchange
ClientChangeCipherSpec
ServerChangeCipherSpec
...begin content type 23...

However, in the handshakes I observed (in wireshark, using firefox 16
and lynx), there was no ServerChangeCipherSpec -- after the
ClientChangeCipherSpec, the client just sent application data and
everything was hunky-dory.  What's up?

Thanks again -- MK.

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From mk at cognitivedissonance.ca  Sun Oct 14 18:15:28 2012
From: mk at cognitivedissonance.ca (MK)
Date: Sun, 14 Oct 2012 12:15:28 -0400
Subject: get fd?
Message-ID: <20121014121528.951021ce88665c0a04946985@cognitivedissonance.ca>

Is there a simple way to get the file descriptor set via
transport_set_ptr again later from a session_t?

MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)




From hramrach at gmail.com  Fri Oct 26 15:15:08 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Fri, 26 Oct 2012 15:15:08 +0200
Subject: cert considered invalid when intermediate is expired
Message-ID: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>

Hello,

gnutls does not verify a certificate when the intermediate CA
certificate is expired.

situation:

server cert (valid)

signed by

intermediate cert (expired, valid at the time of signature)

signet by

root ca cert (valid)

Both GNUtls and OpenSSL refuse to verify the connection.

I am not sure if the certificate is technically valid in this case or not.

Any insight?

Thanks

Michal



From rich at kde.org  Fri Oct 26 18:02:25 2012
From: rich at kde.org (Richard Moore)
Date: Fri, 26 Oct 2012 17:02:25 +0100
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
Message-ID: <CAMp7mVvadnxVOprpKtCy10oRP09=9E_mGL-5521nTWNTpiQNXA@mail.gmail.com>

On 26 October 2012 14:15, Michal Suchanek <hramrach at gmail.com> wrote:
> Both GNUtls and OpenSSL refuse to verify the connection.
>
> I am not sure if the certificate is technically valid in this case or not.
>
> Any insight?

It is invalid, however browsers that cache intermediate certificates
(which most do) are sometimes able to still find a trust path  from
the leaf to one of the trust anchors (root CAs) by using a more recent
replacement for the intermediate certificate if they have encountered
it on another site. The replacement intermediate certificates often
reuse the same private key which is what makes this work.

Regards

Rich.



From nmav at gnutls.org  Sun Oct 28 02:28:50 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 28 Oct 2012 02:28:50 +0100
Subject: inital handshake always fails with GNUTLS_E_GOT_APPLICATION_DATA
In-Reply-To: <20121014115712.e0b39de4f64d7bf56e9ed682@cognitivedissonance.ca>
References: <20121012183017.f61bb6af0daafea7a1ab6ee0@cognitivedissonance.ca>
	<507947AA.10604@gnutls.org>
	<20121014115712.e0b39de4f64d7bf56e9ed682@cognitivedissonance.ca>
Message-ID: <508C8A52.4050703@gnutls.org>

On 10/14/2012 05:57 PM, MK wrote:


> Thanks for confirming this was not just an undocumented gnutls oddity.
> I wanted to get that possibility out of the way -- debugging stuff with
> the C <-> perl layer is very primitive and tedious.
> Your last guess was pretty close.   I know nothing about the TLS
> protocol, but while I was looking at the packets in wireshark, I
> realized I had misread something in the doc for gnutls_session_get_id:
> 
> "Session id is some data set by the server, that identify the current
> session. In TLS 1.0 and SSL 3.0 session id is always less than 32
> ***bytes***."
> Could have been bits, right?


No it is bytes. You can check the returned size in "session_id_size" to
see its actual size. Note that initially it should contain the size of
your buffer.

> If you're still reading, I have an out-of-curiousity question about the
> handshake. According to:
> http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail
> the handshake is:
> ClientHello
> ServerHello
> ServerCertificate
> ServerHelloDone
> ClientKeyExchange
> ClientChangeCipherSpec
> ServerChangeCipherSpec
> ...begin content type 23...
> However, in the handshakes I observed (in wireshark, using firefox 16
> and lynx), there was no ServerChangeCipherSpec -- after the
> ClientChangeCipherSpec, the client just sent application data and
> everything was hunky-dory.  What's up?


Was it a resumed session? In resumed sessions the handshake is brief and
client sends the final changecipherspec.

regards,
Nikos



From nmav at gnutls.org  Sun Oct 28 02:29:15 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 28 Oct 2012 02:29:15 +0100
Subject: get fd?
In-Reply-To: <20121014121528.951021ce88665c0a04946985@cognitivedissonance.ca>
References: <20121014121528.951021ce88665c0a04946985@cognitivedissonance.ca>
Message-ID: <508C8A6B.4030102@gnutls.org>

On 10/14/2012 06:15 PM, MK wrote:

> Is there a simple way to get the file descriptor set via
> transport_set_ptr again later from a session_t?


You can use the transport_get_ptr().

regards,
Nikos




From nmav at gnutls.org  Sun Oct 28 02:31:33 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 28 Oct 2012 02:31:33 +0100
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
Message-ID: <508C8AF5.2000105@gnutls.org>

On 10/26/2012 03:15 PM, Michal Suchanek wrote:

> Hello,
> 
> gnutls does not verify a certificate when the intermediate CA
> certificate is expired.


If the intermediate certificate is expired why would you consider it
valid? You may ignore expiration failures if your application doesn't
care, but gnutls cannot ignore them.

regards,
Nikos





From hramrach at gmail.com  Sun Oct 28 12:16:15 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Sun, 28 Oct 2012 12:16:15 +0100
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <508C8AF5.2000105@gnutls.org>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
	<508C8AF5.2000105@gnutls.org>
Message-ID: <CAOMqctSvXVycEaGqAV9mxK8Rhze77P_BVTxvZOoMMB72kg-xLA@mail.gmail.com>

On 28 October 2012 02:31, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 10/26/2012 03:15 PM, Michal Suchanek wrote:
>
>> Hello,
>>
>> gnutls does not verify a certificate when the intermediate CA
>> certificate is expired.
>
>
> If the intermediate certificate is expired why would you consider it
> valid? You may ignore expiration failures if your application doesn't
> care, but gnutls cannot ignore them.
>

Does that imply that a CA that signs a cert that is supposed to be
valid for 2yrs using an intermediate cert that is valid for 20 months
essentially makes a cert for 20 months only because for the remaining
4 months the cert will be invalid?

The application will, of course, use whatever gnutls supplies for cert
validation so when the cert does not validate in gnutls it will not
validate in any app using the library unless the authors went out of
their way to examine the certificate chain manually.

Thanks

Michal



From alfredo.pironti at inria.fr  Sun Oct 28 12:55:35 2012
From: alfredo.pironti at inria.fr (Alfredo Pironti)
Date: Sun, 28 Oct 2012 12:55:35 +0100
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <CAOMqctSvXVycEaGqAV9mxK8Rhze77P_BVTxvZOoMMB72kg-xLA@mail.gmail.com>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
	<508C8AF5.2000105@gnutls.org>
	<CAOMqctSvXVycEaGqAV9mxK8Rhze77P_BVTxvZOoMMB72kg-xLA@mail.gmail.com>
Message-ID: <CALR0uiLjiGYuYavCWRUyU9AvtmJfzphx2Z_3gTTb55Xi2EX=jA@mail.gmail.com>

>
> Does that imply that a CA that signs a cert that is supposed to be
> valid for 2yrs using an intermediate cert that is valid for 20 months
> essentially makes a cert for 20 months only because for the remaining
> 4 months the cert will be invalid?

I'd say yes, as much as a revoked trusted certificate makes all issued
certificates instantly invalid. Your case looks sort of corner, but I
believe the same verification rule should apply. A wise CA would
refresh their certificate before such a race condition occurs.

Alfredo



From cloos at jhcloos.com  Sun Oct 28 13:57:07 2012
From: cloos at jhcloos.com (James Cloos)
Date: Sun, 28 Oct 2012 08:57:07 -0400
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <508C8AF5.2000105@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 28 Oct 2012 02:31:33 +0100")
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
	<508C8AF5.2000105@gnutls.org>
Message-ID: <m3hape4uv7.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

NM> If the intermediate certificate is expired why would you consider it
NM> valid? You may ignore expiration failures if your application doesn't
NM> care, but gnutls cannot ignore them.

The presumption people normally make is that the validity period of a
cert specifies when it can sign, not when it can verify.

If the cert was valid when the signature was made, validation is expected
to continue to work for the lifetime of the signed cert.

As an example, one might want to issue signing certs to one's employees
which are valid for one shift but used to sign documents which are valid
for several years.  This ensures that were a signing cert compromised,
there would be a very small window of opportunity and a small number of
DoSed victims (ie, who have to come back for a fresh sig because the
compromised signing cert was revoked).

Obviously the ability to overtly revoke certs helps the above use case

The thought process is that only the ee cert is being *used*; the rest
of the chain were used when they made thier sigs and are now just verifying.

The specs very well may say otherwise, that the validity period specifies
when verification is permitted.  But that is not the typical expectation.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6



From nmav at gnutls.org  Sun Oct 28 15:23:03 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 28 Oct 2012 15:23:03 +0100
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <m3hape4uv7.fsf@carbon.jhcloos.org>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
	<508C8AF5.2000105@gnutls.org> <m3hape4uv7.fsf@carbon.jhcloos.org>
Message-ID: <508D3FC7.1020901@gnutls.org>

On 10/28/2012 01:57 PM, James Cloos wrote:

>>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> NM> If the intermediate certificate is expired why would you consider it
> NM> valid? You may ignore expiration failures if your application doesn't
> NM> care, but gnutls cannot ignore them.
> 
> The presumption people normally make is that the validity period of a
> cert specifies when it can sign, not when it can verify.
> 
> If the cert was valid when the signature was made, validation is expected
> to continue to work for the lifetime of the signed cert.
> 
> As an example, one might want to issue signing certs to one's employees
> which are valid for one shift but used to sign documents which are valid
> for several years.  This ensures that were a signing cert compromised,
> there would be a very small window of opportunity and a small number of
> DoSed victims (ie, who have to come back for a fresh sig because the
> compromised signing cert was revoked).


This is a totally different use case than a TLS certificate chain
verification. You can do that by considering the expired certificates as
trusted while you verify the documents. That verification is application
specific.

In the TLS chain verification chain however, there is no way to know
whether the intermediate certificate is expected to be expired or
somebody managed to obtain the private key of an old expired CA
certificate and signed new certificates.

regards,
Nikos



From dkg at fifthhorseman.net  Sun Oct 28 23:45:33 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 28 Oct 2012 18:45:33 -0400
Subject: cert considered invalid when intermediate is expired
In-Reply-To: <508D3FC7.1020901@gnutls.org>
References: <CAOMqctTQyZ9=Cun3Gx5GGWyMa3+Mjk9WrsY6ArKBwGCf39iREA@mail.gmail.com>
	<508C8AF5.2000105@gnutls.org> <m3hape4uv7.fsf@carbon.jhcloos.org>
	<508D3FC7.1020901@gnutls.org>
Message-ID: <508DB58D.7040802@fifthhorseman.net>

On 10/28/2012 10:23 AM, Nikos Mavrogiannopoulos wrote:
> On 10/28/2012 01:57 PM, James Cloos wrote:
> 
>>>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>>
>> NM> If the intermediate certificate is expired why would you consider it
>> NM> valid? You may ignore expiration failures if your application doesn't
>> NM> care, but gnutls cannot ignore them.
>>
>> The presumption people normally make is that the validity period of a
>> cert specifies when it can sign, not when it can verify.
>>
>> If the cert was valid when the signature was made, validation is expected
>> to continue to work for the lifetime of the signed cert.
>
> This is a totally different use case than a TLS certificate chain
> verification. You can do that by considering the expired certificates as
> trusted while you verify the documents. That verification is application
> specific.

Just to clarify, there is a specific attack that web browsers (and other
TLS-using X.509 relying parties) cannot properly defend against:

the holder of the secret key belonging to an expired certificate can
make arbitrary certificates with arbitrary start times (since they
control the clock on the signing system).  So, if your certificate
expired in December 2010, you can still use the secret key today to make
a cert that was "created" in November 2010, which happens to be good for
3 years.

If the relying parties were willing to accept an expired intermediate
(or root) cert that appears to be "valid at time of issuance", then
there is nothing to stop a malicious intermediate (or root!) CA from
continuing to sign any certificate they'd like at any time.

It's tempting to let this particular validation error slide for the
reason James Cloos describes; but it would be a bad idea to do so.

GnuTLS is doing the right thing.

	--dkg

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

From hramrach at gmail.com  Tue Oct 30 10:04:27 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Tue, 30 Oct 2012 10:04:27 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
Message-ID: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>

Hello,

when this flag is set some certificates cannot be verified.


hermes.jabber.org sends a certificate chain laid out like

S R I  where S is the server certificate, R is root certificate, and I
is intermediate certificate which signs S and is signed by R. R is
known CA.

gnutls-cli version 2.8.6, 3.0.20 and 3.0.22 cannot verify the
certificate. gnutls-cli version 3.1.3 can.

Upgrading gnutls to 3.1 does not enable an application to verify
certificate unless the code setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is disabled in the application.

I am not sure what this flag is supposed to do but *disabling* the
ability to verify certificates is hopefully not the intention.

As Debian is shipping gnutls 3.0 this is somewhat troublesome if such
certificate chain is supposed to be valid.

Any idea what the problem is here?

Thanks

Michal



From nmav at gnutls.org  Tue Oct 30 14:17:49 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 30 Oct 2012 14:17:49 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
Message-ID: <CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>

On Tue, Oct 30, 2012 at 10:04 AM, Michal Suchanek <hramrach at gmail.com> wrote:
> Hello,
> when this flag is set some certificates cannot be verified.
> hermes.jabber.org sends a certificate chain laid out like
> S R I  where S is the server certificate, R is root certificate, and I
> is intermediate certificate which signs S and is signed by R. R is
> known CA.
> gnutls-cli version 2.8.6, 3.0.20 and 3.0.22 cannot verify the
> certificate. gnutls-cli version 3.1.3 can.
> Upgrading gnutls to 3.1 does not enable an application to verify
> certificate unless the code setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
> is disabled in the application.

The GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a dangerous flag and you
shouldn't use it unless you really know the consequences. In short it
means that an end-user certificate may pretend to be a CA.

Now for the issue you see. It is because you do not set the flag
GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
chains will be sorted prior to verification. The reason you see this
failure is because this flag is enabled by default on a credentials
structure, unless it is overridden by other flags as you do.

regards,
Nikos



From nmav at gnutls.org  Tue Oct 30 14:22:02 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 30 Oct 2012 14:22:02 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
Message-ID: <CAJU7zaJX0hAMnQJBVapHUBo254MYh-rpHO48noA8gTNdDbJ6Sg@mail.gmail.com>

On Tue, Oct 30, 2012 at 2:17 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:

> The GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a dangerous flag and you
> shouldn't use it unless you really know the consequences. In short it
> means that an end-user certificate may pretend to be a CA.

Sorry, my comments were for the GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT
flag which you don't use. The flag GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is enabled by default so you don't have to set it.

regards,
Nikos



From hramrach at gmail.com  Tue Oct 30 14:22:02 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Tue, 30 Oct 2012 14:22:02 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
Message-ID: <CAOMqctTEc1B8_Wf0Hha5pg3+xnLeLN2=kt9G6PH608QWfMp_4g@mail.gmail.com>

On 30 October 2012 14:17, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, Oct 30, 2012 at 10:04 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>> Hello,
>> when this flag is set some certificates cannot be verified.
>> hermes.jabber.org sends a certificate chain laid out like
>> S R I  where S is the server certificate, R is root certificate, and I
>> is intermediate certificate which signs S and is signed by R. R is
>> known CA.
>> gnutls-cli version 2.8.6, 3.0.20 and 3.0.22 cannot verify the
>> certificate. gnutls-cli version 3.1.3 can.
>> Upgrading gnutls to 3.1 does not enable an application to verify
>> certificate unless the code setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>> is disabled in the application.
>
> The GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a dangerous flag and you
> shouldn't use it unless you really know the consequences. In short it
> means that an end-user certificate may pretend to be a CA.
>
> Now for the issue you see. It is because you do not set the flag
> GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
> chains will be sorted prior to verification. The reason you see this
> failure is because this flag is enabled by default on a credentials
> structure, unless it is overridden by other flags as you do.

The verification does not work on gnutls before 3.1 regardless of setting flags.

Has that default changed in 3.1?

Thanks

Michal



From hramrach at gmail.com  Tue Oct 30 14:28:46 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Tue, 30 Oct 2012 14:28:46 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
Message-ID: <CAOMqctS03kugs5CkVKvVcRdJL+CNiygrcmkUw6j1MVYqfcZ9Cg@mail.gmail.com>

On 30 October 2012 14:17, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, Oct 30, 2012 at 10:04 AM, Michal Suchanek <hramrach at gmail.com> wrote:
>> Hello,
>> when this flag is set some certificates cannot be verified.
>> hermes.jabber.org sends a certificate chain laid out like
>> S R I  where S is the server certificate, R is root certificate, and I
>> is intermediate certificate which signs S and is signed by R. R is
>> known CA.
>> gnutls-cli version 2.8.6, 3.0.20 and 3.0.22 cannot verify the
>> certificate. gnutls-cli version 3.1.3 can.
>> Upgrading gnutls to 3.1 does not enable an application to verify
>> certificate unless the code setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>> is disabled in the application.

> Now for the issue you see. It is because you do not set the flag
> GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
> chains will be sorted prior to verification. The reason you see this
> failure is because this flag is enabled by default on a credentials
> structure, unless it is overridden by other flags as you do.

So all the examples using gnutls_certificate_set_verify_flags are
bogus because they replace the defualt flags and break the
verification.

Also there is no get_verify_flags afaict so you can't update the flags
in any sane way.

Thanks

Michal



From nmav at gnutls.org  Tue Oct 30 15:15:08 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 30 Oct 2012 15:15:08 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAOMqctTEc1B8_Wf0Hha5pg3+xnLeLN2=kt9G6PH608QWfMp_4g@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
	<CAOMqctTEc1B8_Wf0Hha5pg3+xnLeLN2=kt9G6PH608QWfMp_4g@mail.gmail.com>
Message-ID: <CAJU7zaJToxQXLO1+cCPKLS3uE3sTEGfDeC806XC8KGKRz5FEsA@mail.gmail.com>

On Tue, Oct 30, 2012 at 2:22 PM, Michal Suchanek <hramrach at gmail.com> wrote:

>> Now for the issue you see. It is because you do not set the flag
>> GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
>> chains will be sorted prior to verification. The reason you see this
>> failure is because this flag is enabled by default on a credentials
>> structure, unless it is overridden by other flags as you do.
> The verification does not work on gnutls before 3.1 regardless of setting flags.
> Has that default changed in 3.1?

The GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN was introduced in 3.1 if this
is what you mean.

regards,
Nikos



From nmav at gnutls.org  Tue Oct 30 15:17:43 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 30 Oct 2012 15:17:43 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAOMqctS03kugs5CkVKvVcRdJL+CNiygrcmkUw6j1MVYqfcZ9Cg@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
	<CAOMqctS03kugs5CkVKvVcRdJL+CNiygrcmkUw6j1MVYqfcZ9Cg@mail.gmail.com>
Message-ID: <CAJU7zaLtUXnzAKD-nfaQb_8ALJfQiCX3bwOHfcK-QadHC35tyQ@mail.gmail.com>

On Tue, Oct 30, 2012 at 2:28 PM, Michal Suchanek <hramrach at gmail.com> wrote:

>> Now for the issue you see. It is because you do not set the flag
>> GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
>> chains will be sorted prior to verification. The reason you see this
>> failure is because this flag is enabled by default on a credentials
>> structure, unless it is overridden by other flags as you do.
> So all the examples using gnutls_certificate_set_verify_flags are
> bogus because they replace the defualt flags and break the
> verification.

Which examples do you refer to? However, an update_flags may be
helpful indeed. I'll check it.

regards,
Nikos



From hramrach at gmail.com  Tue Oct 30 15:41:38 2012
From: hramrach at gmail.com (Michal Suchanek)
Date: Tue, 30 Oct 2012 15:41:38 +0100
Subject: GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT breaks certificate verification
In-Reply-To: <CAJU7zaLtUXnzAKD-nfaQb_8ALJfQiCX3bwOHfcK-QadHC35tyQ@mail.gmail.com>
References: <CAOMqctQdKftHwte3PQ82874WRNFh2KWQPFSXunuy6gv5x3w4UQ@mail.gmail.com>
	<CAJU7zaLKA=ZTm3LkqBZ8+7rS+L_TsehrTS+Y0BnZhVTZjnifaQ@mail.gmail.com>
	<CAOMqctS03kugs5CkVKvVcRdJL+CNiygrcmkUw6j1MVYqfcZ9Cg@mail.gmail.com>
	<CAJU7zaLtUXnzAKD-nfaQb_8ALJfQiCX3bwOHfcK-QadHC35tyQ@mail.gmail.com>
Message-ID: <CAOMqctTmDXuV0jLERnYsq352R+_uKHEr1we_aBuok6LviW03BA@mail.gmail.com>

On 30 October 2012 15:17, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Tue, Oct 30, 2012 at 2:28 PM, Michal Suchanek <hramrach at gmail.com> wrote:
>
>>> Now for the issue you see. It is because you do not set the flag
>>> GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. If you set this flag then unsorted
>>> chains will be sorted prior to verification. The reason you see this
>>> failure is because this flag is enabled by default on a credentials
>>> structure, unless it is overridden by other flags as you do.
>> So all the examples using gnutls_certificate_set_verify_flags are
>> bogus because they replace the defualt flags and break the
>> verification.
>
> Which examples do you refer to? However, an update_flags may be
> helpful indeed. I'll check it.

Don't know where the software author copied that line but eg. here

http://www.gnu.org/software/gnutls/manual/html_node/Digital-signatures.html

the manual advises to use set_verify_flags.

Thanks

Michal



From dkg at fifthhorseman.net  Wed Oct 31 09:22:38 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 31 Oct 2012 04:22:38 -0400
Subject: Fwd: [oss-security] please verify unusual x.509 constraints are
	handled
In-Reply-To: <20120627131318.GA30758@cmpxchg8b.com>
References: <20120627131318.GA30758@cmpxchg8b.com>
Message-ID: <5090DFCE.3050608@fifthhorseman.net>

The attached message was sent earlier this year to oss-security,
implying that gnutls does not properly honor pathLenConstraint:

  http://openwall.com/lists/oss-security/2012/06/27/5

I'm unable to replicate the reported results with GnuTLS 2.8.6 (debian
squeeze), 3.0.22 (debian sid) or 3.1 (debian experimental).

What i see is (sid and experimental):

0 dkg at pip:/tmp/certtest$ cat local-cert.pem Mengsk.pem
sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e
Loaded 5 certificates, 1 CAs and 0 CRLs

	Subject: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001
	Issuer: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA
	Output: Not verified.

Chain verification output: Not verified.

1 dkg at pip:/tmp/certtest$


or (squeeze):

0 dkg at stable:~/certtest$ cat local-cert.pem Mengsk.pem
sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e
Certificate[0]: C=KR,O=Tanaris,CN=localhost
	Issued by: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk
Certificate Authority
	Verifying against certificate[1].
	Verification output: Verified.

Certificate[1]: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk
Certificate Authority
	Issued by: C=KR,O=Government of Korea,OU=Group of Server,OU=?????
??,CN=sms.hallym.ac.kr
	Verifying against certificate[2].
	Verification output: Verified.

Certificate[2]: C=KR,O=Government of Korea,OU=Group of Server,OU=???
????,CN=sms.hallym.ac.kr
	Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001
	Verifying against certificate[3].
	Verification output: Verified.

Certificate[3]: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001
	Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA
	Verifying against certificate[4].
	Verification output: Not verified.

Certificate[4]: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA
	Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA
	Verification output: Verified.

Chain verification output: Not verified.
0 dkg at stable:~/certtest$

I'm happy to follow up to the original reporter, but i want to be sure
that i understand what's going on.

any pointers or suggestions?

	--dkg
-------------- next part --------------
An embedded message was scrubbed...
From: Tavis Ormandy <taviso at cmpxchg8b.com>
Subject: [oss-security] please verify unusual x.509 constraints are handled
Date: Wed, 27 Jun 2012 15:13:18 +0200
Size: 27423
URL: </pipermail/attachments/20121031/8e020d78/attachment.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20121031/8e020d78/attachment.pgp>

From nmav at gnutls.org  Wed Oct 31 11:04:21 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 31 Oct 2012 11:04:21 +0100
Subject: [oss-security] please verify unusual x.509 constraints are handled
In-Reply-To: <5090DFCE.3050608@fifthhorseman.net>
References: <20120627131318.GA30758@cmpxchg8b.com>
	<5090DFCE.3050608@fifthhorseman.net>
Message-ID: <CAJU7za+zptdfruZjMQj2Qtuy-TaSyJm2e7Wf_4XbrDUu41kDUQ@mail.gmail.com>

On Wed, Oct 31, 2012 at 9:22 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> The attached message was sent earlier this year to oss-security,
> implying that gnutls does not properly honor pathLenConstraint:
>   http://openwall.com/lists/oss-security/2012/06/27/5
> I'm unable to replicate the reported results with GnuTLS 2.8.6 (debian
> squeeze), 3.0.22 (debian sid) or 3.1 (debian experimental).
> What i see is (sid and experimental):
> 0 dkg at pip:/tmp/certtest$ cat local-cert.pem Mengsk.pem
> sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e
> Loaded 5 certificates, 1 CAs and 0 CRLs
>         Subject: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001
>         Issuer: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA
>         Output: Not verified.

I haven't checked why the verification fails, but he is right that we
don't honor the pathLenConstrains and the CertSign and CRLsign
keyUsage bits for CAs. The issue with being strict on X.509
verification is that if other implementations aren't people think it
is a bug. We had that when we enforced the keyUsage bits for digital
signature and encryption. It would be good to enforce those
restrictions though.

regards,
Nikos