From nmav at gnutls.org Mon Apr 2 20:40:45 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 02 Apr 2012 20:40:45 +0200 Subject: gnutls 3.0.18 Message-ID: <4F79F2AD.4020202@gnutls.org> Hello, I've just released gnutls 3.0.18. This is a bug-fix release on the current stable branch. Note that this release is available both under xz and lzip compression formats. We might switch to using only one of these compression formats in the future. * Version 3.0.18 (released 2012-04-02) ** certtool: Avoid a Y2K38 bug when generating certificates. Patch by Robert Millan. ** libgnutls: Make sure that GNUTLS_E_PREMATURE_TERMINATION is returned on premature termination (and added unit test). ** libgnutls: Fixes for W64 API. Patch by B. Scott Michel. ** libgnutls: Corrected VIA padlock detection for old VIA processors. Reported by Kris Karas. ** libgnutls: Updated assembler files. ** libgnutls: Time in generated certificates is stored as GeneralizedTime instead of UTCTime (which only stores 2 digits of a year). ** minitasn1: Upgraded to libtasn1 version 2.13 (pre-release). ** API and ABI modifications: gnutls_x509_crt_set_private_key_usage_period: Added gnutls_x509_crt_get_private_key_usage_period: Added gnutls_x509_crq_set_private_key_usage_period: Added gnutls_x509_crq_get_private_key_usage_period: Added gnutls_session_get_random: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.18.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.18.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From wilmer at gaast.net Sat Apr 7 14:46:09 2012 From: wilmer at gaast.net (Wilmer van der Gaast) Date: Sat, 07 Apr 2012 14:46:09 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data Message-ID: <4F803711.6040707@gaast.net> Hello, /* My ref: http://bugs.bitlbee.org/bitlbee/ticket/938 */ I seem to have a problem with GnuTLS 3.0.x, from what I can see this is a bug (but please correct me if I'm wrong). I have a function that receives data from a HTTPS server. This is all done with async and non-blocking I/O. Before returning from the read event handler, gnutls_record_check_pending() is called to check if there's any more unencrypted data waiting. When trying to query some servers (in this case MSN Messenger HTTPS servers), gnutls_record_check_pending() will return a non-0 number (goes all the way up to 8KB at times), but when I try to read this data I get -28 which seems to be GNUTLS_E_AGAIN. From what I know, that error code means "I would block but this is a non-blocking socket, so come back later". This seems to be a violation of what is promised in the manpage of gnutls_record_check_pending(): DESCRIPTION This function checks if there are unread data in the gnutls buffers. If the return value is non-zero the next call to gnutls_record_recv() is guarranteed not to block. Is this a known issue? Am I using it the wrong way/do I need to set a new flag from GnuTLS 3.x to get the behaviour I want? I could work around this by not even calling check_pending() if I was just returrned E_AGAIN because it seems that this condition fixes itself when more data comes in, but this seems like a risky assumption to me as well (and it doesn't work all the time, possibly): pending = 5792 gnutls_record_recv = -28 pending = 5792 gnutls_record_recv = -28 pending = 8688 gnutls_record_recv = -28 pending = 8688 ... gnutls_record_recv = -28 pending = 8688 gnutls_record_recv = 2048 pending = 8758 gnutls_record_recv = 2048 pending = 6710 gnutls_record_recv = 2048 pending = 4662 gnutls_record_recv = 2048 pending = 2614 gnutls_record_recv = 2048 pending = 566 gnutls_record_recv = 566 pending = 0 gnutls_record_recv = -9 In fact, looking at these numbers it's not really clear to me at all why I suddenly can read data even though the number of pending bytes didn't change, but I suppose that's because some control frame came in that didn't deliver any useful data for my stream. Cheers, Wilmer van der Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + From nmav at gnutls.org Sun Apr 8 13:55:03 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 08 Apr 2012 13:55:03 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data In-Reply-To: <4F803711.6040707@gaast.net> References: <4F803711.6040707@gaast.net> Message-ID: <4F817C97.8010501@gnutls.org> On 04/07/2012 02:46 PM, Wilmer van der Gaast wrote: > Hello, > > /* My ref: http://bugs.bitlbee.org/bitlbee/ticket/938 */ > > I seem to have a problem with GnuTLS 3.0.x, from what I can see this > is a bug (but please correct me if I'm wrong). I have a function that > receives data from a HTTPS server. This is all done with async and > non-blocking I/O. Before returning from the read event handler, > gnutls_record_check_pending() is called to check if there's any more > unencrypted data waiting. Correct. > When trying to query some servers (in this case MSN Messenger HTTPS > servers), gnutls_record_check_pending() will return a non-0 number > (goes all the way up to 8KB at times), but when I try to read this > data I get -28 which seems to be GNUTLS_E_AGAIN. > From what I know, that error code means "I would block but this is a > non-blocking socket, so come back later". Note that return value of gnutls_record_check_pending() is not the actual number of bytes to be received. Especially in the DTLS case it might be that no application data are available for reading. In that case, the call to record_recv() will not block but return eagain as you noticed. > This seems to be a violation of what is promised in the manpage of > gnutls_record_check_pending(): DESCRIPTION This function checks if > there are unread data in the gnutls buffers. If the return value is > non-zero the next call to gnutls_record_recv() is guarranteed not to > block. Since you received eagain, I think that the promise is kept, there was no blocking. However, this scenario should be improbable in normal TLS. I'd be interested to see the reason of the eagain. Could you provide debugging information of level 2 or more for your scenario? Is the version you are using 3.0.18? regards, Nikos From nmav at gnutls.org Mon Apr 9 13:34:09 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 09 Apr 2012 13:34:09 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data In-Reply-To: <4F82A06E.1090802@gaast.net> References: <4F803711.6040707@gaast.net> <4F817C97.8010501@gnutls.org> <4F82A06E.1090802@gaast.net> Message-ID: <4F82C931.4070106@gnutls.org> On 04/09/2012 10:40 AM, Wilmer van der Gaast wrote: >> Since you received eagain, I think that the promise is kept, there was >> no blocking. However, this scenario should be improbable in normal TLS. > Okay, so I did add one interpretation here, which makes sense for normal > Unix sockets but possibly not for TLS: I'm assuming that EAGAIN here > means that the operation would've blocked if I didn't make the socket > non-blocking. (IIRC EWOULDBLOCK is an alias for EAGAIN so it seems like > a reasonable assumption to me?) Hello Wilmer, By checking your log I believe you are right. I see that you receive a complete record packet split in many tcp segments and gnutls_record_check_pending() deceives you by including the incomplete packets to pending data. Would the attached patch solve the issue you notice? If it works for you it will be included in the next version. > So it looks like GnuTLS is indeed trying to read more data from the > socket even though we still have something buffered? Indeed this is not correct. The buffered data are not enough to form a complete record and thus it tries to read. The incomplete data shouldn't have been included there. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gnutls_record_check_pending-functionality-was-divide.patch Type: text/x-patch Size: 3785 bytes Desc: not available URL: From wilmer at gaast.net Mon Apr 9 10:40:14 2012 From: wilmer at gaast.net (Wilmer van der Gaast) Date: Mon, 09 Apr 2012 10:40:14 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data In-Reply-To: <4F817C97.8010501@gnutls.org> References: <4F803711.6040707@gaast.net> <4F817C97.8010501@gnutls.org> Message-ID: <4F82A06E.1090802@gaast.net> Hello Nikos, Thanks for your response. This is with GnuTLS 3.0.17 (currently available in Debian testing). I'm attaching logs from that version, and also logs generated with GnuTLS 2.12.18 which does not have this problem. On 08-04-12 13:55, Nikos Mavrogiannopoulos wrote: > > Since you received eagain, I think that the promise is kept, there was > no blocking. However, this scenario should be improbable in normal TLS. Okay, so I did add one interpretation here, which makes sense for normal Unix sockets but possibly not for TLS: I'm assuming that EAGAIN here means that the operation would've blocked if I didn't make the socket non-blocking. (IIRC EWOULDBLOCK is an alias for EAGAIN so it seems like a reasonable assumption to me?) To check my facts here I've run strace against my program: epoll_ctl(3, EPOLL_CTL_DEL, 12, {EPOLLIN, {u32=12, u64=12}}) = 0 recvfrom(12, 0xaf3070, 5045, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) So it looks like GnuTLS is indeed trying to read more data from the socket even though we still have something buffered? > I'd be interested to see the reason of the eagain. Could you provide > debugging information of level 2 or more for your scenario? Attached to this e-mail now. Hope it helps. The condition does seem to trigger some asserts at least. Thanks, Wilmer van der Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls.dbg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls-ok.dbg URL: From wilmer at gaast.net Tue Apr 10 00:40:11 2012 From: wilmer at gaast.net (Wilmer van der Gaast) Date: Tue, 10 Apr 2012 00:40:11 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data In-Reply-To: <4F82C931.4070106@gnutls.org> References: <4F803711.6040707@gaast.net> <4F817C97.8010501@gnutls.org> <4F82A06E.1090802@gaast.net> <4F82C931.4070106@gnutls.org> Message-ID: <4F83654B.1030405@gaast.net> Hello Nikos, On 09-04-12 13:34, Nikos Mavrogiannopoulos wrote: > By checking your log I believe you are right. I see that you receive > a complete record packet split in many tcp segments and > gnutls_record_check_pending() deceives you by including the incomplete > packets to pending data. Would the attached patch solve the issue you > notice? If it works for you it will be included in the next version. > Yes, this works better: 0x995d30 gnutls_record_recv = -28 0x995d30 gnutls_record_check_pending = 0 2 ASSERT: gnutls_buffers.c:510 2 ASSERT: gnutls_record.c:1000 2 ASSERT: gnutls_record.c:1202 0x995d30 gnutls_record_recv = -28 0x995d30 gnutls_record_check_pending = 0 0x995d30 gnutls_record_recv = 2048 0x995d30 gnutls_record_check_pending = 8770 0x995d30 gnutls_record_recv = 2048 0x995d30 gnutls_record_check_pending = 6722 0x995d30 gnutls_record_recv = 2048 I'm getting my data now, without ending up in an almost infinite loop. Thank you! Would you be able to tell me which versions of GnuTLS are affected by this by the way? I'm thinking of adding a work-around so BitlBee will still work properly with affected GnuTLS versions. Cheers, Wilmer van der Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + From nmav at gnutls.org Tue Apr 10 11:00:49 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 10 Apr 2012 11:00:49 +0200 Subject: gnutls_record_check_pending() returning non-0 but gnutls_record_recv() gives no data In-Reply-To: <4F83654B.1030405@gaast.net> References: <4F803711.6040707@gaast.net> <4F817C97.8010501@gnutls.org> <4F82A06E.1090802@gaast.net> <4F82C931.4070106@gnutls.org> <4F83654B.1030405@gaast.net> Message-ID: On Tue, Apr 10, 2012 at 12:40 AM, Wilmer van der Gaast wrote: > Yes, this works better: > 0x995d30 gnutls_record_recv = -28 > 0x995d30 gnutls_record_check_pending = 0 > 2 ASSERT: gnutls_buffers.c:510 > 2 ASSERT: gnutls_record.c:1000 > 2 ASSERT: gnutls_record.c:1202 > 0x995d30 gnutls_record_recv = -28 > 0x995d30 gnutls_record_check_pending = 0 > 0x995d30 gnutls_record_recv = 2048 > 0x995d30 gnutls_record_check_pending = 8770 > 0x995d30 gnutls_record_recv = 2048 > 0x995d30 gnutls_record_check_pending = 6722 > 0x995d30 gnutls_record_recv = 2048 > I'm getting my data now, without ending up in an almost infinite loop. Thank > you! > Would you be able to tell me which versions of GnuTLS are affected by this > by the way? I'm thinking of adding a work-around so BitlBee will still work > properly with affected GnuTLS versions. This "feature" was added in 3.0.13. regards, Nikos From Mallikarjun.Bailammanavar at infineon.com Tue Apr 17 10:54:48 2012 From: Mallikarjun.Bailammanavar at infineon.com (Mallikarjun.Bailammanavar at infineon.com) Date: Tue, 17 Apr 2012 08:54:48 +0000 Subject: Implementing a global callback method Message-ID: Hallo, I would like to implement one global callback method in GNU-TLS, which should be linked and exported via the DLL. I want to implement a method something similar to "gnutls_global_set_log_function". How can I achieve the same? Can some one please help. Thanks. Regards, Malik From simon at josefsson.org Tue Apr 17 14:16:43 2012 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 17 Apr 2012 14:16:43 +0200 Subject: Implementing a global callback method In-Reply-To: (Mallikarjun Bailammanavar's message of "Tue, 17 Apr 2012 08:54:48 +0000") References: Message-ID: <87pqb6eeok.fsf@latte.josefsson.org> writes: > Hallo, > > > I would like to implement one global callback method in GNU-TLS, which > should be linked and exported via the DLL. > > I want to implement a method something similar to > "gnutls_global_set_log_function". > > How can I achieve the same? > Can some one please help. 1) Add the prototype to the appropriate header file, e.g. lib/includes/gnutls/gnutls.h.in 2) Write the code in some existing .c file under lib/, or add a new .c file under lib/ and add it in the Makefile.am. 3) mention the function in the symbol file lib/libgnutls.map. 4) write self tests 5) write documentation See more in the manual: https://www.gnu.org/software/gnutls/manual/html_node/TLS-Extension-Handling.html#Add-API-functions-to-enable_002fdisable-the-extension_002e /Simon From aedelatorre at gmail.com Sat Apr 21 04:00:29 2012 From: aedelatorre at gmail.com (Alfredo Esteban) Date: Sat, 21 Apr 2012 04:00:29 +0200 Subject: Load pkcs12 file using gnutls Message-ID: Hi, Is there a way to load a pkcs12 file using certtool? I read the manual and found the --p12info option but I didn't find an example or a description of that flag syntax. I'm looking for something similar to: openssl pkcs12 -noout -passin pass:mypassword -in myfilename.p12 Thanks in advance, Alfredo From nmav at gnutls.org Sat Apr 21 15:46:13 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Apr 2012 15:46:13 +0200 Subject: Load pkcs12 file using gnutls In-Reply-To: References: Message-ID: <4F92BA25.2070008@gnutls.org> On 04/21/2012 04:00 AM, Alfredo Esteban wrote: > Hi, > > Is there a way to load a pkcs12 file using certtool? I read the manual > and found the --p12info option but I didn't find an example or a > description of that flag syntax. certtool --p12-info --infile myfile regards, Nikos From aedelatorre at gmail.com Sat Apr 21 17:06:25 2012 From: aedelatorre at gmail.com (Alfredo Esteban) Date: Sat, 21 Apr 2012 17:06:25 +0200 Subject: Load pkcs12 file using gnutls In-Reply-To: <4F92BA25.2070008@gnutls.org> References: <4F92BA25.2070008@gnutls.org> Message-ID: Thank for your help. The problem is that certtool expects a file in base64 format (p12_import function code and messages are clear): > certtool --p12-info cert.p12 certtool: p12_import: Base64 unexpected header error. Simple conversion doesn't work either: > cat cert.p12 | base64 | certtool --p12-info certtool: p12_import: Base64 unexpected header error. This is not the case when exporting a certificate from a browser (Firefox for example) because I think PKCS#12 is a binary format so I don't know how to use certtool. Regards, Alfredo 2012/4/21 Nikos Mavrogiannopoulos : > On 04/21/2012 04:00 AM, Alfredo Esteban wrote: > >> Hi, >> >> Is there a way to load a pkcs12 file using certtool? I read the manual >> and found the --p12info option but I didn't find an example or a >> description of that flag syntax. > > > certtool --p12-info --infile myfile > > > regards, > Nikos From nmav at gnutls.org Sat Apr 21 17:31:19 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Apr 2012 17:31:19 +0200 Subject: Load pkcs12 file using gnutls In-Reply-To: References: <4F92BA25.2070008@gnutls.org> Message-ID: <4F92D2C7.6020200@gnutls.org> On 04/21/2012 05:06 PM, Alfredo Esteban wrote: > Thank for your help. > > The problem is that certtool expects a file in base64 format > (p12_import function code and messages are clear): > >> certtool --p12-info cert.p12 > certtool: p12_import: Base64 unexpected header error. There is the --inder option to import from DER format. regards, Nikos From aedelatorre at gmail.com Sat Apr 21 17:54:11 2012 From: aedelatorre at gmail.com (Alfredo Esteban) Date: Sat, 21 Apr 2012 17:54:11 +0200 Subject: Load pkcs12 file using gnutls In-Reply-To: <4F92D2C7.6020200@gnutls.org> References: <4F92BA25.2070008@gnutls.org> <4F92D2C7.6020200@gnutls.org> Message-ID: Thanks a lot. It works: certtool --p12-info --inder --infile cert.p12 Regards, Alfredo 2012/4/21 Nikos Mavrogiannopoulos : > On 04/21/2012 05:06 PM, Alfredo Esteban wrote: > >> Thank for your help. >> >> The problem is that certtool expects a file in base64 format >> (p12_import function code and messages are clear): >> >>> certtool --p12-info cert.p12 >> certtool: p12_import: Base64 unexpected header error. > > There is the --inder option to import from DER format. > > > regards, > Nikos From aedelatorre at gmail.com Sun Apr 22 01:42:38 2012 From: aedelatorre at gmail.com (Alfredo Esteban) Date: Sun, 22 Apr 2012 01:42:38 +0200 Subject: Compiling gnutls example in Ubuntu 11.10 64 bits Message-ID: I'trying to compile a very simple program to load a pkcs12 file using gnutls. libgnutls26 is found by ld (no "not found error") but not symbols. > gcc -lgnutls ejemplo.c /tmp/ccKyg1zu.o: In function `main': ejemplo.c:(.text+0x149): undefined reference to `gnutls_global_init' ejemplo.c:(.text+0x15c): undefined reference to `gnutls_strerror' ejemplo.c:(.text+0x182): undefined reference to `gnutls_global_init_extra' ejemplo.c:(.text+0x195): undefined reference to `gnutls_strerror' ejemplo.c:(.text+0x1bd): undefined reference to `gnutls_pkcs12_init' ejemplo.c:(.text+0x1d0): undefined reference to `gnutls_strerror' ejemplo.c:(.text+0x25d): undefined reference to `gnutls_pkcs12_import' ejemplo.c:(.text+0x29c): undefined reference to `gnutls_pkcs12_verify_mac' collect2: ld devolvi? el estado de salida 1 [00:47:32] [alfredo at portatil] ~/gnutls-crackpkcs12/ejemplo > dpkg -l | grep gnutls ii libcurl3-gnutls 7.21.6-3ubuntu3.2 Multi-protocol file transfer library (GnuTLS) ii libgnutls-dev 2.10.5-1ubuntu3.1 the GNU TLS library - development files ii libgnutls26 2.10.5-1ubuntu3.1 the GNU TLS library - runtime library ii libgnutls26:i386 2.10.5-1ubuntu3.1 the GNU TLS library - runtime library ii libgnutlsxx26 2.10.5-1ubuntu3.1 the GNU TLS library - C++ runtime library ii libneon27-gnutls 0.29.6-1 HTTP and WebDAV client library (GnuTLS enabled) > more /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=11.10 DISTRIB_CODENAME=oneiric DISTRIB_DESCRIPTION="Ubuntu 11.10" > uname -a Linux portatil 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Thanks in advance, Alfredo From nmav at gnutls.org Sun Apr 22 17:21:22 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Apr 2012 17:21:22 +0200 Subject: gnutls 3.0.19 Message-ID: <4F9421F2.3060106@gnutls.org> Hello, I've just released gnutls 3.0.19. This is a bug-fix release on the current stable branch. * Version 3.0.19 (released 2012-04-22) ** libgnutls: When decoding a PKCS #11 URL the pin-source field is assumed to be a file that stores the pin. Based on patch by David Smith. ** libgnutls: gnutls_record_check_pending() no longer returns unprocessed data, and thus ensure the non-blocking of the next call to gnutls_record_recv(). ** libgnutls: Added strict tests in Diffie-Hellman and SRP key exchange public keys. ** libgnutls: in ECDSA and DSA TLS 1.2 authentication be less strict in hash selection, and allow a stronger hash to be used than the appropriate, to improve interoperability with openssl. ** tests: Disabled floating point test, and corrections in pkcs12 decoding tests. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.19.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.19.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From jim at silvertailsystems.com Wed Apr 25 02:37:42 2012 From: jim at silvertailsystems.com (Jim Lloyd) Date: Tue, 24 Apr 2012 17:37:42 -0700 Subject: Obtaining the raw RSA parameters from a PKCS11 private key Message-ID: Question: Is there a way to obtain the raw RSA parameters from a PKCS11 private key? Background: I'm attempting to update an existing packet sniffing application to be able to load certs/keys via pkcs11. The application was previously written using gnutls 2.8.5 and gcrypt 1.4.4. I want to upgrade gnutls to 2.12.x and am currently developing with 2.12.18. I'd like to continue to use libgrcypt since the application currently uses gcrypt APIs for the cryptographic operations. I have been able to install 2.12.x, build my app, run our unit tests, etc. Now I am attempting to add the pkcs11 support. We are testing with an Thales nCipher netHSM device. I can use p11tool to query the device and install objects (certs, keys). I am now working on the new logic to load a private key via pkcs11 so that I can obtain the cryptographic parameters. I can load the key just fine into a gnutls_privkey_t. But I see no way to then extract the cryptographic parameters, as we have previously done with gnutls_x509_privkey_export_rsa_raw. I see in the documentation this note: *"An abstract gnutls_privkey_t can be initialized using the functions below. It can be imported through an existing structure like gnutls_x509_privkey_t, but unlike public keys it cannot be exported. That is to allow abstraction over PKCS #11 keys that are not extractable."* What then is the way for packet sniffing applications to use gnutls with certs/keys stored on HSMs? Am I forced to use gnutls_pubkey_encrypt_data and gnutls_privkey_decrypt_data with keys loaded from HSMs? What happens under the hood with these APIs? Thanks, Jim Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Apr 25 09:36:29 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Apr 2012 09:36:29 +0200 Subject: Obtaining the raw RSA parameters from a PKCS11 private key In-Reply-To: References: Message-ID: <4F97A97D.3060801@gnutls.org> On 04/25/2012 02:37 AM, Jim Lloyd wrote: > Question: Is there a way to obtain the raw RSA parameters from a PKCS11 > private key? The typical use case of PKCS #11 is to store keys there so that no-one is able to extract the keys (e.g. if someone breaks into your web-server he will not extract the keys). May I ask your use case? Some devices do not allow exporting keys at all, but on some you can mark them as exportable during their installation or generation. If your keys are marked as exportable you can use gnutls_pkcs11_obj_export() and then import it as an x509 private key. > What then is the way for packet sniffing applications to use gnutls with > certs/keys stored on HSMs? Am I forced to use gnutls_pubkey_encrypt_data > and gnutls_privkey_decrypt_data with keys loaded from HSMs? What happens > under the hood with these APIs? The idea is to use the pubkey_encrypt() and privkey_decrypt() and let the hardware perform the operations for you. regards, Nikos From jnewell at newells.info Thu Apr 26 20:37:27 2012 From: jnewell at newells.info (James Newell) Date: Thu, 26 Apr 2012 14:37:27 -0400 Subject: gnutls suite b interoperability with a mocana server Message-ID: Hello, I'm attempting to use gntls client with a mocana ssl server. The gnutls-cli fails indicating it could not negotiate a cipher suite, despite the mocana sending back the cipher selected in the server hello packet chosen from the client cipher list. I've provide both debug output from the server and client below. Is it possible I configured something incorrectly on the gnutls side? Any help is appreciated. Regards, Jim $ ./build/gnutls-3.0.19/src/gnutls-cli --list|grep ECD TLS_ECDH_ANON_NULL_SHA1 ? ? ? ? ? ? ? ? ? ? ? ? ?? 0xc0, 0x15 TLS1.0 TLS_ECDH_ANON_3DES_EDE_CBC_SHA1 ? ? ? ? ? ? ? ? ?? 0xc0, 0x17 TLS1.0 TLS_ECDH_ANON_AES_128_CBC_SHA1 ? ? ? ? ? ? ? ? ? ? 0xc0, 0x18 TLS1.0 TLS_ECDH_ANON_AES_256_CBC_SHA1 ? ? ? ? ? ? ? ? ? ? 0xc0, 0x19 TLS1.0 TLS_ECDHE_RSA_NULL_SHA1 ? ? ? ? ? ? ? ? ? ? ? ? ?? 0xc0, 0x10 TLS1.0 TLS_ECDHE_RSA_3DES_EDE_CBC_SHA1 ? ? ? ? ? ? ? ? ?? 0xc0, 0x12 TLS1.0 TLS_ECDHE_RSA_AES_128_CBC_SHA1 ? ? ? ? ? ? ? ? ? ? 0xc0, 0x13 TLS1.0 TLS_ECDHE_RSA_AES_256_CBC_SHA1 ? ? ? ? ? ? ? ? ? ? 0xc0, 0x14 TLS1.0 TLS_ECDHE_ECDSA_NULL_SHA1 ? ? ? ? ? ? ? ? ? ? ? ?? 0xc0, 0x06 TLS1.0 TLS_ECDHE_ECDSA_3DES_EDE_CBC_SHA1 ? ? ? ? ? ? ? ?? 0xc0, 0x08 TLS1.0 TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 ? ? ? ? ? ? ? ? ? 0xc0, 0x09 TLS1.0 ./build/gnutls-3.0.19/src/gnutls-cli -d 10 192.168.1.130 -p 2300 Resolving '192.168.1.130'... Connecting to '192.168.1.130:2300'... |<4>| REC[0x14fc5f0]: Allocating epoch #0 |<2>| ASSERT: gnutls_constate.c:717 |<4>| REC[0x14fc5f0]: Allocating epoch #1 |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 (00.40) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 (00.A2) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05) |<3>| HSK[0x14fc5f0]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04) |<3>| EXT[0x14fc5f0]: Sending extension SAFE RENEGOTIATION (1 bytes) |<3>| EXT[0x14fc5f0]: Sending extension SUPPORTED ECC (12 bytes) |<3>| EXT[0x14fc5f0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) |<3>| EXT[0x14fc5f0]: sent signature algo (4.1) RSA-SHA256 |<3>| EXT[0x14fc5f0]: sent signature algo (4.2) DSA-SHA256 |<3>| EXT[0x14fc5f0]: sent signature algo (4.3) ECDSA-SHA256 |<3>| EXT[0x14fc5f0]: sent signature algo (5.1) RSA-SHA384 |<3>| EXT[0x14fc5f0]: sent signature algo (5.3) ECDSA-SHA384 |<3>| EXT[0x14fc5f0]: sent signature algo (6.1) RSA-SHA512 |<3>| EXT[0x14fc5f0]: sent signature algo (6.3) ECDSA-SHA512 |<3>| EXT[0x14fc5f0]: sent signature algo (3.1) RSA-SHA224 |<3>| EXT[0x14fc5f0]: sent signature algo (3.2) DSA-SHA224 |<3>| EXT[0x14fc5f0]: sent signature algo (3.3) ECDSA-SHA224 |<3>| EXT[0x14fc5f0]: sent signature algo (2.1) RSA-SHA1 |<3>| EXT[0x14fc5f0]: sent signature algo (2.2) DSA-SHA1 |<3>| EXT[0x14fc5f0]: sent signature algo (2.3) ECDSA-SHA1 |<3>| EXT[0x14fc5f0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) |<3>| HSK[0x14fc5f0]: CLIENT HELLO was queued [184 bytes] |<7>| HWRITE: enqueued [CLIENT HELLO] 184. Total 184 bytes. |<7>| HWRITE FLUSH: 184 bytes in buffer. |<4>| REC[0x14fc5f0]: Preparing Packet Handshake(22) with length: 184 |<9>| ENC[0x14fc5f0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 189 bytes for 0x4. Total 189 bytes. |<4>| REC[0x14fc5f0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 189 |<7>| HWRITE: wrote 1 bytes, 0 bytes left. |<7>| WRITE FLUSH: 189 bytes in buffer. |<7>| WRITE: wrote 189 bytes, 0 bytes left. |<2>| ASSERT: gnutls_buffers.c:974 |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x14fc5f0]: SSL 3.0 Handshake packet received. Epoch 0, length: 46 |<4>| REC[0x14fc5f0]: Expected Packet Handshake(22) |<4>| REC[0x14fc5f0]: Received Packet Handshake(22) with length: 46 |<7>| READ: Got 46 bytes from 0x4 |<7>| READ: read 46 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 46 bytes. |<7>| RB: Requested 51 bytes |<4>| REC[0x14fc5f0]: Decrypted Packet[0] Handshake(22) with length: 46 |<6>| BUF[REC]: Inserted 46 bytes of Data(22) |<3>| HSK[0x14fc5f0]: SERVER HELLO was received. Length 42[42], frag offset 0, frag length: 42, sequence: 0 |<3>| HSK[0x14fc5f0]: Server's version: 3.0 |<3>| HSK[0x14fc5f0]: SessionID length: 4 |<3>| HSK[0x14fc5f0]: SessionID: 05000000 |<2>| ASSERT: gnutls_handshake.c:1385 |<3>| HSK[0x14fc5f0]: unsupported cipher suite C0.09 |<2>| ASSERT: gnutls_handshake.c:1618 |<2>| ASSERT: gnutls_handshake.c:2058 |<2>| ASSERT: gnutls_handshake.c:1293 |<2>| ASSERT: gnutls_handshake.c:2484 *** Fatal error: Could not negotiate a supported cipher suite. |<4>| REC: Sending Alert[2|40] - Handshake failed |<4>| REC[0x14fc5f0]: Preparing Packet Alert(21) with length: 2 |<9>| ENC[0x14fc5f0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes. |<7>| WRITE FLUSH: 7 bytes in buffer. |<7>| WRITE: wrote 7 bytes, 0 bytes left. |<4>| REC[0x14fc5f0]: Sent Packet[2] Alert(21) in epoch 0 and length: 7 *** Handshake has failed GnuTLS error: Could not negotiate a supported cipher suite. |<4>| REC[0x14fc5f0]: Start of epoch cleanup |<4>| REC[0x14fc5f0]: End of epoch cleanup |<4>| REC[0x14fc5f0]: Epoch #0 freed |<4>| REC[0x14fc5f0]: Epoch #1 freed The deug output from the Mocana server indicates it selected 0xc009 from the list the client sent. 11:48:38.1:20644:NetworkService.cpp:274:I:session[7FBCBC002C40,192.168.1.130:38889]:session created(fd=16) Client Hello Ciphers (v3): CipherSuite = 0xc009 CipherSuite = 0xc023 CipherSuite = 0xc02b CipherSuite = 0xc00a CipherSuite = 0xc024 CipherSuite = 0xc02c CipherSuite = 0xc008 CipherSuite = 0xc013 CipherSuite = 0xc027 CipherSuite = 0xc02f CipherSuite = 0xc014 CipherSuite = 0xc030 CipherSuite = 0xc012 CipherSuite = 0x0033 CipherSuite = 0x0067 CipherSuite = 0x0045 CipherSuite = 0x009e CipherSuite = 0x0039 CipherSuite = 0x006b CipherSuite = 0x0088 CipherSuite = 0x0016 CipherSuite = 0x0032 CipherSuite = 0x0040 CipherSuite = 0x0044 CipherSuite = 0x00a2 CipherSuite = 0x0038 CipherSuite = 0x006a CipherSuite = 0x0087 CipherSuite = 0x0013 CipherSuite = 0x0066 CipherSuite = 0x002f CipherSuite = 0x003c CipherSuite = 0x0041 CipherSuite = 0x009c CipherSuite = 0x0035 CipherSuite = 0x003d CipherSuite = 0x0084 CipherSuite = 0x000a CipherSuite = 0x0005 CipherSuite = 0x0004 SSLSOCK_selectCipherSuiteV3: CipherSuite selected = 0xc009 Handshake length = 184 (SERVER) Client Hello 01 00 00 b4 03 03 4f 99 6e 56 1f 43 59 9f b2 45 b4 f8 57 34 8b 63 5f 5f 38 46 d1 ec e3 6c 06 ff 65 f9 21 c3 d7 1e 00 00 50 c0 09 c0 23 c0 2b c0 0a c0 24 c0 2c c0 08 c0 13 c0 27 c0 2f c0 14 c0 30 c0 12 00 33 00 67 00 45 00 9e 00 39 00 6b 00 88 00 16 00 32 00 40 00 44 00 a2 00 38 00 6a 00 87 00 13 00 66 00 2f 00 3c 00 41 00 9c 00 35 00 3d 00 84 00 0a 00 05 00 04 01 00 00 3b ff 01 00 01 00 00 0a 00 0c 00 0a 00 13 00 15 00 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 1c 00 1a 04 01 04 02 04 03 05 01 05 03 06 01 06 03 03 01 03 02 03 03 02 01 02 02 02 03 Resume state = 0. Handshake length = 46 (SERVER) Server hello 02 00 00 2a 03 00 c3 95 e3 a0 37 a8 08 72 04 22 13 c6 61 76 5f f0 a4 dd 69 9d 58 1b 6e f1 e7 b4 7a a4 94 12 19 3b 04 05 00 00 00 c0 09 00 ^------------- The server hello sent back indicating the cipher suite. Handshake length = 293 (SERVER) Certificate 0b 00 01 21 00 01 1e 00 01 1b 30 82 01 17 30 81 bf a0 03 02 01 02 02 14 11 3b bb 29 fa fd 88 a7 be da e4 8c 6f 43 22 d8 d1 9a 01 bb 30 09 06 07 2a 86 48 ce 3d 04 01 30 0d 31 0b 30 09 06 03 55 04 06 13 02 55 53 30 1e 17 0d 30 33 30 35 32 36 30 30 30 31 32 36 5a 17 0d 33 33 30 35 32 34 32 33 30 31 32 36 5a 30 0d 31 0b 30 09 06 03 55 04 06 13 02 55 53 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 86 48 ce 3d 03 01 07 03 42 00 04 9f 3a 81 33 3a 5b 7f 44 ed dd f2 ea b1 89 4e cd 0a 26 b4 0f b3 02 a4 6e 39 9e 33 05 8e ec 55 cd 6b 74 e9 b6 9e 39 89 52 b3 be f0 d4 c5 4a 33 b7 be de 81 3e 35 e5 a9 66 e0 be 6a f1 05 79 3b 47 30 09 06 07 2a 86 48 ce 3d 04 01 03 48 00 30 45 02 20 51 09 e8 bd 4d 3e b1 b3 64 3a 74 60 f6 89 37 98 1e 17 96 5e 53 78 7d 47 c0 ca 20 17 68 9e 13 5c 02 21 00 ba af 8c 7c dc d3 5b d5 00 70 31 30 3b f1 f8 74 88 63 e9 21 5d 26 fe b4 70 90 27 ef 95 c5 56 53 Handshake length = 147 (SERVER) Server Key Exchange 0c 00 00 8f 03 00 17 41 04 5c 78 ce a4 ea 82 e9 b4 4e 3f 6f 9a 4f dc ac e4 13 2b a0 75 93 be f2 ba 52 23 d3 02 52 4c e5 55 f1 45 e9 f9 c7 09 29 57 75 00 21 70 80 9c b3 9a d2 09 25 8d d8 f1 f1 eb aa 03 31 db e1 fe 9f 6d 00 48 30 46 02 21 00 f7 80 e4 29 80 d4 0c 12 44 de f7 34 2e 65 cb ae 47 bb 28 87 ea 95 6b 8d fc 3f 9b 79 78 2b ce 19 02 21 00 b7 e0 ea 73 2a a3 73 3e 9f 50 cb 3c 98 0f 7b 45 26 4a 81 f9 60 4e 3d 2b a2 61 89 28 76 0b ed 25 Handshake length = 4 (SERVER) Server Hello done 0e 00 00 00 From nmav at gnutls.org Thu Apr 26 23:17:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 Apr 2012 23:17:07 +0200 Subject: gnutls suite b interoperability with a mocana server In-Reply-To: References: Message-ID: <4F99BB53.1080703@gnutls.org> On 04/26/2012 08:37 PM, James Newell wrote: > Hello, > > I'm attempting to use gntls client with a mocana ssl server. The > gnutls-cli fails indicating it could not negotiate a cipher suite, > despite the mocana sending back the cipher selected in the server > hello packet chosen from the client cipher list. I've provide both > debug output from the server and client below. Is it possible I > configured something incorrectly on the gnutls side? Any help is > appreciated. Interesting issue. The key is: > |<3>| HSK[0x14fc5f0]: Server's version: 3.0 > |<3>| HSK[0x14fc5f0]: unsupported cipher suite C0.09 Your server negotiates SSL 3.0 with an elliptic curve ciphersuite. Those are defined with TLS 1.0 or later. Is there an option to enable TLS 1.0 on your server? regards, Nikos From jnewell at newells.info Fri Apr 27 03:42:49 2012 From: jnewell at newells.info (James Newell) Date: Thu, 26 Apr 2012 21:42:49 -0400 Subject: gnutls suite b interoperability with a mocana server In-Reply-To: <4F99BB53.1080703@gnutls.org> References: <4F99BB53.1080703@gnutls.org> Message-ID: On Thu, Apr 26, 2012 at 5:17 PM, Nikos Mavrogiannopoulos wrote: > On 04/26/2012 08:37 PM, James Newell wrote: > >> Hello, >> >> I'm attempting to use gntls client with a mocana ssl server. ?The >> gnutls-cli fails indicating it could not negotiate a cipher suite, >> despite the mocana sending back the cipher selected in the server >> hello packet chosen from the client cipher list. ?I've provide both >> debug output from the server and client below. ?Is it possible I >> configured something incorrectly on the gnutls side? ?Any help is >> appreciated. > > > Interesting issue. The key is: > >> |<3>| HSK[0x14fc5f0]: Server's version: 3.0 >> |<3>| HSK[0x14fc5f0]: unsupported cipher suite C0.09 > > > Your server negotiates SSL 3.0 with an elliptic curve ciphersuite. Those > are defined with TLS 1.0 or later. Is there an option to > enable TLS 1.0 on your server? I did not find an option to explicitly enable TLS 1.0 on the server, but since I had the code I tracked it down to the server code setting it's ssl minor version based on the announced minor version of the client, therefore sending 3.0 back to the gnutls-cli client. I modified this to return 1, and now the gnutls-cli connects correctly. Should a server be sending it's SSL version based on the clients version? I'm not well versed in the tls spec. I'll have to do some reading. Thank you for you help. Regards, Jim > > regards, > Nikos > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls From nmav at gnutls.org Fri Apr 27 19:46:05 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 27 Apr 2012 19:46:05 +0200 Subject: gnutls suite b interoperability with a mocana server In-Reply-To: References: <4F99BB53.1080703@gnutls.org> Message-ID: On Fri, Apr 27, 2012 at 3:42 AM, James Newell wrote: > I did not find an option to explicitly enable TLS 1.0 on the server, > but since I had the code I tracked it down to the server code setting > it's ssl minor version based on the announced minor version of the > client, therefore sending 3.0 back to the gnutls-cli client. Strange. Gnutls by default advertises TLS 1.2. Could it be that the server incorrectly checks the version in the record header and not the client hello[0]? regards, Nikos [0]. If I remember well a very old openssl version used to have this bug.