From fw at deneb.enyo.de Fri Jun 2 17:35:10 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 02 Jun 2006 17:35:10 +0200 Subject: [Help-gnutls] Perl binding Message-ID: <878xofd101.fsf@mid.deneb.enyo.de> Is there some kind of Perl binding for GNUTLS? And, while I'm at it, is it possible to use GNUTLS in a straightforward manner with self-signed X.509 certificates (or OpenPGP keys)? With "straightforward" I mean something like SSH: The client specifies the server key (preferably given as an in-memory blob), and the library will establish the connection only if the server key matches. The server accepts all clients, but will then verify the certifcate against a user-supllied database (e.g. the library returns some unqiue identifier, and a callback provides the corresponding key material, again in memory). From nmav at gnutls.org Sun Jun 4 23:05:20 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 4 Jun 2006 23:05:20 +0200 Subject: [Help-gnutls] Perl binding In-Reply-To: <878xofd101.fsf@mid.deneb.enyo.de> References: <878xofd101.fsf@mid.deneb.enyo.de> Message-ID: <200606042305.20684.nmav@gnutls.org> On Fri 02 Jun 2006 17:35, Florian Weimer wrote: Hello Florian, > Is there some kind of Perl binding for GNUTLS? None that I'm aware of. > And, while I'm at it, is it possible to use GNUTLS in a > straightforward manner with self-signed X.509 certificates (or > OpenPGP keys)? With "straightforward" I mean something like SSH: The > client specifies the server key (preferably given as an in-memory > blob), and the library will establish the connection only if the > server key matches. The server accepts all clients, but will then > verify the certifcate against a user-supllied database (e.g. the > library returns some unqiue identifier, and a callback provides the > corresponding key material, again in memory). Yes you could use gnutls that way. If you ask for a function to do exactly that it doesn't exist. You may want to check the certificate verification example to get an idea how you could do it. regards, Nikos From mogorman at digium.com Mon Jun 5 20:29:23 2006 From: mogorman at digium.com (mogorman) Date: Mon, 05 Jun 2006 13:29:23 -0500 Subject: [Help-gnutls] timeout? Message-ID: <44847803.1020901@digium.com> Hello Can someone provide or explain to me how to use gnutls_recv with a timeout, or someway to acheive the same function? Thanks Mog From oliverlupton at gmail.com Mon Jun 5 23:29:15 2006 From: oliverlupton at gmail.com (Oliver Lupton) Date: Mon, 05 Jun 2006 22:29:15 +0100 Subject: [Help-gnutls] timeout? In-Reply-To: <448497B3.8020600@digium.com> References: <44847803.1020901@digium.com> <448491DB.9040806@gmail.com> <448497B3.8020600@digium.com> Message-ID: <4484A22B.3020909@gmail.com> mogorman wrote: > Oliver Lupton wrote: > >> mogorman wrote: >> >>> Hello >>> Can someone provide or explain to me how to use gnutls_recv with a >>> timeout, or someway to acheive the same function? >>> >>> Thanks >>> Mog >>> >>> >>> _______________________________________________ >>> Help-gnutls mailing list >>> Help-gnutls at gnu.org >>> http://lists.gnu.org/mailman/listinfo/help-gnutls >>> >> >> I'm a little in a rush so sorry there's no examples. >> There may be a easier way of doing this that's "good enough", but you >> can set the socket descriptors non-blocking which will cause >> gnutls_record_recv to always return immediately. You can then either >> go all the way and make your whole program use async sockets (a pain, >> if you've already written a lot), or you can write a wrapper for >> gnutls_record_recv to select() for the socket being readable, select() >> can timeout :) >> I can do some examples soon if you need them, just ask :) >> >> Cheers, >> -ol > > yes I would greatly appreciate it if you dont mind, im actually using a > jabber library (iksemel) that uses gnutls and it is calling gnutls_recv > and never timing out so i am going to have to change it there, but > needless to say i have not used gnutls that much. > > Mog > Okay, firstly setting a socket nonblocking: int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); Once a socket is nonblocking, no calls to read(), write(), recv(), send() etc will ever block, they'll always return immediately. I'm assuming all the stuff giving gnutls the descriptor and so on is working already. Now, the second way with a wrapper would be something like: int my_read(gnutls_session_t session, char* buffer, int length, int timeout) { int fd; fd_set rfds; struct timeval tv; fd = (int)gnutls_transport_get_ptr(session); tv.tv_sec = length; tv.tv_usec = 0; FD_ZERO(&rfds); FD_SET(fd, &rfds); int sr = select(fd+1, &rfds, NULL, NULL, &tv); if(sr == -1) { /* Shouldn't happen, select() error */ return -1; } else if(sr) { int r = gnutls_record_recv(session, buffer, length); /* Handle this as you would normally, probably just return it and let the caller handle it. */ return r; } else { /* Timeout, however you want to indicate it */ } } Having said that this would be an easy way, I think it may have some issues with the handshaking, a possible solution might be to not set the socket nonblocking until after the handshake is complete. But maybe someone else would have a neater solution? As for the fully-async way, I don't think I can really show it in one example. If you have some understanding of how asynchronous socket apps work then it shouldn't be too hard :) Hope some of this helps Cheers, -ol From rks at mur.at Tue Jun 6 21:01:57 2006 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Tue, 06 Jun 2006 21:01:57 +0200 Subject: [Help-gnutls] timeout? Message-ID: <4485D125.9030104@mur.at> > Hello > Can someone provide or explain to me how to use gnutls_recv with a > timeout, or someway to acheive the same function? > > Thanks > Mog how about using the socket options SO_RCVTIMEO and SO_SNDTIMEO? Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria From jas at extundo.com Mon Jun 12 15:19:57 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon, 12 Jun 2006 15:19:57 +0200 Subject: [Help-gnutls] Development branch open, daily snapshots Message-ID: <87ver6tssi.fsf@latte.josefsson.org> We've branched off the stable 1.4.x branch from the CVS trunk, the branch tag is 'gnutls_1_4_x'. The CVS trunk is now the next development series, 1.5.x, that will lead to the next stable release, 1.6.0. We'll continue to make release on the 1.4.x branch, to fix any security problems or to improve the most recent additions (TLS/IA, TLS-PSK, etc). We'll hopefully be able to make releases on the 1.2.x branch to fix security problems. We don't have resources to maintain the 1.0.x branch. We're collecting things to do for 1.5, and they currently include: - C++ interface - Continue move to a crypto-library independent backend including crypto hardware support (currently stalled because we don't have the resources to work on it) - Perl bindings? - Datagram-TLS support? - Implement the draft-salowey-tls-ticket TLS extension? If you can think of something more, please mention it. If you'd like to work on, or sponsor something, we're interested. I've also improved the daily snapshot build script. You can now find daily snapshots for all currently supported branches, see: http://josefsson.org/daily/gnutls-1.2/ - Old stable 1.2.x branch http://josefsson.org/daily/gnutls-1.4/ - New stable 1.4.x branch http://josefsson.org/daily/gnutls/ - Current development branch (1.5.x) Please test the daily builds! If there's anything wrong with them, you'll have to tell us, so we can fix it before the next release. /Simon From prog1 at yobinario.com Mon Jun 12 21:12:11 2006 From: prog1 at yobinario.com (Fran) Date: Mon, 12 Jun 2006 21:12:11 +0200 Subject: [Help-gnutls] Development branch open, daily snapshots In-Reply-To: <87ver6tssi.fsf@latte.josefsson.org> References: <87ver6tssi.fsf@latte.josefsson.org> Message-ID: <1150139531.3096.5.camel@localhost.localdomain> El lun, 12-06-2006 a las 15:19 +0200, Simon Josefsson escribi?: > - Continue move to a crypto-library independent backend including > crypto hardware support (currently stalled because we don't have the > resources to work on it) Hello, Readers for new national electronic identification cards are included in crypto hardware? Regards. From fweimer at bfk.de Tue Jun 13 10:31:29 2006 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 13 Jun 2006 10:31:29 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA Message-ID: <20060613083128.GA7946@mx00.int.bfk.de> As far as I can tell, GNUTLS discards a peer certificate unless it is signed by a trusted CA. For SSH-style "leap of faith" authentication, this is counterproductive. I could add an outer protocol layer in which the client tells the server which certificate it is going to send (so that the server can look it up in a database and tell GNUTLS it is trusted). However, I'd like to avoid this. Here's how I set up the session on the server side: my $cred = new Crypt::GNUTLS::CertificateCredentials; $cred->set_x509_key_mem($server_cert, $server_key, GNUTLS_X509_FMT_PEM); my $session = new_server Crypt::GNUTLS::Session; $session->set_default_priority; $session->kx_set_priority(qw/RSA/); $session->certificate_server_set_request(GNUTLS_CERT_REQUEST); $cred->set($session); After that, the peer certificate list is empty, even though the client claims to have sent a certificate. If I mark the client certificate as trusted, using: $cred->set_x509_trust_mem($client_cert, GNUTLS_X509_FMT_PEM); the certificate is returned as desired. However, I can't really load all client certificates into the library because that wouldn't scale. Any suggestions? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From jas at extundo.com Tue Jun 13 11:13:18 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 13 Jun 2006 11:13:18 +0200 Subject: [Help-gnutls] Re: Development branch open, daily snapshots In-Reply-To: <1150139531.3096.5.camel@localhost.localdomain> (Fran's message of "Mon, 12 Jun 2006 21:12:11 +0200") References: <87ver6tssi.fsf@latte.josefsson.org> <1150139531.3096.5.camel@localhost.localdomain> Message-ID: <87u06ps9jl.fsf@latte.josefsson.org> Fran writes: > El lun, 12-06-2006 a las 15:19 +0200, Simon Josefsson escribi?: > >> - Continue move to a crypto-library independent backend including >> crypto hardware support (currently stalled because we don't have the >> resources to work on it) > > Hello, > > Readers for new national electronic identification cards are included in > crypto hardware? I was thinking more about encryption-accelerators (to reduce load on a busy server). Interfacing with smart card readers that perform crypto operations for authentication purposes is another idea, and closely related. If the crypto-backend is modularized, supporting smart cards will be much easier too. Thanks, I'll add it to the list of things to consider. It is probably more work than crypto accelerators, though. Still, we don't have any resources to work on these two right now. But we can dream a little. /Simon From fweimer at bfk.de Tue Jun 13 14:51:34 2006 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 13 Jun 2006 14:51:34 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: References: <20060613083128.GA7946@mx00.int.bfk.de> Message-ID: <20060613125134.GA2698@mx00.int.bfk.de> On Tue, Jun 13, 2006 at 12:10:32PM +0200, Nikos Mavrogiannopoulos wrote: > >the client tells the server which certificate it is going to send (so > >that the server can look it up in a database and tell GNUTLS it is > >trusted). However, I'd like to avoid this. > Why do that in an outer protocol? Because the server is pre-warned and can feed the expected certificate to GNUTLS. > From the server side you can access the actual certificate that the > client had sent, thus you can look it up in a database (say by using > the sha-1 of the certificate or even something simpler). Well, according to my experiments, this doesn't work. 8-( Good to know that it should, though. > >After that, the peer certificate list is empty, even though the client > > Probably it is empty because the client didn't send any certificate. Indeed, gnutls_certificate_client_get_request_status returns 0 on the client side. But if I comment out the set_x509_key_mem call (see below), the test case with set_x509_trust_mem on the server side begins to fail. Therefore, I assume that a client certificate is actually sent to the server. > How do you set up the client side? If you use the default functions > most probably the certificate will not be sent if the server doesn't send > in his certificate request message a list of acceptable CAs (at least > one CA must have signed that certificate). my $cred = new Crypt::GNUTLS::CertificateCredentials; $cred->set_x509_key_mem($client_cert, $client_key, GNUTLS_X509_FMT_PEM); $cred->set_x509_trust_mem($server_cert, GNUTLS_X509_FMT_PEM); my $session = new_client Crypt::GNUTLS::Session; $session->set_default_priority; $session->kx_set_priority(qw/RSA/); $cred->set($session); > In that case if you would like to send the client certificate anyway, > you should use the callback function (don't remember the name right > now). Will try and report. But it's rather strange that I see a certificate on the server side even if the client doesn't send one. 8-/ Smells like a bug. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Tue Jun 13 16:28:35 2006 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 13 Jun 2006 16:28:35 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <20060613125134.GA2698@mx00.int.bfk.de> References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> Message-ID: <20060613142835.GA26436@mx00.int.bfk.de> On Tue, Jun 13, 2006 at 02:51:34PM +0200, fweimer wrote: > > In that case if you would like to send the client certificate anyway, > > you should use the callback function (don't remember the name right > > now). > > Will try and report. gnutls_certificate_client_get_request_status still returns 0 on the client side, but it seems that this time, a certificate is actually transmitted in a way the server can handle it. May I assume that the first certificate returned by gnutls_certifcate_get_peers contains public key material which actually corresponds to the private key material which was used to establish the ssession? By the way, gnutls_certificate_client_set_retrieve_function is not a well-designed interface. The callback function lacks a closure parameter. Even worse, it is hard to fake it because gnutls_certificate_client_set_retrieve_function is called with a credentials structure, and the callback is called with a session structure. Extremely annoying. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From sig at netdot.net Mon Jun 19 16:14:21 2006 From: sig at netdot.net (Aaron VanDevender) Date: Mon, 19 Jun 2006 09:14:21 -0500 Subject: [Help-gnutls] Empty CRL Message-ID: <1150726461.324.4.camel@lazlo.netdot.net> Is there a way to use certtool to create an empty CRL? If I say: $ certtool --load-ca-certificate ca-cert.pem --load-ca-privkey \ ca-key.pem --generate-crl --outfile crl.pem I get: Generating a signed CRL... Loading CA's private key... Loading CA's certificate... Loading certificate list... You must specify a certificate. But if I say: $ certtool -l --infile crl.pem where crl.pem is an empty file, I get: Decoding error: Base64 decoding error. So how do I make something that is a valid CRL file, but just doesn't contain any records? -- sig at netdot.net Plead the First. From nmav at gnutls.org Mon Jun 19 19:17:04 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Jun 2006 19:17:04 +0200 Subject: [Help-gnutls] Empty CRL In-Reply-To: <1150726461.324.4.camel@lazlo.netdot.net> References: <1150726461.324.4.camel@lazlo.netdot.net> Message-ID: <200606191917.05120.nmav@gnutls.org> On Mon 19 Jun 2006 16:14, Aaron VanDevender wrote: > Is there a way to use certtool to create an empty CRL? If I say: > $ certtool --load-ca-certificate ca-cert.pem --load-ca-privkey \ > ca-key.pem --generate-crl --outfile crl.pem With the current certtool I don't think so. But why would you need an empty CRL list? regards, Nikos From sig at netdot.net Tue Jun 20 00:59:49 2006 From: sig at netdot.net (Aaron VanDevender) Date: Mon, 19 Jun 2006 17:59:49 -0500 Subject: [Help-gnutls] Empty CRL In-Reply-To: <200606191917.05120.nmav@gnutls.org> References: <1150726461.324.4.camel@lazlo.netdot.net> <200606191917.05120.nmav@gnutls.org> Message-ID: <1150757990.324.14.camel@lazlo.netdot.net> On Mon, 2006-06-19 at 19:17 +0200, Nikos Mavrogiannopoulos wrote: > On Mon 19 Jun 2006 16:14, Aaron VanDevender wrote: > > Is there a way to use certtool to create an empty CRL? If I say: > > $ certtool --load-ca-certificate ca-cert.pem --load-ca-privkey \ > > ca-key.pem --generate-crl --outfile crl.pem > > With the current certtool I don't think so. But why would you need an > empty CRL list? So that I can write a program that just says: gnutls_certificate_set_x509_crl_file (cert_cred, CRLFILE, GNUTLS_X509_FMT_PEM); Just like in Example Server 7.4.2 and not have to first check that CRLFILE is empty or not. Also, and more importantly, the CRL file has useful stuff in it in addition to revocation certificates, like a CRL expiration date, so that when I'm setting up a new CA, and there haven't been any revoked certs yet, clients can still download the CRL and learn that 1) nothing has been revoked yet, and 2) when they can expect a new CRL to be published that might contain a revoked certificate. Without that clients have no idea whether to check for the next CRL in ten minutes or in ten years. So they have to guess, and when I finally do issue a new CRL, I don't know how long it will take till all the clients have gotten the new one, and thus closed the abuse window on the old revoked certificate. In other words, we need to be able to create empty CRLs. It's as shame that it cannot be done with certtool. I'll use openssl for now: openssl ca -config ./openssl.cnf -gencrl -out crl.pem -keyfile ca-key.pem -cert ca-cert.pem But it would be nice if I could use GnuTLS as a complete PKI solution. -- sig at netdot.net Plead the First. From nmav at gnutls.org Thu Jun 22 01:11:29 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Jun 2006 01:11:29 +0200 Subject: [Help-gnutls] Empty CRL In-Reply-To: <1150757990.324.14.camel@lazlo.netdot.net> References: <1150726461.324.4.camel@lazlo.netdot.net> <200606191917.05120.nmav@gnutls.org> <1150757990.324.14.camel@lazlo.netdot.net> Message-ID: <200606220111.30169.nmav@gnutls.org> On Tue 20 Jun 2006 00:59, Aaron VanDevender wrote: > > With the current certtool I don't think so. But why would you need > > an empty CRL list? > So that I can write a program that just says: > gnutls_certificate_set_x509_crl_file (cert_cred, CRLFILE, > GNUTLS_X509_FMT_PEM); > Just like in Example Server 7.4.2 and not have to first check that > CRLFILE is empty or not. It looks interesting. I'll put it to my todo list, but with my current schedule I don't expect to work on it anytime soon. regards, Nikos From nmav at gnutls.org Thu Jun 22 01:30:53 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Jun 2006 01:30:53 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <20060613142835.GA26436@mx00.int.bfk.de> References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> Message-ID: <200606220130.53330.nmav@gnutls.org> On Tue 13 Jun 2006 16:28, Florian Weimer wrote: > On Tue, Jun 13, 2006 at 02:51:34PM +0200, fweimer wrote: > > > In that case if you would like to send the client certificate > > > anyway, you should use the callback function (don't remember the > > > name right now). > > > > Will try and report. > > gnutls_certificate_client_get_request_status still returns 0 on the > client side, but it seems that this time, a certificate is actually > transmitted in a way the server can handle it. This looks like a bug, but from a quick glimpse the code looks ok. I'll try to check it further once I have more time. > May I assume that the first certificate returned by > gnutls_certifcate_get_peers contains public key material which > actually corresponds to the private key material which was used to > establish the ssession? No. That would be the last certificate in the chain. > By the way, gnutls_certificate_client_set_retrieve_function is not a > well-designed interface. The callback function lacks a closure > parameter. What do you mean by closure parameter? > Even worse, it is hard to fake it because > gnutls_certificate_client_set_retrieve_function is called with a > credentials structure, and the callback is called with a session > structure. Extremely annoying. But you want to know the session in the callback (to obtain information about the current session). The session is the caller of the callback. regards, Nikos From jas at extundo.com Tue Jun 27 11:00:03 2006 From: jas at extundo.com (Simon Josefsson) Date: Tue, 27 Jun 2006 11:00:03 +0200 Subject: [Help-gnutls] Libtasn1 0.3.5 Message-ID: <87odwfvur0.fsf@latte.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by GNU Shishi to handle Kerberos V5 packets. Version 0.3.5 (2006-06-27) - Fix asn1_octet_der to handle writes of zero-length buffers, before it did not write the ASN.1 length for a zero-length buffer. This caused ASN.1 encodings to be incorrect on 64-bit platforms. - Add self test that attempt to trigger the above bug. - Fix test of -Wno-pointer-sign. - Improve cross-compilation to MinGW by using AC_LIBTOOL_WIN32_DLL. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Manual in many formats: http://josefsson.org/gnutls/manual/libtasn1/ Here are the compressed sources (1.2MB): http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.5.tar.gz Here are GPG detached signatures using key 0xB565716F: http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.5.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2006-08-14] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2006-08-14] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: b2e4bc705a971e2835e149bb6d456a1fddf50d7e libtasn1-0.3.5.tar.gz f84ce6b3bdaefc2b6e1c7bac33a1562c07881af2 libtasn1-0.3.5.tar.gz.sig bed2d3244e32c25b95b0dc25e5cdfebc7c25a5c92f907a6b49858c2e libtasn1-0.3.5.tar.gz efd6031fe7ec2a86af57130aaef4ef942f2fdd2d74f3b2ba5e669afd libtasn1-0.3.5.tar.gz.sig Enjoy, Fabio, Nikos and Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: