From nmav at gnutls.org Wed Jul 1 20:59:32 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 01 Jul 2009 21:59:32 +0300 Subject: Bug in gnutls breaking Pidgin Jabber support In-Reply-To: <4A4A898D.4000700@filezilla-project.org> References: <4A3FBDC1.8070102@darkrain42.org> <873a9qu9xp.fsf@mocca.josefsson.org> <4A486960.6010405@filezilla-project.org> <4A4874C3.4010709@filezilla-project.org> <4A4A5D0D.40701@gnutls.org> <4A4A66AF.6010002@filezilla-project.org> <4A4A7215.6010402@gnutls.org> <4A4A7693.9000806@filezilla-project.org> <4A4A898D.4000700@filezilla-project.org> Message-ID: <4A4BB214.9010308@gnutls.org> Tim Kosse wrote: > Hi, > > since my initial assumptions got invalidated, I no longer consider my > earlier patch as a merely an ugly workaround but instead as a viable > solution. I've attached an updated version of the patch. In addition to > _gnutls_io_write_buffered, _gnutls_handshake_io_send_int is fixed as well. > > Combined with the handshake patch I've previously mailed, I've been > unable to reproduce any problems with GnuTLS in FileZilla. I applied it, and added as well a test case for the EAGAIN case. That is mini-egain.c in tests/ directory. Probably it does not fully check all possibilities (i.e. sending less bytes), but still it is useful. regards, Nikos From nmav at gnutls.org Wed Jul 1 21:12:38 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 01 Jul 2009 22:12:38 +0300 Subject: Certificate Request State In-Reply-To: <20090630202448.19789.qmail@wiredyne.com> References: <20090630202448.19789.qmail@wiredyne.com> Message-ID: <4A4BB526.4040208@gnutls.org> Peter Hendrickson wrote: > Running GnuTLS 2.8.1 under Ubuntu 9.04, I find that > gnutls_certificate_client_get_request_status() falsely reports that no > client certificate was requested, even when there was a request. (The > server code is supposed to be asking for a certificate, it > successfully verifies the client certificate, and I can see the > certificate request packet to the client and the client sending its > certificate.) > > Watching in the debugger, it appears that when the "Certificate > Request" handshake packet arrives at the client from the server, the > client sets session->key->certificate_requested to 1 in > auth_cert.c:_gnutls_proc_cert_cert_req(). > > The problem seems to lie in gnutls_certificate_client_get_request_status() > itself. Corrected thanks. I also don't remember why this is like that. It must have been some incomplete attempt to move this variable from the key to auth_info structure. regards, Nikos From nmav at gnutls.org Wed Jul 1 21:25:33 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 01 Jul 2009 22:25:33 +0300 Subject: Patch for _gnutls_send_finished in gnutls_handshake.c In-Reply-To: <4A4A824B.1040905@filezilla-project.org> References: <4A4A824B.1040905@filezilla-project.org> Message-ID: <4A4BB82D.8000507@gnutls.org> Tim Kosse wrote: > This is the handshake issue I've mentioned earlier. This problem exists > in 2.6.4 as well as 2.8. > > If _gnutls_send_finished fails with GNUTLS_E_AGAIN or GNUTLS_E_AGAIN it > eventually gets called a second time. > > It however does not call _gnutls_send_handshake with a NULL pointer on > repeated calls, ultimately leading to an internal error in > _gnutls_handshake_io_send_int. > > The attached patch simply makes sure to also pass a NULL pointer to > _gnutls_send_handshake if data_size is 0. Applied. Thank you! From tim.kosse at filezilla-project.org Wed Jul 1 23:18:23 2009 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Wed, 01 Jul 2009 23:18:23 +0200 Subject: Patch for _gnutls_send_finished in gnutls_handshake.c In-Reply-To: <4A4BB82D.8000507@gnutls.org> References: <4A4A824B.1040905@filezilla-project.org> <4A4BB82D.8000507@gnutls.org> Message-ID: <4A4BD29F.2060307@filezilla-project.org> Nikos Mavrogiannopoulos wrote: > Applied. Thank you! Thanks for applying the patch(es). Are there any plans for a 2.8.2 release in the near future? Thanks, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sun Jul 5 23:10:51 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 06 Jul 2009 00:10:51 +0300 Subject: Patch for _gnutls_send_finished in gnutls_handshake.c In-Reply-To: <4A4BD29F.2060307@filezilla-project.org> References: <4A4A824B.1040905@filezilla-project.org> <4A4BB82D.8000507@gnutls.org> <4A4BD29F.2060307@filezilla-project.org> Message-ID: <4A5116DB.1010408@gnutls.org> Tim Kosse wrote: > Thanks for applying the patch(es). Are there any plans for a 2.8.2 > release in the near future? It's up to Simon. regards, Nikos From tomas.kukosa at siemens-enterprise.com Wed Jul 8 13:27:16 2009 From: tomas.kukosa at siemens-enterprise.com (Kukosa, Tomas) Date: Wed, 8 Jul 2009 13:27:16 +0200 Subject: GnuTLS for Win64 Message-ID: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> Are there any plans in this respect? Best regards, Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From cr4yv3n at hotmail.com Fri Jul 10 03:53:46 2009 From: cr4yv3n at hotmail.com (Zak Hoskins) Date: Thu, 9 Jul 2009 18:53:46 -0700 Subject: /usr/lib/libgnutls.so.13 won't work Message-ID: I hate to just send complaints like this, but this software has completely crapped out my system. I can't get Amarok, SAMBA, cupsd, and alot of apps that worked before to work. I didn't mind at first because I don't really use these services right now. But when gammu didn't build because of problems with this, that was enough. I really need gammu to function because I'm using it at work. But when I try to build it with make I get the following errors: /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_dn_by_oid at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_get_peers at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_import at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_dn at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_cipher_get at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_check_hostname at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_activation_time at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_check_version at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_session_set_data at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_expiration_time at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_record_send at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_global_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_global_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_pk_algorithm_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_bye at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_verify_flags at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_record_recv at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_strerror at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_pk_algorithm at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_set_default_priority at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_cipher_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_verify_peers2 at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_issuer_dn at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_mac_get at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_allocate_credentials at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_session_get_data at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_credentials_set at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_compression_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_version at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_transport_set_ptr at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_handshake at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_x509_key_file at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_type_set_priority at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_mac_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_x509_trust_file at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_free_credentials at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_compression_get at GNUTLS_1_3' collect2: ld returned 1 exit status make[3]: *** [gammu/gammu] Error 1 make[3]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make[2]: *** [gammu/CMakeFiles/gammu.dir/all] Error 2 make[2]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make[1]: *** [all] Error 2 make[1]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make: *** [all] Error 2 I tried downloading and building the latest versions of both curl and gnuTLS. Both compiled and installed properly. Yet after I tried running ./configure and make on gammu, I get the same errors as above. I'm really at a loss as of what to do here. Do I need to re-link something manually. Please respond soon as I have completely exhausted ideas on fixing this issue and no longer have any desire to search on google for solutions that don't work. I hope one of you can help me, and I would be sincerely grateful if you could. _________________________________________________________________ Insert movie times and more without leaving Hotmail?. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at unixuser.org Tue Jul 14 22:11:45 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 15 Jul 2009 05:11:45 +0900 Subject: [PATCH] session ticket support Message-ID: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> Hi, The attached is an experimental patch which adds support for RFC5077 SessionTicket extension to GnuTLS. I would appreciate any comment. Some notes: - I added gnutls_ext_register2, since the send_params callback of gnutls_ext_register is not currently able to send empty extension data. - The interface is not flexible and there are many limitations; for example, there is no control whether to accept/reject tickets on reception. - For the example usage of the interface, please check tests/session_ticket.c. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-session-ticket.diff Type: text/x-diff Size: 47429 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From nmav at gnutls.org Tue Jul 14 23:19:44 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:19:44 +0300 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907142005.20551.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> <200907141946.11694.bradh@frogmouth.net> <200907142005.20551.bradh@frogmouth.net> Message-ID: <4A5CF670.6000806@gnutls.org> Brad Hards wrote: > On Tuesday 14 July 2009 19:46:10 Brad Hards wrote: >> On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: >>> Actually I think it might be much easier to do that inside gnutls by >>> extending get_subject_alt_name() to be able to accept the OID as >>> parameter to parse the 2.5.29.18 extension as well. Then would be easy >>> to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to >>> gnutls. >> I had a first cut at this. See attached patch. > [I realise this can't be applied yet - I'm just looking for feedback] > > Here is an example that I was sent a while ago, and what I see running it through > certtool. Do you think it is worth adding that as a unit test? Yes. From nmav at gnutls.org Tue Jul 14 23:29:16 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:29:16 +0300 Subject: [PATCH] session ticket support In-Reply-To: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> Message-ID: <4A5CF8AC.6010102@gnutls.org> Daiki Ueno wrote: > Hi, > > The attached is an experimental patch which adds support for RFC5077 > SessionTicket extension to GnuTLS. I would appreciate any comment. Hey, thank you. From a quick glimpse I like it. I'll check it better tomorrow. I'm wondering whether it would be easy to allow returning empty data from send_func, to avoid having a second function for sending data. Anyway I'll check it tomorrow. regards, Nikos From nmav at gnutls.org Thu Jul 16 22:56:10 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Jul 2009 23:56:10 +0300 Subject: [PATCH] session ticket support In-Reply-To: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> Message-ID: <4A5F93EA.9050100@gnutls.org> Daiki Ueno wrote: > Hi, > > The attached is an experimental patch which adds support for RFC5077 > SessionTicket extension to GnuTLS. I would appreciate any comment. > > Some notes: > > - I added gnutls_ext_register2, since the send_params callback of > gnutls_ext_register is not currently able to send empty extension > data. Hello, I have modified your patch and gnutls to avoid the need for send_func2. (new patch attached). Some questions I'd like to pose you are: - Would you be willing to transfer copyright to FSF for your code? - Have you checked this implementation against others? - It seems gnutls_session_ticket_enable_server() requires some random key to be available. Do you have thought a way for this key to be generated? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: session2.patch Type: text/x-patch Size: 33783 bytes Desc: not available URL: From ueno at unixuser.org Fri Jul 17 13:32:08 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 17 Jul 2009 20:32:08 +0900 Subject: [PATCH] session ticket support In-Reply-To: <4A5F93EA.9050100@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 16 Jul 2009 23:56:10 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> Message-ID: Hi Nikos, >>>>> In <4A5F93EA.9050100 at gnutls.org> >>>>> Nikos Mavrogiannopoulos wrote: > > The attached is an experimental patch which adds support for RFC5077 > > SessionTicket extension to GnuTLS. I would appreciate any comment. > > > > Some notes: > > > > - I added gnutls_ext_register2, since the send_params callback of > > gnutls_ext_register is not currently able to send empty extension > > data. > I have modified your patch and gnutls to avoid the need for send_func2. > (new patch attached). Thanks for reviewing. I agree with that having a second function just for sending empty data is too much. > Some questions I'd like to pose you are: > - Would you be willing to transfer copyright to FSF for your code? Sure. > - Have you checked this implementation against others? Not yet. I'll check it against OpenSSL this weekend. > - It seems gnutls_session_ticket_enable_server() requires some random > key to be available. Do you have thought a way for this key to be generated? Though I have no idea how to generate that key, how about an interface something like: gnutls_session_ticket_server_key_t key; gnutls_session_ticket_allocate_server_key (&key); /* NULL for generating a random key internally. */ gnutls_session_ticket_set_server_key (key, NULL, -1); for (;;) { sd = accept (listen_sd, ...); ... /* Generate only IV here. */ gnutls_session_ticket_enable_server (session, key); } Sorry if I'm missing the subject. Regards, -- Daiki Ueno From nmav at gnutls.org Fri Jul 17 21:01:04 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Jul 2009 22:01:04 +0300 Subject: [PATCH] session ticket support In-Reply-To: References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> Message-ID: <4A60CA70.9080607@gnutls.org> Daiki Ueno wrote: >> - Have you checked this implementation against others? > Not yet. I'll check it against OpenSSL this weekend. Please let me know of results. >> - It seems gnutls_session_ticket_enable_server() requires some random >> key to be available. Do you have thought a way for this key to be generated? > > Though I have no idea how to generate that key, how about an interface > something like: > > gnutls_session_ticket_server_key_t key; > > gnutls_session_ticket_allocate_server_key (&key); > /* NULL for generating a random key internally. */ > gnutls_session_ticket_set_server_key (key, NULL, -1); > > for (;;) > { > sd = accept (listen_sd, ...); > ... > /* Generate only IV here. */ > gnutls_session_ticket_enable_server (session, key); > } > > Sorry if I'm missing the subject. No you are correct. However I would go a step further and make the randomization it explicitly, in order to allow storing of those somewhere (for a web server to reuse). An API could be: int gnutls_session_ticket_allocate_server_key (&key); int gnutls_session_ticket_randomize (key); int gnutls_session_ticket_export (key, uint8_t* data, size_t* size); /* to save into a file */ int gnutls_session_ticket_import (key, const uint8_t* data, size_t size); /* to load from a file */ Would you be interested into implementing this as well? Alternatively I could work on it once all paper work is done. best regards, Nikos From cj at sveningsson.info Mon Jul 20 16:08:34 2009 From: cj at sveningsson.info (Carl-Johan Sveningsson) Date: Mon, 20 Jul 2009 14:08:34 +0000 (UTC) Subject: PKCS#11 support and proxy providers References: <1244614661.11069.6.camel@wallace.localnet> <87r5xr3wdn.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson josefsson.org> writes: > > Craig Ringer postnewspapers.com.au> writes: > > > Hi > > > > I've been doing some research into PKCS#11 support in GnuTLS and into > > PKCS#11 proxy providers. There was some discussion on both some time ago > > on the GnuTLS devel list, but I've been unable to find much more recent > > than 2007. Current GnuTLS sources do not appear to support loading and > > using a PKCS#11 provider module. > > > > Is there PKCS#11 support in GnuTLS that I'm missing? Or did the PKCS#11 > > work done in 2007 not come to anything? > > > > The reason I'm interested is that some apps I use, including Evolution > > Data Server's Camel mail client module, use GnuTLS for their crypto > > needs. This not only prevents them from talking to smart cards and other > > hardware keys, but it prevents them from using centralized PKCS#11-based > > certificate stores like the GNOME Keyring Daemon. Users must instead > > configure each GnuTLS-using app to load their certificate from a PKCS#12 > > file. > > > > I'm looking into ways to get a centralized key store, including PKCS#11 > > proxying for smart cards and the like, into wider use on Linux desktops. > > As part of that I'd be really interested in any progress on PKCS#11 > > support in GnuTLS. For my purposes I'd only need single-provider > > support, since GnuTLS would talk to the proxy provider over a UNIX > > socket and that'd manage the keystore as well as any smart cards and the > > like. > > > > I've been unable to find any suitable existing proxy provider > > implementations, so I was thinking of writing a thin PKCS#11 provider > > module and a daemon that uses libnss to handle the keystore, card > > proxying, and the like. Is anyone here aware of a suitable existing > > PKCS#11 proxy daemon and provider that might do the job? > > Hi. > > You should be able to implement what you need using the sign callback in > GnuTLS: > > http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#index-gnutls_005fsign_005fcallback_005fset-268 > > This lets you send back the sign request to where the private keys is, > which can include a PKCS#11 provider. > > However, I would agree with you that something more would be useful. > > We have been thinking about a 'gnutlsd' daemon that can sit in the > background and hold private keys, or tunnel them to PKCS#11 providers. > See some ideas on: > > http://redmine.josefsson.org/projects/gnutls/wiki/GnuTLSExternalValidation > > Seahorse could implement the same protocol, and would then be able to > hold private keys and serve GnuTLS clients. > > I think it makes more sense for these daemons to do the PKCS#11 > integration than including that code in the TLS client library. It > makes things simpler and easier to debug. > > I wish I had more time to work on this, it would be quite interesting. > If you want to help, now is a good time to do it, since we have just > opened the 2.9.x branch. > > /Simon > Hello everyone, please pardon me if I'm confused about what I want to achieve or how to do it (I have not been close to gnutls at all, only other peripherial stuff), but I have been missing some sort of PKCS#11 proxy for a long time. I can come up with a number of use-cases which I don't know how to solve today, like letting an application in a virtual machine or vnc interact with a physical local PKCS#11 device, decrypting data on-server in your webmail, accessing a PKCS#11 device plugged into a lighter system than the one running the application, like some thin client (on some level, probably all these situations are analogue). At which layer could such a proxy be placed, in order to enable flexibility but with minimal complexity installed on the device holding the PKCS#11 device? If someone could give me anything on this, even a pointer in the right direction, it would be much appreciated. Thanks, best regards Carl-Johan Sveningsson From pdh at wiredyne.com Fri Jul 24 20:51:16 2009 From: pdh at wiredyne.com (Peter Hendrickson) Date: 24 Jul 2009 18:51:16 -0000 Subject: Handshake Packet Dropped Message-ID: <20090724185116.25208.qmail@wiredyne.com> A server initiates a session renegotiation by calling gnutls_rehandshake(). If the connection is active, the client will send application data followed by a ClientHello. (The application data may well have been sent before the Client received the HelloRequest packet.) According to the gnutls_handshake() documentation: > If this function is called by a server after a rehandshake request > then `GNUTLS_E_GOT_APPLICATION_DATA' or > `GNUTLS_E_WARNING_ALERT_RECEIVED' may be returned. Note that these > are non fatal errors, only in the specific case of a rehandshake. > Their meaning is that the client rejected the rehandshake request. So, apparently the server needs to clear out any incoming application data before calling gnutls_handshake(). If it doesn't, gnutls_handshake() just returns GNUTLS_E_GOT_APPLICATION_DATA. And that is apparently indistinguishable from the client rejecting the renegotiation request. The server wants to read all of the application data out before the ClientHello packet appears. And this is where I believe I have found a bug. If the server calls gnutls_record_recv(), it needs to do so repeatedly until it runs out of application data. This means that when the ClientHello packet comes in, that it will need to be stored someplace so that gnutls_handshake() will be able to use it shortly thereafter. What actually happens is that gnutls_record_recv() calls _gnutls_recv_int() and tells it to expect application data. When the ClientHello comes in, it is decrypted and stored in a gnutls_datum_t called "tmp". The sequence number is incremented and then record_check_type() is called. This routine notices that the data received is a handshake and not application data and the result is that _gnutls_recv_int() returns GNUTLS_E_REHANDSHAKE. However, the ClientHello packet does not seem to get stored anywhere. When gnutls_handshake() is subsequently called it just waits and waits for a packet it will never see because the client already sent it -- it just got dropped on the floor. (The memory in _gnutls_recv_int():tmp does not seem to get freed in this case, so there may also be a little memory leak.) This is observed in GnuTLS 2.9.2. I doubt it matters, but I am using nonblocking sockets. Peter From nmav at gnutls.org Sat Jul 25 11:06:18 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 25 Jul 2009 12:06:18 +0300 Subject: [PATCH] session ticket support In-Reply-To: References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> Message-ID: <4A6ACB0A.4030801@gnutls.org> Daiki Ueno wrote: >> - Have you checked this implementation against others? > > Not yet. I'll check it against OpenSSL this weekend. Hello Daiki, Do you have any updates on that? regards, Nikos From ueno at unixuser.org Sat Jul 25 13:01:55 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Sat, 25 Jul 2009 20:01:55 +0900 Subject: [PATCH] session ticket support In-Reply-To: <4A6ACB0A.4030801@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 25 Jul 2009 12:06:18 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> Message-ID: >>>>> In <4A6ACB0A.4030801 at gnutls.org> >>>>> Nikos Mavrogiannopoulos wrote: > >> - Have you checked this implementation against others? > > > > Not yet. I'll check it against OpenSSL this weekend. > Do you have any updates on that? Yes - but there are some issues. I have tested with modified gnutls-cli/gnutl-serv capable of session ticket handling. The combination of OpenSSL s_client and gnutls-serv seems OK, but gnutls-cli and s_server cannot continue handshake. I'm now investigating what is going on. Anyway, I attach the log files of: $ openssl s_server -accept 10000 -CAfile x509-ca.pem \ -key x509-server-key.pem -cert x509-server.pem -msg >& s_server.log $ gnutls-cli --debug 10 -p 10000 --resume localhost >& gnutls-cli.log -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: s_server.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls-cli.log URL: -------------- next part -------------- Regards, -- Daiki Ueno From nmav at gnutls.org Sun Jul 26 15:00:53 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 26 Jul 2009 16:00:53 +0300 Subject: [PATCH] session ticket support In-Reply-To: References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> Message-ID: <4A6C5385.9010504@gnutls.org> Daiki Ueno wrote: >>>>>> In <4A6ACB0A.4030801 at gnutls.org> >>>>>> Nikos Mavrogiannopoulos wrote: >>>> - Have you checked this implementation against others? >>> Not yet. I'll check it against OpenSSL this weekend. > >> Do you have any updates on that? > > Yes - but there are some issues. I have tested with modified > gnutls-cli/gnutl-serv capable of session ticket handling. > > The combination of OpenSSL s_client and gnutls-serv seems OK, but > gnutls-cli and s_server cannot continue handshake. I'm now > investigating what is going on. Anyway, I attach the log files of: > > $ openssl s_server -accept 10000 -CAfile x509-ca.pem \ > -key x509-server-key.pem -cert x509-server.pem -msg >& s_server.log Probably you have tried already but I would suggest -tlsextdebug -state instead of -msg... The actual messages might be easier to see using wireshark. > $ gnutls-cli --debug 10 -p 10000 --resume localhost >& gnutls-cli.log If I am correctly checking the log, It seems from the capture that openssl doesn't send the NewSessionTicket on subsequent handshakes. Could it be this the reason that gnutls-cli fails? regards, Nikos From ueno at unixuser.org Tue Jul 28 03:27:39 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 28 Jul 2009 10:27:39 +0900 Subject: [PATCH] session ticket support In-Reply-To: <4A6C5385.9010504@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 26 Jul 2009 16:00:53 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> Message-ID: >>>>> In <4A6C5385.9010504 at gnutls.org> >>>>> Nikos Mavrogiannopoulos wrote: > > The combination of OpenSSL s_client and gnutls-serv seems OK, but > > gnutls-cli and s_server cannot continue handshake. I'm now > > investigating what is going on. Anyway, I attach the log files of: > Probably you have tried already but I would suggest -tlsextdebug -state > instead of -msg... The actual messages might be easier to see using > wireshark. Thanks, it really helped. It turned out that there was a bug in session ID handling of my previous patch. > If I am correctly checking the log, It seems from the capture that > openssl doesn't send the NewSessionTicket on subsequent handshakes. > Could it be this the reason that gnutls-cli fails? Yes, it was the immediate cause. If a client reuses previous session ID, s_server returns empty session ID and behaves as if it is resumed (this might be a bug of OpenSSL). When I changed _gnutls_recv_new_session_ticket to generate new session ID, it started to work. I attach the new patch, which includes: * Adaption for gnutls-cli/gnutls-serv. Session ticket support is enabled by default, while it can be disabled by --noticket option. You can test the interoperability with: $ gnutls-serv -p 10000 --nodb --x509cafile x509-ca.pem \ --x509keyfile x509-server-key.pem --x509certfile x509-server.pem $ openssl s_client -connect localhost:10000 -reconnect and $ openssl s_server -accept 10000 -CAfile x509-ca.pem \ -key x509-server-key.pem -cert x509-server.pem $ gnutls-cli -p 10000 --resume localhost * New interface functions as you suggested. int gnutls_session_ticket_allocate_key (gnutls_session_ticket_key_t *); int gnutls_session_ticket_randomize (gnutls_session_ticket_key_t); int gnutls_session_ticket_import (gnutls_session_t, void *, size_t); int gnutls_session_ticket_export (gnutls_session_t, void *, size_t *); -------------- next part -------------- A non-text attachment was scrubbed... Name: session3.diff.gz Type: application/octet-stream Size: 11838 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From joe at x2a.org Tue Jul 28 23:37:12 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Tue, 28 Jul 2009 17:37:12 -0400 Subject: [WIP] DTLS 1.0 preliminary patches Message-ID: <4A6F6F88.7000207@x2a.org> Hello, Being interested in DTLS and GnuTLS I have decided to try to implement DTLS in the GnuTLS library. I have managed to send a valid DTLS ClientHello using a modified GnuTLS in a relatively non-intrusive way (but which may break the ABI since it messes with existing enum values). The OpenSSL implementation responds to this ClientHello with a HelloVerifyMessage and Wireshark considers the packet valid DTLS. You may find my patches at this URL: http://x2a.org/pub/dtls/ Unfortunately the lower end of the record layer and buffer/transport layer seems rather messy to my untrained eye. I am having trouble imagining implementing UDP buffering easely. I would need to buffer the whole packet then iterate over the records contained within the packet. The main problem seems to be layering violations between the handshake, record and buffer layers. Would it be better if _gnutls_{recv,send}_int dealt with whole records (and possibly return prematurely if more data or buffer space is required) ? _gnutls_{recv,send}_int could also deal with the SSLv2.0 record encapsulation. The handhake layer would therefore deal with those two functions for sending/receiving from the lower layer. The handshake layer buffering would also be moved to gnutls_handshake.c. Am I making any sense ? http://lists.gnupg.org/pipermail/gnutls-dev/2005-May/000864.html documents the previous attempt. Comments and suggestions welcome... Cheers, Jonathan From joe at x2a.org Tue Jul 28 20:44:29 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Tue, 28 Jul 2009 14:44:29 -0400 Subject: [WIP] DTLS 1.0 preliminary patches Message-ID: <4A6F470D.1090606@x2a.org> Hello, Being interested in DTLS and GnuTLS I have decided to try to implement DTLS in the GnuTLS library. I have managed to send a valid DTLS ClientHello using a modified GnuTLS in a relatively non-intrusive way (but which may break the ABI since it messes with existing enum values). The OpenSSL implementation responds to this ClientHello with a HelloVerifyMessage and Wireshark considers the packet valid DTLS. You may find my patches at this URL: http://x2a.org/pub/dtls/ Unfortunately the lower end of the record layer and buffer/transport layer seems rather messy to my untrained eye. I am having trouble imagining implementing UDP buffering easely. I would need to buffer the whole packet then iterate over the records contained within the packet. The main problem seems to be layering violations between the handshake, record and buffer layers. Would it be better if _gnutls_{recv,send}_int dealt with whole records (and possibly return prematurely if more data or buffer space is required) ? _gnutls_{recv,send}_int could also deal with the SSLv2.0 record encapsulation. The handhake layer would therefore deal with those two functions for sending/receiving from the lower layer. The handshake layer buffering would also be moved to gnutls_handshake.c. Am I making any sense ? http://lists.gnupg.org/pipermail/gnutls-dev/2005-May/000864.html documents the previous attempt. Comments, suggestions and insults welcome... Cheers, Jonathan From simon at josefsson.org Wed Jul 29 11:59:43 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 11:59:43 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A6F6F88.7000207@x2a.org> (Jonathan Bastien-Filiatrault's message of "Tue, 28 Jul 2009 17:37:12 -0400") References: <4A6F6F88.7000207@x2a.org> Message-ID: <87ocr3izcg.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Hello, > > Being interested in DTLS and GnuTLS I have decided to try to implement > DTLS in the GnuTLS library. Great! > I have managed to send a valid DTLS ClientHello using a modified GnuTLS > in a relatively non-intrusive way (but which may break the ABI since it > messes with existing enum values). The OpenSSL implementation responds > to this ClientHello with a HelloVerifyMessage and Wireshark considers > the packet valid DTLS. > > You may find my patches at this URL: http://x2a.org/pub/dtls/ Even better. If you feel it would help you, you could have git access so you could push your work to a special branch. You need a savannah.gnu.org account and sign FSF papers though. > Unfortunately the lower end of the record layer and buffer/transport > layer seems rather messy to my untrained eye. I am having trouble > imagining implementing UDP buffering easely. I would need to buffer the > whole packet then iterate over the records contained within the packet. > > The main problem seems to be layering violations between the handshake, > record and buffer layers. Would it be better if _gnutls_{recv,send}_int > dealt with whole records (and possibly return prematurely if more data > or buffer space is required) ? _gnutls_{recv,send}_int could also deal > with the SSLv2.0 record encapsulation. The handhake layer would > therefore deal with those two functions for sending/receiving from the > lower layer. The handshake layer buffering would also be moved to > gnutls_handshake.c. > > Am I making any sense ? I agree that code is hairy, and I'm hoping Nikos can give you some advice. I don't feel strongly about changing this code, but it will need significant testing before we can feel comfortable with the changes. Maybe as a bonus side-effect, the code will become more readable... ;) Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= 100' after it so there is room for TLS 1.3 etc? Also, please drop the GNUTLS_DTLS1 mapping, I think it helps to be specific about version numbers at all places. I think this patch could be added quickly without problem. Re 0003-Add-DTLS-state.patch: do you think there will be more DTLS additions? I suggest putting the DTLS stuff into a separate struct, if you think it is OK. Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles one way. DTLS is really a completely new protocol, not just a different transport method for TLS. So maybe there should really be a new function that replaces gnutls_init? How about gnutls_init_dtls? It would return a gnutls_session_t for DTLS. Re last part of 0005-Make-version-lookup-transport-dependent.patch: Is this a good idea? Running DTLS over TCP won't work, will it? But I understand why you need this. Hm. Maybe the default priorities needs to be DTLS-specific -- this also argues for having gnutls_init_dtls function so that the priority setting functions know for certain that the session is a DTLS or non-DTLS session, and that won't change later. Generally, I like your incremental approach since it helps to review and merge the patches. I definitely think we should create a branch for your DTLS work. /Simon From joe at x2a.org Wed Jul 29 16:03:21 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 29 Jul 2009 10:03:21 -0400 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <87ocr3izcg.fsf@mocca.josefsson.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> Message-ID: <4A7056A9.9060004@x2a.org> Simon Josefsson wrote: > Jonathan Bastien-Filiatrault writes: > >> Hello, >> >> Being interested in DTLS and GnuTLS I have decided to try to implement >> DTLS in the GnuTLS library. > > Great! > >> I have managed to send a valid DTLS ClientHello using a modified GnuTLS >> in a relatively non-intrusive way (but which may break the ABI since it >> messes with existing enum values). The OpenSSL implementation responds >> to this ClientHello with a HelloVerifyMessage and Wireshark considers >> the packet valid DTLS. >> >> You may find my patches at this URL: http://x2a.org/pub/dtls/ > > Even better. > > If you feel it would help you, you could have git access so you could > push your work to a special branch. You need a savannah.gnu.org account > and sign FSF papers though. Alright, you can send me the copyright reassignment FSF papers. I will ensure that I have savannah account. I don't mind working on my local git tree for now. A dtls branch would be nice when the code is almost merge-ready or at least close to functionnal. >> Unfortunately the lower end of the record layer and buffer/transport >> layer seems rather messy to my untrained eye. I am having trouble >> imagining implementing UDP buffering easely. I would need to buffer the >> whole packet then iterate over the records contained within the packet. >> >> The main problem seems to be layering violations between the handshake, >> record and buffer layers. Would it be better if _gnutls_{recv,send}_int >> dealt with whole records (and possibly return prematurely if more data >> or buffer space is required) ? _gnutls_{recv,send}_int could also deal >> with the SSLv2.0 record encapsulation. The handhake layer would >> therefore deal with those two functions for sending/receiving from the >> lower layer. The handshake layer buffering would also be moved to >> gnutls_handshake.c. >> >> Am I making any sense ? > > I agree that code is hairy, and I'm hoping Nikos can give you some > advice. I don't feel strongly about changing this code, but it will > need significant testing before we can feel comfortable with the > changes. Maybe as a bonus side-effect, the code will become more > readable... ;) Actually, I started to read the code yesterday and it seems to make more sense than I originally thought. I would be more inclined to short-circuit a lot of the buffer layer to a UDP buffering layer. Datagram transport requires its own buffers for retransmission and reassembly. I think it would be possible to do this without disturbing much of the record and handshake layer and without code duplication (I would still use functions such as _gnutls_read). > Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you > re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= > 100' after it so there is room for TLS 1.3 etc? Also, please drop the > GNUTLS_DTLS1 mapping, I think it helps to be specific about version > numbers at all places. I think this patch could be added quickly > without problem. Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still experimental, could this breakage be tolerated ? I am wide open for a suggestions in this case... > > Re 0003-Add-DTLS-state.patch: do you think there will be more DTLS > additions? I suggest putting the DTLS stuff into a separate struct, if > you think it is OK. Yes, there needs to be more additions for datagram buffering and replay protection. Putting it in a sub-struct is not a problem. Would I keep it in the internals struct or at a higher level in the session struct ? > Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles > one way. DTLS is really a completely new protocol, not just a different > transport method for TLS. So maybe there should really be a new > function that replaces gnutls_init? How about gnutls_init_dtls? It > would return a gnutls_session_t for DTLS. I was thinking more of a set_transport in the long run with a DGRAM or STREAM argument and with a transport protocol selector for UDP, SCTP, DCCP and UDP-Lite. I guess gnutls_init_dtls could take those arguments instead. > Re last part of 0005-Make-version-lookup-transport-dependent.patch: Is > this a good idea? Running DTLS over TCP won't work, will it? But I > understand why you need this. Hm. Maybe the default priorities needs > to be DTLS-specific -- this also argues for having gnutls_init_dtls > function so that the priority setting functions know for certain that > the session is a DTLS or non-DTLS session, and that won't change later. DTLS over TCP would probably work as long as the code handles the "partial read" problem, but that is rather far in Bad Idea (TM) territory. I have been hesitant to do priority fiddling since I have not had a good look at that code. Is there a easy way I could put all DTLS versions in a separate priority list and set the priority list in gnutls_init_dtls ? > Generally, I like your incremental approach since it helps to review and > merge the patches. I definitely think we should create a branch for > your DTLS work. Thanks, that is what git rebase and git commit --amend is for :-)... Until the code is alpha quality I will probably do a lot of rebasing and cleaning of previous commits, I would need to be allowed to force updates on the dtls branch, at least for a while. > > /Simon Thanks for having a look at my patches, Cheers, Jonathan From simon at josefsson.org Wed Jul 29 17:04:19 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 17:04:19 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A7056A9.9060004@x2a.org> (Jonathan Bastien-Filiatrault's message of "Wed, 29 Jul 2009 10:03:21 -0400") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> Message-ID: <87ws5rwmx8.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Alright, you can send me the copyright reassignment FSF papers. I sent them separately. > I will ensure that I have savannah account. I don't mind working on my > local git tree for now. A dtls branch would be nice when the code is > almost merge-ready or at least close to functionnal. Ok, that's fine too. >>> Unfortunately the lower end of the record layer and buffer/transport >>> layer seems rather messy to my untrained eye. I am having trouble >>> imagining implementing UDP buffering easely. I would need to buffer the >>> whole packet then iterate over the records contained within the packet. >>> >>> The main problem seems to be layering violations between the handshake, >>> record and buffer layers. Would it be better if _gnutls_{recv,send}_int >>> dealt with whole records (and possibly return prematurely if more data >>> or buffer space is required) ? _gnutls_{recv,send}_int could also deal >>> with the SSLv2.0 record encapsulation. The handhake layer would >>> therefore deal with those two functions for sending/receiving from the >>> lower layer. The handshake layer buffering would also be moved to >>> gnutls_handshake.c. >>> >>> Am I making any sense ? >> >> I agree that code is hairy, and I'm hoping Nikos can give you some >> advice. I don't feel strongly about changing this code, but it will >> need significant testing before we can feel comfortable with the >> changes. Maybe as a bonus side-effect, the code will become more >> readable... ;) > > Actually, I started to read the code yesterday and it seems to make > more sense than I originally thought. I would be more inclined to > short-circuit a lot of the buffer layer to a UDP buffering > layer. Datagram transport requires its own buffers for retransmission > and reassembly. I think it would be possible to do this without > disturbing much of the record and handshake layer and without code > duplication (I would still use functions such as _gnutls_read). That's better. >> Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you >> re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= >> 100' after it so there is room for TLS 1.3 etc? Also, please drop the >> GNUTLS_DTLS1 mapping, I think it helps to be specific about version >> numbers at all places. I think this patch could be added quickly >> without problem. > > Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, > mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still > experimental, could this breakage be tolerated ? I am wide open for a > suggestions in this case... Where are these "ver <" checks? I recall only a few. I think those checks are broken, and should be replace with a small inline function that maps TLS version to requested behaviour (I'm thinking a switch..case mapping). >> Re 0003-Add-DTLS-state.patch: do you think there will be more DTLS >> additions? I suggest putting the DTLS stuff into a separate struct, if >> you think it is OK. > > Yes, there needs to be more additions for datagram buffering and > replay protection. Putting it in a sub-struct is not a problem. Would > I keep it in the internals struct or at a higher level in the session > struct ? I prefer the internals struct. >> Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles >> one way. DTLS is really a completely new protocol, not just a different >> transport method for TLS. So maybe there should really be a new >> function that replaces gnutls_init? How about gnutls_init_dtls? It >> would return a gnutls_session_t for DTLS. > > I was thinking more of a set_transport in the long run with a DGRAM or > STREAM argument and with a transport protocol selector for UDP, SCTP, > DCCP and UDP-Lite. I guess gnutls_init_dtls could take those arguments > instead. A set_transport function would work if the protocols are the same, but it seems several parts of GnuTLS will behave quite different depending on whether TLS or DTLS is used (e.g., the set_priority functions) so it is important to use a gnutls_init_dtls approach. >> Re last part of 0005-Make-version-lookup-transport-dependent.patch: Is >> this a good idea? Running DTLS over TCP won't work, will it? But I >> understand why you need this. Hm. Maybe the default priorities needs >> to be DTLS-specific -- this also argues for having gnutls_init_dtls >> function so that the priority setting functions know for certain that >> the session is a DTLS or non-DTLS session, and that won't change later. > > DTLS over TCP would probably work as long as the code handles the > "partial read" problem, but that is rather far in Bad Idea (TM) > territory. I have been hesitant to do priority fiddling since I have > not had a good look at that code. Is there a easy way I could put all > DTLS versions in a separate priority list and set the priority list in > gnutls_init_dtls ? That's how it should work, I think. You could make the set_priority functions check early on whether it is for DTLS or TLS. Keep the TLS-case as is today, and write new code for the DTLS code as appropriate. You may want to forbid some old ciphers or SSL stuff for DTLS. >> Generally, I like your incremental approach since it helps to review and >> merge the patches. I definitely think we should create a branch for >> your DTLS work. > > Thanks, that is what git rebase and git commit --amend is for > :-)... Until the code is alpha quality I will probably do a lot of > rebasing and cleaning of previous commits, I would need to be allowed > to force updates on the dtls branch, at least for a while. Right. /Simon From nmav at gnutls.org Wed Jul 29 19:55:07 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 29 Jul 2009 20:55:07 +0300 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A7056A9.9060004@x2a.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> Message-ID: <4A708CFB.7030503@gnutls.org> Jonathan Bastien-Filiatrault wrote: Hello Jonathan, Due to lack of time I did some quick glimpse, and attach some quick comments. >>> Being interested in DTLS and GnuTLS I have decided to try to implement >>> DTLS in the GnuTLS library. That's really good news! >>> Unfortunately the lower end of the record layer and buffer/transport >>> layer seems rather messy to my untrained eye. I am having trouble >>> imagining implementing UDP buffering easely. I would need to buffer the >>> whole packet then iterate over the records contained within the packet. >>> >>> The main problem seems to be layering violations between the handshake, >>> record and buffer layers. Would it be better if _gnutls_{recv,send}_int >>> dealt with whole records (and possibly return prematurely if more data >>> or buffer space is required) ? _gnutls_{recv,send}_int could also deal >>> with the SSLv2.0 record encapsulation. The handhake layer would >>> therefore deal with those two functions for sending/receiving from the >>> lower layer. The handshake layer buffering would also be moved to >>> gnutls_handshake.c. >>> >>> Am I making any sense ? >> >> I agree that code is hairy, and I'm hoping Nikos can give you some >> advice. I don't feel strongly about changing this code, but it will >> need significant testing before we can feel comfortable with the >> changes. Maybe as a bonus side-effect, the code will become more >> readable... ;) > > Actually, I started to read the code yesterday and it seems to make more > sense than I originally thought. I would be more inclined to > short-circuit a lot of the buffer layer to a UDP buffering layer. > Datagram transport requires its own buffers for retransmission and > reassembly. I think it would be possible to do this without disturbing > much of the record and handshake layer and without code duplication (I > would still use functions such as _gnutls_read). It's good that you understood the code. This part is one of the oldest parts and quite unreadable. If you have any questions on that let me know. I really don't know what will be faster to do for DTLS... rewriting this part of code or extending it. Anyway if you have any specific questions on functionality or purpose let me know... >> Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you >> re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= >> 100' after it so there is room for TLS 1.3 etc? Also, please drop the >> GNUTLS_DTLS1 mapping, I think it helps to be specific about version >> numbers at all places. I think this patch could be added quickly >> without problem. > Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, > mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still > experimental, could this breakage be tolerated ? I am wide open for a > suggestions in this case... In general I'd agree with simon that DTLS should be distinct from TLSx.y. For the specific tests maybe we should move those into designated functions such as if (_check_for_feature_xyz(tlsversion)) { ... }. And a more complex matching algorithm will be present there. >> Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles >> one way. DTLS is really a completely new protocol, not just a different >> transport method for TLS. So maybe there should really be a new >> function that replaces gnutls_init? How about gnutls_init_dtls? It >> would return a gnutls_session_t for DTLS. If there no issues in initialization the obvious place for me to be done would be gnutls_priority_set() and gnutls_protocol_set_priority(). There the actual version of the protocol that will be used is given and if DTLS is there the function should act accordingly. That way the same API can be used for both. > I was thinking more of a set_transport in the long run with a DGRAM or > STREAM argument and with a transport protocol selector for UDP, SCTP, > DCCP and UDP-Lite. I guess gnutls_init_dtls could take those arguments > instead. You mean for setting different push/pull functions? Those could be in predefined macros that are explicitly called. regards, Nikos From nmav at gnutls.org Wed Jul 29 19:57:25 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 29 Jul 2009 20:57:25 +0300 Subject: [PATCH] session ticket support In-Reply-To: References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> Message-ID: <4A708D85.7070702@gnutls.org> Daiki Ueno wrote: > When I changed _gnutls_recv_new_session_ticket to generate new session > ID, it started to work. I attach the new patch, which includes: > > * Adaption for gnutls-cli/gnutls-serv. > > Session ticket support is enabled by default, while it can be disabled > by --noticket option. You can test the interoperability with: > > $ gnutls-serv -p 10000 --nodb --x509cafile x509-ca.pem \ > --x509keyfile x509-server-key.pem --x509certfile x509-server.pem > $ openssl s_client -connect localhost:10000 -reconnect > > and > > $ openssl s_server -accept 10000 -CAfile x509-ca.pem \ > -key x509-server-key.pem -cert x509-server.pem > $ gnutls-cli -p 10000 --resume localhost > > * New interface functions as you suggested. Thank you. I'll check it as soon. All best, Nikos From simon at josefsson.org Wed Jul 29 20:35:36 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 20:35:36 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A708CFB.7030503@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 29 Jul 2009 20:55:07 +0300") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> Message-ID: <87y6q7pcav.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: >>> Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you >>> re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= >>> 100' after it so there is room for TLS 1.3 etc? Also, please drop the >>> GNUTLS_DTLS1 mapping, I think it helps to be specific about version >>> numbers at all places. I think this patch could be added quickly >>> without problem. >> Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, >> mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still >> experimental, could this breakage be tolerated ? I am wide open for a >> suggestions in this case... > > In general I'd agree with simon that DTLS should be distinct from > TLSx.y. For the specific tests maybe we should move those into > designated functions such as if (_check_for_feature_xyz(tlsversion)) { > ... }. And a more complex matching algorithm will be present there. Exactly. >>> Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles >>> one way. DTLS is really a completely new protocol, not just a different >>> transport method for TLS. So maybe there should really be a new >>> function that replaces gnutls_init? How about gnutls_init_dtls? It >>> would return a gnutls_session_t for DTLS. > > If there no issues in initialization the obvious place for me to be done > would be gnutls_priority_set() and gnutls_protocol_set_priority(). There > the actual version of the protocol that will be used is given and if > DTLS is there the function should act accordingly. That way the same API > can be used for both. Hm. Are you suggesting that DTLS should be enabled through a priority string? I kind of like that. I'm not sure it is sufficient -- some other functions called before the handshake may also want to know if DTLS or normal TLS is going to be used. Then the order of calls will matter -- i.e., if gnutls_priority_set("DTLS") is called before or after the call to this other API. So a gnutls_init_dtls seems safer to me. /Simon From simon at josefsson.org Wed Jul 29 20:37:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 20:37:48 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A708CFB.7030503@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 29 Jul 2009 20:55:07 +0300") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> Message-ID: <87tz0vpc77.fsf@mocca.josefsson.org> Jonathan, how much code do you think DTLS will add? Perhaps we should create a header file gnutls/dtls.h for the DTLS-specific APIs and create a separate library libgnutls-dtls for the DTLS-specific parts. /Simon From joe at x2a.org Wed Jul 29 20:42:29 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 29 Jul 2009 14:42:29 -0400 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A708CFB.7030503@gnutls.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> Message-ID: <4A709815.4090206@x2a.org> Nikos Mavrogiannopoulos wrote: >> I was thinking more of a set_transport in the long run with a DGRAM or >> STREAM argument and with a transport protocol selector for UDP, SCTP, >> DCCP and UDP-Lite. I guess gnutls_init_dtls could take those arguments >> instead. > > You mean for setting different push/pull functions? Those could be in > predefined macros that are explicitly called. I was referring to DTLS over DCCP and SCTP having specific quirks (and specs, RFC5238 and draft-ietf-tsvwg-dtls-for-sctp-01). DTLS needs a way to be told it is using something other than UDP. > regards, > Nikos Cheers, Jonathan From simon at josefsson.org Wed Jul 29 20:42:01 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 20:42:01 +0200 Subject: GnuTLS for Win64 In-Reply-To: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> (Tomas Kukosa's message of "Wed, 8 Jul 2009 13:27:16 +0200") References: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> Message-ID: <87prbjpc06.fsf@mocca.josefsson.org> "Kukosa, Tomas" writes: > Are there any plans in this respect? I believe Mingw64 is close to working (?), so if someone could help me get that compiler to work (simplest is to give me a .deb package for it) I could build GnuTLS for win64 using it. I don't think any code changes would be necessary. /Simon From joe at x2a.org Wed Jul 29 20:47:17 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 29 Jul 2009 14:47:17 -0400 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <87tz0vpc77.fsf@mocca.josefsson.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> <87tz0vpc77.fsf@mocca.josefsson.org> Message-ID: <4A709935.2050507@x2a.org> Simon Josefsson wrote: > Jonathan, how much code do you think DTLS will add? Perhaps we should > create a header file gnutls/dtls.h for the DTLS-specific APIs and create > a separate library libgnutls-dtls for the DTLS-specific parts. > > /Simon Maybe... The bigger part of the code will be handshake retransmission and reassembly. Retransmission will probably use a linked list of packets and I am thinking of using a binary heap for reassembly. I don't think it will be huge. I am hoping that is the only logic I have to build from scratch (so far so good). At the very least I will have a gnutls_dtls_buffers.{c,h}. Jonathan From simon at josefsson.org Wed Jul 29 20:49:41 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 20:49:41 +0200 Subject: Patch for _gnutls_send_finished in gnutls_handshake.c In-Reply-To: <4A5116DB.1010408@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 06 Jul 2009 00:10:51 +0300") References: <4A4A824B.1040905@filezilla-project.org> <4A4BB82D.8000507@gnutls.org> <4A4BD29F.2060307@filezilla-project.org> <4A5116DB.1010408@gnutls.org> Message-ID: <87ljm7pbne.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Tim Kosse wrote: > >> Thanks for applying the patch(es). Are there any plans for a 2.8.2 >> release in the near future? > > It's up to Simon. I've been on vacation and slowly catching up on e-mails. I don't see this patch in the 2.8.x branch. Tim, is it required to make things work? There is another patch in the 2.8.x branch which seems to address a similar problem. Are both patches needed? /Simon From simon at josefsson.org Wed Jul 29 20:55:25 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 20:55:25 +0200 Subject: Bug in gnutls breaking Pidgin Jabber support In-Reply-To: <4A4A898D.4000700@filezilla-project.org> (Tim Kosse's message of "Tue, 30 Jun 2009 23:54:21 +0200") References: <4A3FBDC1.8070102@darkrain42.org> <873a9qu9xp.fsf@mocca.josefsson.org> <4A486960.6010405@filezilla-project.org> <4A4874C3.4010709@filezilla-project.org> <4A4A5D0D.40701@gnutls.org> <4A4A66AF.6010002@filezilla-project.org> <4A4A7215.6010402@gnutls.org> <4A4A7693.9000806@filezilla-project.org> <4A4A898D.4000700@filezilla-project.org> Message-ID: <87eirzpbdu.fsf@mocca.josefsson.org> Tim Kosse writes: > Hi, > > since my initial assumptions got invalidated, I no longer consider my > earlier patch as a merely an ugly workaround but instead as a viable > solution. I've attached an updated version of the patch. In addition to > _gnutls_io_write_buffered, _gnutls_handshake_io_send_int is fixed as well. > > Combined with the handshake patch I've previously mailed, I've been > unable to reproduce any problems with GnuTLS in FileZilla. How are those two patches related? Is this patch for application data, and the other for handshakes? We need a NEWS entry for this. I'm considering: ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. Report and patch by Tim Kosse in and . Or should the two patches have one NEWS entry each? Please advice. /Simon > --- lib/gnutls_buffers.c_old 2009-06-29 09:57:46.934517539 +0200 > +++ lib/gnutls_buffers.c 2009-06-30 23:43:22.000000000 +0200 > @@ -657,7 +657,7 @@ > { > gnutls_datum bdata; > /* checking is handled above */ > - _gnutls_buffer_get_datum (&session->internals.record_send_buffer, &bdata, n); > + _gnutls_buffer_get_datum (&session->internals.record_send_buffer, &bdata, session->internals.record_send_buffer.length); > > ptr = bdata.data; > n = bdata.size; > @@ -854,7 +854,7 @@ > gnutls_assert (); > > /* checking is handled above */ > - _gnutls_buffer_get_datum (&session->internals.handshake_send_buffer, &bdata, n); > + _gnutls_buffer_get_datum (&session->internals.handshake_send_buffer, &bdata, session->internals.handshake_send_buffer.length); > > ptr = bdata.data; > n = bdata.size; > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From simon at josefsson.org Wed Jul 29 21:01:39 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 21:01:39 +0200 Subject: Certificate Request State In-Reply-To: <4A4BB526.4040208@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 01 Jul 2009 22:12:38 +0300") References: <20090630202448.19789.qmail@wiredyne.com> <4A4BB526.4040208@gnutls.org> Message-ID: <87ab2npb3g.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Peter Hendrickson wrote: >> Running GnuTLS 2.8.1 under Ubuntu 9.04, I find that >> gnutls_certificate_client_get_request_status() falsely reports that no >> client certificate was requested, even when there was a request. (The >> server code is supposed to be asking for a certificate, it >> successfully verifies the client certificate, and I can see the >> certificate request packet to the client and the client sending its >> certificate.) >> >> Watching in the debugger, it appears that when the "Certificate >> Request" handshake packet arrives at the client from the server, the >> client sets session->key->certificate_requested to 1 in >> auth_cert.c:_gnutls_proc_cert_cert_req(). >> >> The problem seems to lie in gnutls_certificate_client_get_request_status() >> itself. > > Corrected thanks. I also don't remember why this is like that. It must > have been some incomplete attempt to move this variable from the key to > auth_info structure. Thanks for report Peter. I added a NEWS entry about this: ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. Before it always returned false. Reported by Peter Hendrickson in . And also back-ported it to GnuTLS 2.8.x, it seemed like a obvious and safe fix. /Simon From simon at josefsson.org Wed Jul 29 21:16:37 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 21:16:37 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A709815.4090206@x2a.org> (Jonathan Bastien-Filiatrault's message of "Wed, 29 Jul 2009 14:42:29 -0400") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> <4A709815.4090206@x2a.org> Message-ID: <87y6q7nvu2.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Nikos Mavrogiannopoulos wrote: >>> I was thinking more of a set_transport in the long run with a DGRAM or >>> STREAM argument and with a transport protocol selector for UDP, SCTP, >>> DCCP and UDP-Lite. I guess gnutls_init_dtls could take those arguments >>> instead. >> >> You mean for setting different push/pull functions? Those could be in >> predefined macros that are explicitly called. > > I was referring to DTLS over DCCP and SCTP having specific quirks (and > specs, RFC5238 and draft-ietf-tsvwg-dtls-for-sctp-01). DTLS needs a > way to be told it is using something other than UDP. Ouch, I see. How about something like this: typedef enum { GNUTLS_DTLS_OVER_DCCP } gnutls_dtls_flags_t; int gnutls_init_dtls (gnutls_session_t * session, gnutls_connection_end_t con_end, gnutls_dtls_flags_t flags); A "flags" concept is somewhat more generic since it allows for other DTLS-flavors than just those influenced by the transport. Another alternative is to use a priority string but I'm not sure it will work -- there is the ordering of API calls problem I mentioned earlier. /Simon From simon at josefsson.org Wed Jul 29 21:46:00 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 21:46:00 +0200 Subject: compilation difficulties on Mac In-Reply-To: <4A48038C.80308@technoplaza.net> (John Ratliff's message of "Sun, 28 Jun 2009 19:58:04 -0400") References: <4A48038C.80308@technoplaza.net> Message-ID: <87tz0vnuh3.fsf@mocca.josefsson.org> John Ratliff writes: > For some reason, Mac cannot build the doc folder on gnutls. Because of > this, make install will not proceed. I have been editing the Makefile > to prevent the doc folder from being built, but I wonder if there is a > better solution to this. > > I am using the 2009-06-28 daily source release, but this problem > affects all versions (2.8.1, 2.6.x, 2.4.2, and 2.2.5 tested). It > manifests on both Tiger and Leopard. It builds fine on my powerbook: http://autobuild.josefsson.org/gnutls/#GnuTLS-powerpc-apple-darwin8.11.0 > My configure line > > ./configure --disable-shared > --with-libgcrypt-prefix=$HOME/unix/libgcrypt --prefix > $HOME/unix/gnutls-20090628 > > My configure output: http://code.technoplaza.net/temp/gnutls/configure.log > The output of make http://code.technoplaza.net/temp/gnutls/make.log Can you try without --disabled-shared? > The library builds fine, and if I edit the Makefile to tell it to > ignore the doc directory, I can use make install and the library works > perfectly. I am presently using this patch > http://code.technoplaza.net/filezilla/gnutls-2.8.patch to adjust the > Makefile. > > Any better suggestions? Sorry I can't think of anything. The error message is: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib/includes -I../lib/includes -I/Users/jdratlif/unix/libgcrypt/include -I/Users/jdratlif/unix/libgpg-error-1.7/include -g -O2 -MT errcodes.o -MD -MP -MF .deps/errcodes.Tpo -c -o errcodes.o errcodes.c mv -f .deps/errcodes.Tpo .deps/errcodes.Po /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -o errcodes errcodes.o ../lib/libgnutls.la ../gl/libgnu.la libtool: link: gcc -std=gnu99 -g -O2 -o errcodes errcodes.o ../lib/.libs/libgnutls.a -L/Users/jdratlif/unix/libgcrypt/lib -L/Users/jdratlif/unix/libgpg-error-1.7/lib -lz /Users/jdratlif/unix/libgcrypt-1.4.4/lib/libgcrypt.a /Users/jdratlif/unix/libgpg-error-1.7/lib/libgpg-error.a ../gl/.libs/libgnu.a Undefined symbols: "__gnutls_log_func", referenced from: __gnutls_log_func$non_lazy_ptr in libgnutls.a(gnutls_errors.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[4]: *** [errcodes] Error 1 but I don't recognize it. If dropping --disable-shared doesn't help I don't know. Maybe some Mac OS X expert can help if you quote the above error message. /Simon From simon at josefsson.org Wed Jul 29 22:43:16 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 22:43:16 +0200 Subject: GNU Libtasn1 2.3 Message-ID: <87tz0vmd97.fsf@mocca.josefsson.org> I'm happy to announce the first release of Libtasn1 as an official GNU project. GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. Libtasn1 is used by GnuTLS to parse and generate X.509 structures and by Shishi to parse and generate Kerberos V5 structures. * Noteworthy changes in release 2.3 (2009-07-29) [stable] - Libtasn1 is now an official GNU project. - Solve build problem on Tru64 related to TRUE/FALSE. - More careful decoding of OIDs. - Fixed warning in ASN1.y. - Use "Software libraries" info dircategory. - Drop GPL/LGPL copies from the manual (not needed there). - New configure parameters to set packaging specific information. The parameters are --with-packager, --with-packager-version, and --with-packager-bug-reports. See for more details. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, 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 the help-gnutls mailing list, see: . Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.3.zip http://josefsson.org/gnutls4win/libtasn1-2.3.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.3-1_all.deb The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] 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: 2010-04-21] 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: 71607f846e83849f0722ffdd93247028c9c88384 libtasn1-2.3.tar.gz 0dc935133aa110fc17e0c212ca3c9b446f3da37e5e51ea1c8561c3ec libtasn1-2.3.tar.gz 31d1570b30f9a86850d74e535138f52f8f164179 libtasn1-2.3.zip 623864081339c7ef653d0356d6abadc64e0a799031351277e302c3ef libtasn1-2.3.zip 461ed2aa187cc86780ca0155b08be05401f9a403 mingw32-libtasn1_2.3-1_all.deb 425d98c7b456d120bf103a0fef59eff55f3694a9682ee0bd3240289d mingw32-libtasn1_2.3-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From nmav at gnutls.org Wed Jul 29 23:02:04 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Jul 2009 00:02:04 +0300 Subject: Patch for _gnutls_send_finished in gnutls_handshake.c In-Reply-To: <87ljm7pbne.fsf@mocca.josefsson.org> References: <4A4A824B.1040905@filezilla-project.org> <4A4BB82D.8000507@gnutls.org> <4A4BD29F.2060307@filezilla-project.org> <4A5116DB.1010408@gnutls.org> <87ljm7pbne.fsf@mocca.josefsson.org> Message-ID: <4A70B8CC.7070901@gnutls.org> Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> Tim Kosse wrote: >> >>> Thanks for applying the patch(es). Are there any plans for a 2.8.2 >>> release in the near future? >> It's up to Simon. > > I've been on vacation and slowly catching up on e-mails. I don't see > this patch in the 2.8.x branch. I just pushed it. From nmav at gnutls.org Wed Jul 29 23:10:02 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Jul 2009 00:10:02 +0300 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <87y6q7pcav.fsf@mocca.josefsson.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> <87y6q7pcav.fsf@mocca.josefsson.org> Message-ID: <4A70BAAA.4040009@gnutls.org> Simon Josefsson wrote: >>>> Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles >>>> one way. DTLS is really a completely new protocol, not just a different >>>> transport method for TLS. So maybe there should really be a new >>>> function that replaces gnutls_init? How about gnutls_init_dtls? It >>>> would return a gnutls_session_t for DTLS. >> If there no issues in initialization the obvious place for me to be done >> would be gnutls_priority_set() and gnutls_protocol_set_priority(). There >> the actual version of the protocol that will be used is given and if >> DTLS is there the function should act accordingly. That way the same API >> can be used for both. > > Hm. Are you suggesting that DTLS should be enabled through a priority > string? I kind of like that. I'm not sure it is sufficient -- some > other functions called before the handshake may also want to know if > DTLS or normal TLS is going to be used. Then the order of calls will > matter -- i.e., if gnutls_priority_set("DTLS") is called before or after > the call to this other API. So a gnutls_init_dtls seems safer to me. I don't really know about that. What functionality would that be? For me since DTLS is supposed to be just another version of TLS it feels it should be configurable through the version interface. If multiple functions initialization are needed for another variants it would be not a nice API IMHO (it would be possible to initialize tls but specify TLS 1.2 through the priority api?). I thought initially that some extended gnutls_init_ext() would be useful, but since we already have the priority API I see no point in making a new API for that (unless of course there is not alternative due to technical problems). regards, Nikos From simon at josefsson.org Wed Jul 29 23:16:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 23:16:48 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A70BAAA.4040009@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 30 Jul 2009 00:10:02 +0300") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> <87y6q7pcav.fsf@mocca.josefsson.org> <4A70BAAA.4040009@gnutls.org> Message-ID: <87iqhbmbpb.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >>>>> Re 0004-Add-gnutls_session_datagram-function.patch: this just toggles >>>>> one way. DTLS is really a completely new protocol, not just a different >>>>> transport method for TLS. So maybe there should really be a new >>>>> function that replaces gnutls_init? How about gnutls_init_dtls? It >>>>> would return a gnutls_session_t for DTLS. >>> If there no issues in initialization the obvious place for me to be done >>> would be gnutls_priority_set() and gnutls_protocol_set_priority(). There >>> the actual version of the protocol that will be used is given and if >>> DTLS is there the function should act accordingly. That way the same API >>> can be used for both. >> >> Hm. Are you suggesting that DTLS should be enabled through a priority >> string? I kind of like that. I'm not sure it is sufficient -- some >> other functions called before the handshake may also want to know if >> DTLS or normal TLS is going to be used. Then the order of calls will >> matter -- i.e., if gnutls_priority_set("DTLS") is called before or after >> the call to this other API. So a gnutls_init_dtls seems safer to me. > > I don't really know about that. What functionality would that be? Maybe there aren't any. I was thinking about size limits, or some requirements on credentials used that applies only to DTLS -- for example how about a RSA-EXPORT credential? What about TLS extensions? Are all TLS extensions applicable to DTLS automatically, without any change in behaviour? On the other hand, if applications requests DTLS and calls APIs which aren't applicable to DTLS, they shouldn't expect things to work. So maybe the impact is low. If Jonathan doesn't discover anything when his DTLS support is ready to be merged, I'm fine with using a priority string to switch over to DTLS mode. /Simon > For me since DTLS is supposed to be just another version of TLS it > feels it should be configurable through the version interface. If > multiple functions initialization are needed for another variants it > would be not a nice API IMHO (it would be possible to initialize tls > but specify TLS 1.2 through the priority api?). I thought initially > that some extended gnutls_init_ext() would be useful, but since we > already have the priority API I see no point in making a new API for > that (unless of course there is not alternative due to technical > problems). From joe at x2a.org Thu Jul 30 01:55:10 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 29 Jul 2009 19:55:10 -0400 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A708CFB.7030503@gnutls.org> References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> Message-ID: <4A70E15E.5080502@x2a.org> Nikos Mavrogiannopoulos wrote: > specific questions on functionality or purpose let me know... > >>> Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you >>> re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= >>> 100' after it so there is room for TLS 1.3 etc? Also, please drop the >>> GNUTLS_DTLS1 mapping, I think it helps to be specific about version >>> numbers at all places. I think this patch could be added quickly >>> without problem. >> Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, >> mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still >> experimental, could this breakage be tolerated ? I am wide open for a >> suggestions in this case... > > In general I'd agree with simon that DTLS should be distinct from > TLSx.y. For the specific tests maybe we should move those into > designated functions such as if (_check_for_feature_xyz(tlsversion)) { > ... }. And a more complex matching algorithm will be present there. > So in _gnutls_finished the ver < GNUTLS_TLS1_2 checks would become something like !_gnutls_has_selectable_prf(session) ? I suggest putting such functions in gnutls_algorithms.c. Any objections ? Side note: I have setup a public git repository for your viewing pleasure. cgit URL: http://x2a.org/git/gnutls/ pull URL: git://x2a.org/gnutls.git WARNING: the dtls-wip branch is regularly rebased, do not use for any permanent merging or cherry-picking. Cheers, Jonathan From arfrever.fta at gmail.com Thu Jul 30 04:48:41 2009 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 Jul 2009 04:48:41 +0200 Subject: GNU Libtasn1 2.3 In-Reply-To: <87tz0vmd97.fsf@mocca.josefsson.org> References: <87tz0vmd97.fsf@mocca.josefsson.org> Message-ID: <200907300448.45843.Arfrever.FTA@gmail.com> 2009-07-29 22:43:16 Simon Josefsson napisa?(a): >... > Here are the compressed sources (1.5MB): > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > > Here are GPG detached signatures using key 0xB565716F: > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig s:gnutls:libtasn1: Please fix URLs in your e-mail template :) . -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From webmaster at technoplaza.net Thu Jul 30 05:50:16 2009 From: webmaster at technoplaza.net (John Ratliff) Date: Wed, 29 Jul 2009 23:50:16 -0400 Subject: compilation difficulties on Mac In-Reply-To: <87tz0vnuh3.fsf@mocca.josefsson.org> References: <4A48038C.80308@technoplaza.net> <87tz0vnuh3.fsf@mocca.josefsson.org> Message-ID: <4A711878.7090608@technoplaza.net> Simon Josefsson wrote: >> My configure line >> >> ./configure --disable-shared >> --with-libgcrypt-prefix=$HOME/unix/libgcrypt --prefix >> $HOME/unix/gnutls-20090628 >> >> My configure output: http://code.technoplaza.net/temp/gnutls/configure.log >> The output of make http://code.technoplaza.net/temp/gnutls/make.log >> > > Can you try without --disabled-shared? > Shared builds work fine. It's only static builds that fail. I didn't want to use shared libraries because I'm distributing an application and it's difficult to bundle shared libraries with an application. I wrote some perl scripts that help me change the library names and paths which ease the process, so I guess I will do that from now on. I haven't found any way to do this automatically. Perhaps there is a better way I have overlooked, but I'm not well versed in OS X development tools. Have you tried it with --disable-shared? It doesn't seem to work. Also requires libgcrypt to have a shared version built, which in turn requires libgpg-error to be built shared. > >> The library builds fine, and if I edit the Makefile to tell it to >> ignore the doc directory, I can use make install and the library works >> perfectly. I am presently using this patch >> http://code.technoplaza.net/filezilla/gnutls-2.8.patch to adjust the >> Makefile. >> >> Any better suggestions? >> > > Someone told me to change to the lib subdirectory and make from there. That's what I've been doing and it lets me eliminate the patch. --John Ratliff From tml at iki.fi Thu Jul 30 12:04:50 2009 From: tml at iki.fi (Tor Lillqvist) Date: Thu, 30 Jul 2009 13:04:50 +0300 Subject: GnuTLS for Win64 In-Reply-To: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> References: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> Message-ID: There are 64-bit Windows binaries also for GnuTLS in the openSUSE Build Service hosted cross-compilation project: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_10.3/noarch/ (I have not personally used them, so I am not sure how well they work.) --tml From simon at josefsson.org Thu Jul 30 13:30:47 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 30 Jul 2009 13:30:47 +0200 Subject: [WIP] DTLS 1.0 preliminary patches In-Reply-To: <4A70E15E.5080502@x2a.org> (Jonathan Bastien-Filiatrault's message of "Wed, 29 Jul 2009 19:55:10 -0400") References: <4A6F6F88.7000207@x2a.org> <87ocr3izcg.fsf@mocca.josefsson.org> <4A7056A9.9060004@x2a.org> <4A708CFB.7030503@gnutls.org> <4A70E15E.5080502@x2a.org> Message-ID: <87bpn28l20.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Nikos Mavrogiannopoulos wrote: > >> specific questions on functionality or purpose let me know... >> >>>> Re 0002-Add-DTLS1.0-protocol-entry.patch: This breaks the API. Can you >>>> re-order the DTLS addition so it is after GNUTLS_TLS1_2 and add a '= >>>> 100' after it so there is room for TLS 1.3 etc? Also, please drop the >>>> GNUTLS_DTLS1 mapping, I think it helps to be specific about version >>>> numbers at all places. I think this patch could be added quickly >>>> without problem. >>> Alright, but DTLS1.0 needs to be sandwiched between TLS1.1 and TLS1.2, >>> mostly for ver < GNUTLS_TLS1_2 checks. Since TLS1.2 is still >>> experimental, could this breakage be tolerated ? I am wide open for a >>> suggestions in this case... >> >> In general I'd agree with simon that DTLS should be distinct from >> TLSx.y. For the specific tests maybe we should move those into >> designated functions such as if (_check_for_feature_xyz(tlsversion)) { >> ... }. And a more complex matching algorithm will be present there. >> > > So in _gnutls_finished the ver < GNUTLS_TLS1_2 checks would become > something like !_gnutls_has_selectable_prf(session) ? > > I suggest putting such functions in gnutls_algorithms.c. Any objections ? Yes. We could apply this directly, it makes the code more clear. > Side note: I have setup a public git repository for your viewing pleasure. > > cgit URL: http://x2a.org/git/gnutls/ > pull URL: git://x2a.org/gnutls.git > > WARNING: the dtls-wip branch is regularly rebased, do not use for any > permanent merging or cherry-picking. Great. /Simon From simon at josefsson.org Thu Jul 30 13:31:29 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 30 Jul 2009 13:31:29 +0200 Subject: GNU Libtasn1 2.3 In-Reply-To: <200907300448.45843.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Thu, 30 Jul 2009 04:48:41 +0200") References: <87tz0vmd97.fsf@mocca.josefsson.org> <200907300448.45843.Arfrever.FTA@gmail.com> Message-ID: <877hxq8l0u.fsf@mocca.josefsson.org> Arfrever Frehtes Taifersar Arahesis writes: > 2009-07-29 22:43:16 Simon Josefsson napisa?(a): >>... >> Here are the compressed sources (1.5MB): >> ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz >> http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz >> >> Here are GPG detached signatures using key 0xB565716F: >> ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig >> http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig > > s:gnutls:libtasn1: > Please fix URLs in your e-mail template :) . Ouch! Thanks for pointing this out. /Simon From simon at josefsson.org Thu Jul 30 13:33:51 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 30 Jul 2009 13:33:51 +0200 Subject: GNU Libtasn1 2.3 In-Reply-To: <87tz0vmd97.fsf__5819.01253103769$1248929158$gmane$org@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 29 Jul 2009 22:43:16 +0200") References: <87tz0vmd97.fsf__5819.01253103769$1248929158$gmane$org@mocca.josefsson.org> Message-ID: <873a8e8kww.fsf@mocca.josefsson.org> Simon Josefsson writes: > Here are the compressed sources (1.5MB): > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > > Here are GPG detached signatures using key 0xB565716F: > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig The correct URLs should be: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig Thanks to Arfrever Frehtes Taifersar Arahesis for noticing this. /Simon From simon at josefsson.org Thu Jul 30 14:08:28 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 30 Jul 2009 14:08:28 +0200 Subject: GnuTLS for Win64 In-Reply-To: (Tor Lillqvist's message of "Thu, 30 Jul 2009 13:04:50 +0300") References: <55C8A85ABA86D246826721A8F165C8DE64518C@atnets15pa.ww300.siemens.net> Message-ID: <87ocr274qr.fsf@mocca.josefsson.org> Tor Lillqvist writes: > There are 64-bit Windows binaries also for GnuTLS in the openSUSE > Build Service hosted cross-compilation project: > > http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_10.3/noarch/ > > (I have not personally used them, so I am not sure how well they work.) Thanks for the pointer. It seems OpenSUSE has RPM packages for mingw64, so I'll see if I can get them to work. It would be nice to have a proper GnuTLS4Win64 binary installer. /Simon From nmav at gnutls.org Thu Jul 30 22:48:43 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Jul 2009 23:48:43 +0300 Subject: [PATCH] session ticket support In-Reply-To: References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> Message-ID: On Tue, Jul 28, 2009 at 4:27 AM, Daiki Ueno wrote: > When I changed _gnutls_recv_new_session_ticket to generate new session > ID, it started to work. ?I attach the new patch, which includes: [...] Hello Daiki, I have some questions for you. I was checking the parts that unpack and pack the session and was wondering whether using the _gnutls_session_pack() would be possible. In that case both implementations of the DB and session ticket backends will share common code. The parts that triggered my interest there is that the rfc suggests some structures that are actually another implementation of those gnutls functions (and the individual cases such as psk/certificates are already handled there). Do you think that the rfc format for packed data would be more suitable, or there are reasons to use it instead of the internal? Another issue I noticed while checking the code is that if the session ticket doesn't decrypt well or doesn't verify well, an error is returned... Wouldn't it be more appropriate to just continue ignoring the ticket and perform a full handshake? all best, Nikos