From frank.krout at eurorscg.com Tue Nov 1 19:51:55 2011 From: frank.krout at eurorscg.com (frank.krout at eurorscg.com) Date: Tue, 1 Nov 2011 14:51:55 -0400 Subject: handshake issue with gnutls 3.0.3 Message-ID: Anyone run into this. I'm new to GNUTLS and having an issue in multi-threaded app. Via application mutex's, I've serialized access to GNUTLS_HANDSHAKE in order just to get a successful handshake... and am getting this: ==> backtrace() returned 18 addresses ------------------------------------------- ../Linux/MassMailer [0x80021b86] [0x3ffffb612a8] /lib64/libpthread.so.0(__pthread_mutex_lock+0x22) [0x200001dc71e] /home/fkrout/usr/lib/libgnutls.so.28 [0x2000006ff2e] /home/fkrout/usr/lib/libgnutls.so.28 [0x200000f61b4] /home/fkrout/usr/lib/libgnutls.so.28(_gnutls_tls_create_random+0x46) [0x20000054972] /home/fkrout/usr/lib/libgnutls.so.28(_gnutls_send_hello+0x4e4) [0x2000005864c] /home/fkrout/usr/lib/libgnutls.so.28(_gnutls_handshake_client+0x2ca) [0x20000059422] /home/fkrout/usr/lib/libgnutls.so.28(gnutls_handshake+0xee) [0x2000005990a] ../Linux/MassMailer(_ZN12CUT_WSClient19do_handshake_gnutlsEv+0x104) [0x8006b1dc] ../Linux/MassMailer(_ZN8SMTPconn11SMTPConnectEPKcS1_S1_+0x5ba) [0x80065af2] ../Linux/MassMailer(_Z23SendAnEmailNotificationPcS_S_S_+0x95e) [0x80067466] ../Linux/MassMailer(SendAnEmailToFromAdr+0xe0) [0x800981a8] ../Linux/MassMailer [0x80085f12] ../Linux/MassMailer(_Z19alloCATEgorize_mainlPPc+0x1da) [0x80089c4e] ../Linux/MassMailer(main+0x2824) [0x80076130] /lib64/libc.so.6(__libc_start_main+0x100) [0x200003ea568] ../Linux/MassMailer(__res_query+0x5e) [0x80016d62] Info: Initializing GNUTLS The gnutls-cli app runs fine, built in same environment and does not use gnutls_global_set_mutex. Since it does work, I've modeled my code largely after ( src/cli.c ), not using set_mutex either. I realize it's a single thread, that is why I serialized the handshake in my app. So the random function works fine for gnutls-cli, I don't get what's going on. Hoping this is "low hanging fruit" for the community.... otherwise I just have a wild pointer somewhere... I've read through the docs and mailing list, so unless I missed something... Thanks.. Frank Krout Senior Software Engineer Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 Tel 203.563.3314 Fax 203.563.3434 Web eurorscg.com ???? ________________________________________________________________________________ ____________________________________ The views and opinions expressed in this e-mail and any accompanying attachment, are those of the author and do not necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. To learn more about Euro RSCG, please visit our website at www.eurorscg.com Please consider the environment before printing this email. ________________________________________________________________________________ _____________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1491 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1131 bytes Desc: not available URL: From nmav at gnutls.org Wed Nov 2 09:30:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 02 Nov 2011 09:30:12 +0100 Subject: handshake issue with gnutls 3.0.3 In-Reply-To: References: Message-ID: <4EB0FF94.5030506@gnutls.org> On 11/01/2011 07:51 PM, frank.krout at eurorscg.com wrote: > Anyone run into this. I'm new to GNUTLS and having an issue in > multi-threaded app. > > Via application mutex's, I've serialized access to GNUTLS_HANDSHAKE in > order just to get a successful handshake... and am getting this: [...] > The gnutls-cli app runs fine, built in same environment and does not use > gnutls_global_set_mutex. > Since it does work, I've modeled my code largely after ( src/cli.c ), not > using set_mutex either. > I realize it's a single thread, that is why I serialized the handshake in > my app. > So the random function works fine for gnutls-cli, I don't get what's going > on. I don't quite understand your issue. Do the implicit locks (pthread) work for you, but when you use gnutls_global_set_mutex() you get a crash? regards, Nikos From fabrice.gautier at gmail.com Fri Nov 4 01:59:30 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 3 Nov 2011 17:59:30 -0700 Subject: NULL cipher suites broken in gnutls 3.0.5 ? Message-ID: Hi, I get decryption error when using NULL-MD5 or NULL-SHA1 cipher suites when using gnutls-serv, and connecting with a openssl client. Server is started that way: $ gnutls-serv --http --x509cafile x509-ca.pem --x509keyfile x509-server-key.pem --x509certfile x509-server.pem --priority "NORMAL:+ANON-DH:+NULL" The openssl s_client is started that way: $ openssl s_client -cipher NULL-SHA -connect localhost:5556 This is what I get from the gnutls logs: * Accepted connection from IPv4 127.0.0.1 port 53650 on Thu Nov 3 17:23:51 2011 * Successful handshake from IPv4 127.0.0.1 port 53650 - Session ID: 26:C8:6A:7B:CE:F2:99:0B:19:1F:90:90:D8:58:73:60:99:BF:8D:DE:1B:7B:77:A2:80:54:65:11:D0:A8:5F:94 - Certificate type: X.509 - Could not verify certificate (err: The peer did not send any certificate.) - Version: TLS1.0 - Key Exchange: RSA - Cipher: NULL - MAC: SHA1 - Compression: NULL Error while receiving data >From the openssl side I get an error as well: 140735311722940:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:479: I believe it worked fine when I was using gnutls-2.12. I used both openssl 0.9.8r and 1.0.0e for the client side. Any known issue there ? -- Fabrice From fabrice.gautier at gmail.com Fri Nov 4 02:47:21 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 3 Nov 2011 18:47:21 -0700 Subject: NULL cipher suites broken in gnutls 3.0.5 ? In-Reply-To: References: Message-ID: I also verified this against gnutls-2.12.11, as both client and server: When using NULL cipher suites: - The 3.0.5 client cannot talk to the 2.12.11 server - The 2.12.11 client cannot talk to 3.0.5 server. -- Fabrice On Thu, Nov 3, 2011 at 5:59 PM, Fabrice Gautier wrote: > Hi, > > I get decryption error when using NULL-MD5 or NULL-SHA1 cipher suites > when using gnutls-serv, and connecting with a openssl client. > > Server is started that way: > > $ gnutls-serv --http --x509cafile x509-ca.pem --x509keyfile > x509-server-key.pem --x509certfile x509-server.pem ?--priority > "NORMAL:+ANON-DH:+NULL" > > The openssl s_client is started that way: > > $ openssl s_client -cipher NULL-SHA -connect localhost:5556 > > > This is what I get from the gnutls logs: > > > * Accepted connection from IPv4 127.0.0.1 port 53650 on Thu Nov ?3 17:23:51 2011 > > * Successful handshake from IPv4 127.0.0.1 port 53650 > - Session ID: 26:C8:6A:7B:CE:F2:99:0B:19:1F:90:90:D8:58:73:60:99:BF:8D:DE:1B:7B:77:A2:80:54:65:11:D0:A8:5F:94 > - Certificate type: X.509 > - Could not verify certificate (err: The peer did not send any certificate.) > - Version: TLS1.0 > - Key Exchange: RSA > - Cipher: NULL > - MAC: SHA1 > - Compression: NULL > Error while receiving data > > > > From the openssl side I get an error as well: > > 140735311722940:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption > failed or bad record mac:s3_pkt.c:479: > > > I believe it worked fine when I was using gnutls-2.12. I used both > openssl 0.9.8r and 1.0.0e for the client side. > > > Any known issue there ? > > -- Fabrice > From nmav at gnutls.org Fri Nov 4 19:57:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2011 19:57:12 +0100 Subject: NULL cipher suites broken in gnutls 3.0.5 ? In-Reply-To: References: Message-ID: <4EB43588.70704@gnutls.org> On 11/04/2011 01:59 AM, Fabrice Gautier wrote: > Hi, > I get decryption error when using NULL-MD5 or NULL-SHA1 cipher suites > when using gnutls-serv, and connecting with a openssl client. Hello, Thanks for reporting that. It seems the AEAD ciphers addition has broken the NULL cipher. I've committed a fix in the repository. regards, Nikos From fabrice.gautier at gmail.com Sat Nov 5 00:46:29 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Fri, 4 Nov 2011 16:46:29 -0700 Subject: EC keys interoperability issue between openSSL and GnuTLS ? Message-ID: Hi, I generated some EC keys and cert using openssl, and when I try to use them with gnutls_serv, it seems that gnutls_serv will just crash. It also seems that I can properly read them using gnutls certtool. This is how I generated ServerKey.ecc.pem with openSSL: $ openssl ecparam -name secp256r1 -out ecparam.pem $ openssl req -new -nodes -days 365 -subj '/CN=SecurityTests Server Cert (ECC)' -newkey ec:ecparam.pem -keyout ServerKey.ecc.pem -out ServerReq.ecc.pem Using certtool I get: $ /usr/local/bin/certtool -k --infile test-certs/ServerKey.ecc.pem Public Key Info: Public Key Algorithm: ECC Key Security Level: Unknown Error in key ECC data export: The request is invalid. Error in key id calculation: ASN1 parser: Generic parsing error. /usr/local/bin/certtool: export error: ASN1 parser: Element was not found. When using that key with gnutls_serv, it seems that it just crashes without any warning message (when I try to connect using an EC cipher suite) Note that if I generated the keys using certtool then it seems to be fine. -- Fabrice From ludo at gnu.org Sat Nov 5 01:02:35 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sat, 05 Nov 2011 01:02:35 +0100 Subject: NULL cipher suites broken in gnutls 3.0.5 ? References: <4EB43588.70704@gnutls.org> Message-ID: <877h3f77xg.fsf@gnu.org> Hello, Nikos Mavrogiannopoulos skribis: > On 11/04/2011 01:59 AM, Fabrice Gautier wrote: >> Hi, >> I get decryption error when using NULL-MD5 or NULL-SHA1 cipher suites >> when using gnutls-serv, and connecting with a openssl client. > > Hello, > Thanks for reporting that. It seems the AEAD ciphers addition has > broken the NULL cipher. I've committed a fix in the repository. Would be nice to add Fabrice?s example as a test case so the bug can be caught when it shows up again. Thanks, Ludo?. From nmav at gnutls.org Sat Nov 5 09:13:39 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 09:13:39 +0100 Subject: NULL cipher suites broken in gnutls 3.0.5 ? In-Reply-To: <877h3f77xg.fsf@gnu.org> References: <4EB43588.70704@gnutls.org> <877h3f77xg.fsf@gnu.org> Message-ID: <4EB4F033.803@gnutls.org> On 11/05/2011 01:02 AM, Ludovic Court?s wrote: >> Hello, >> Thanks for reporting that. It seems the AEAD ciphers addition has >> broken the NULL cipher. I've committed a fix in the repository. > Would be nice to add Fabrice?s example as a test case so the bug can be > caught when it shows up again. I've included a test. regards, Nikos From nmav at gnutls.org Sat Nov 5 09:28:02 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 09:28:02 +0100 Subject: EC keys interoperability issue between openSSL and GnuTLS ? In-Reply-To: References: Message-ID: <4EB4F392.4010901@gnutls.org> On 11/05/2011 12:46 AM, Fabrice Gautier wrote: > Hi, > > I generated some EC keys and cert using openssl, and when I try to use > them with gnutls_serv, it seems that gnutls_serv will just crash. Ouch. It seems there are two issues here. One bug which didn't report a parsing error back to the caller (was fixed) and the fact that openssl uses an old format for storing ECC private keys. GnuTLS uses the format from RFC 5915 for ECC keys. OpenSSL seems to be able to read this format, but I couldn't find an option to generate keys using this format. regards, Nikos From n.mavrogiannopoulos at gmail.com Sat Nov 5 12:16:16 2011 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 12:16:16 +0100 Subject: EC keys interoperability issue between openSSL and GnuTLS ? In-Reply-To: <4EB4F392.4010901@gnutls.org> References: <4EB4F392.4010901@gnutls.org> Message-ID: <4EB51B00.2030109@gmail.com> On 11/05/2011 09:28 AM, Nikos Mavrogiannopoulos wrote: > GnuTLS uses the format from RFC 5915 for ECC keys. OpenSSL seems to be > able to read this format, but I couldn't find an option to generate keys > using this format. I was wrong on that. If you generate an ECC key using: $ openssl ecparam -genkey -text -name secp224r1 it is stored using the RFC 5915 format. I don't know why your command outputs that old format. Maybe you should report it to the openssl guys. regards, Nikos From bluewind at xinu.at Mon Nov 7 10:22:22 2011 From: bluewind at xinu.at (Florian Pritz) Date: Mon, 07 Nov 2011 10:22:22 +0100 Subject: Compiling gnutls 3.0.5 on x86_64 in 32bit mode Message-ID: <4EB7A34E.9080308@xinu.at> Hi, I'm trying to compile gnutls 3.0.5 on a x86_64 host, but as a 32bit library so it can be used for a multilib environment. The problem is that it tries to compile 64bit assembler and fails [1][2]. If I add --host=i686 to ./configure it compiles fine, but only builds the static library and not the shared one (config.log [3]) although I use --disable-static. Am I missing something here? I could use --disable-hardware-acceleration, but I'm not sure if that's the best solution. [1]: https://paste.xinu.at/rF3W/ [2]: http://paste.xinu.at/NKYj/ [3]: http://paste.xinu.at/XCr/ -- Florian Pritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Mon Nov 7 22:42:22 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Nov 2011 22:42:22 +0100 Subject: gnutls 3.0.6 Message-ID: <4EB850BE.7000409@gnutls.org> Hello, I've just released gnutls 3.0.6. It is a bug-fix release on the current stable branch. * Version 3.0.6 (released 2011-11-07) ** gnutls-guile: Compilation fixes. ** libgnutls: Fixed possible buffer overflow in gnutls_session_get_data(). Reported and fix by Alban Crequy. ** libgnutls: Bug fixes in the ciphersuites with NULL cipher. Reported by Fabrice Gautier. ** libgnutls: Bug fixes in ECC code for 64-bit MIPS systems. Thanks to Joseph Graham for providing access to such a system. ** libgnutls: Correctly report ECC private key parsing errors. Reported by Fabrice Gautier. ** libgnutls: In ECDHE verify that the received point lies on the selected curve. The ECDHE ciphersuites now take precendence to plain DHE. ** 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 and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.6.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.6.tar.xz.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 nmav at gnutls.org Mon Nov 7 22:42:37 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Nov 2011 22:42:37 +0100 Subject: gnutls 2.12.13 Message-ID: <4EB850CD.2010908@gnutls.org> Hello, I've just released gnutls 2.12.13. This is a bugfix release on the 2.12.x branch. Version 2.12.13 (released 2011-11-07) ** minitasn1: Upgraded to libtasn1 version 2.10. ** libgnutls: Fixed possible buffer overflow in gnutls_session_get_data(). Reported and fix by Alban Crequy. ** 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 and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2.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 frank.krout at eurorscg.com Mon Nov 7 23:37:55 2011 From: frank.krout at eurorscg.com (frank.krout at eurorscg.com) Date: Mon, 7 Nov 2011 17:37:55 -0500 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? Message-ID: Hello, Using gnutls_record_check_pending() to check for received data in a function that sleeps a few times if no data present: ie. if (esmtpInfo.gnutls.ringBuffer.currentIndex == 0){//ringbuffer empty, look for more data int count = 0; int loop = 0; do { //add sleep function call here loop++; sleep( INTERNET_DEFAULT_TIMEOUT_SECONDS ); count = gnutls_record_check_pending( esmtpInfo.gnutls.session ); //count = esmtpInfo.gnutls.session->internals.record_buffer.byte_length; }while ( count <= 0 && loop < 3 ); if (count > 0) return NMQ_SUCCESS; if ( count == 0) return NMQ_NET_TIMEOUT; } Using this in multi-threaded mailer... problem is gnutls_record_check_pending() fails EVERY time. That is, it never indicates any data has been received. If I remove the check completely and just go to the receive logic after sending an ESMTP command and call gnutls_record_recv() all works fine. I successfully deliver complete emails. Looking at gnutls_record_check_pending()'s use in cli.c I see it's really inconclusive... the select might detect the incoming data... static int check_net_or_keyboard_input(socket_st* hd) { int maxfd; fd_set rset; int err; struct timeval tv; do { FD_ZERO (&rset); FD_SET (fileno (stdin), &rset); FD_SET (hd->fd, &rset); maxfd = MAX (fileno (stdin), hd->fd); tv.tv_sec = 0; tv.tv_usec = 500 * 1000; if (hd->secure == 1) if (gnutls_record_check_pending(hd->session)) return IN_NET; err = select (maxfd + 1, &rset, NULL, NULL, &tv); if (err < 0) continue; if (FD_ISSET (hd->fd, &rset)) return IN_NET; if (FD_ISSET (fileno (stdin), &rset)) return IN_KEYBOARD; } while(err == 0); return IN_NONE; } FYI, I'm linking in all of these -lgnutls -lgnutlsxx -lgnutls-extra I'm going to need to implement a timeout so threads don't hang, I suppose I could do it on the gnutls_record_recv() call, but will that block on no data received? Any thoughts? Regards, Frank System info: c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> gcc -v Using built-in specs. Target: s390x-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix= --enable-version-specific-runtime-libs --without-system-libunwind --with-tune=z9-109 --with-arch=z900 --with-long-double-128 --host=s390x-suse-linux Thread model: posix gcc version 4.1.2 20070115 (SUSE Linux) Frank Krout Senior Software Engineer Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 Tel 203.563.3314 Fax 203.563.3434 Web eurorscg.com ???? ________________________________________________________________________________ ____________________________________ The views and opinions expressed in this e-mail and any accompanying attachment, are those of the author and do not necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. To learn more about Euro RSCG, please visit our website at www.eurorscg.com Please consider the environment before printing this email. ________________________________________________________________________________ _____________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1491 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1131 bytes Desc: not available URL: From fabrice.gautier at gmail.com Tue Nov 8 04:14:03 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Mon, 7 Nov 2011 19:14:03 -0800 Subject: Issue with TLS_ECDHE_RSA_AES_128_CBC_SHA256 cipher suite. Message-ID: Hi, It looks like this cipher suite is using the wrong hash. >From algorithms/ciphersuites.c: GNUTLS_CIPHER_SUITE_ENTRY (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256, GNUTLS_CIPHER_AES_128_CBC, GNUTLS_KX_ECDHE_RSA, GNUTLS_MAC_SHA1, GNUTLS_TLS1_2, GNUTLS_VERSION_MAX, 1), Should be GNUTLS_MAC_SHA256 instead of GNUTLS_MAC_SHA1 -- Fabrice From nmav at gnutls.org Tue Nov 8 07:56:31 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 08 Nov 2011 07:56:31 +0100 Subject: Issue with TLS_ECDHE_RSA_AES_128_CBC_SHA256 cipher suite. In-Reply-To: References: Message-ID: <4EB8D29F.9060005@gnutls.org> On 11/08/2011 04:14 AM, Fabrice Gautier wrote: > Hi, > > It looks like this cipher suite is using the wrong hash. > From algorithms/ciphersuites.c: > GNUTLS_CIPHER_SUITE_ENTRY (GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256, > GNUTLS_CIPHER_AES_128_CBC, GNUTLS_KX_ECDHE_RSA, > GNUTLS_MAC_SHA1, GNUTLS_TLS1_2, > GNUTLS_VERSION_MAX, 1), > Should be GNUTLS_MAC_SHA256 instead of GNUTLS_MAC_SHA1 Nice catch. I've committed a fix. regards, Nikos From nmav at gnutls.org Tue Nov 8 08:26:25 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 08 Nov 2011 08:26:25 +0100 Subject: gnutls 3.0.7 Message-ID: <4EB8D9A1.3080800@gnutls.org> Hello, I've just released gnutls 3.0.7. The 3.0.6 release introduced a usability issue in an attempt to fix a security bug. This release eliminates the usability issue. I understand there is not much information on the security issue. This might change soon. * Version 3.0.7 (released 2011-11-08) ** libgnutls: Corrected fix in gnutls_session_get_data() to report the actual session size when the provided buffer is not enough. ** libgnutls: Fixed ciphersuite GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256, which was using a wrong MAC algorithm. Reported by Fabrice Gautier. ** 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 and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.7.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.7.tar.xz.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 nmav at gnutls.org Tue Nov 8 08:29:02 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 08 Nov 2011 08:29:02 +0100 Subject: gnutls 2.12.14 Message-ID: <4EB8DA3E.5020206@gnutls.org> Hello, I've just released gnutls 2.12.14. This is a bugfix release on the 2.12.x branch. Version 2.12.14 (released 2011-11-08) ** libgnutls: Corrected fix in gnutls_session_get_data() to report the actual session size when the provided buffer is not enough. ** 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 and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2.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 nmav at gnutls.org Tue Nov 8 12:57:10 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Nov 2011 12:57:10 +0100 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? In-Reply-To: References: Message-ID: Hi, Please check the documentation for gnutls_record_check_pending() at: http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_record_check_pending This function checks for data in the gnutls buffers, not for received network data. As you notice in the example you quote, for network data select() is being used. regards, Nikos On Mon, Nov 7, 2011 at 11:37 PM, wrote: > Hello, > > Using gnutls_record_check_pending() to check for received data in a > function that sleeps a few times if no data present: > > ie. > if (esmtpInfo.gnutls.ringBuffer.currentIndex == > 0){//ringbuffer empty, look for more data > int count = 0; > int loop = 0; > do { //add sleep function call here > loop++; > sleep( INTERNET_DEFAULT_TIMEOUT_SECONDS > ); > count = gnutls_record_check_pending( > esmtpInfo.gnutls.session ); > //count = > esmtpInfo.gnutls.session->internals.record_buffer.byte_length; > }while ( count <= 0 && loop < 3 ); > if (count > 0) return NMQ_SUCCESS; > if ( count == 0) return NMQ_NET_TIMEOUT; > } > > Using this in multi-threaded mailer... problem is > gnutls_record_check_pending() fails EVERY time. > That is, it never indicates any data has been received. > > If I remove the check completely and just go to the receive logic after > sending an ESMTP command and call gnutls_record_recv() > all works fine. I successfully deliver complete emails. > > Looking at gnutls_record_check_pending()'s use in cli.c I see it's really > inconclusive... the select might detect the incoming data... > static int check_net_or_keyboard_input(socket_st* hd) > { > int maxfd; > fd_set rset; > int err; > struct timeval tv; > > do > { > FD_ZERO (&rset); > FD_SET (fileno (stdin), &rset); > FD_SET (hd->fd, &rset); > > maxfd = MAX (fileno (stdin), hd->fd); > tv.tv_sec = 0; > tv.tv_usec = 500 * 1000; > > if (hd->secure == 1) > if (gnutls_record_check_pending(hd->session)) > return IN_NET; > > err = select (maxfd + 1, &rset, NULL, NULL, &tv); > if (err < 0) > continue; > > if (FD_ISSET (hd->fd, &rset)) > return IN_NET; > > > if (FD_ISSET (fileno (stdin), &rset)) > return IN_KEYBOARD; > } > while(err == 0); > > return IN_NONE; > } > > FYI, I'm linking in all of these -lgnutls -lgnutlsxx -lgnutls-extra > I'm going to need to implement a timeout so threads don't hang, > I suppose I could do it on the gnutls_record_recv() call, but will that > block on no data received? > > Any thoughts? > Regards, > Frank > > System info: > c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> > gcc -v > Using built-in specs. > Target: s390x-suse-linux > Configured with: ../configure --enable-threads=posix --prefix=/usr > --with-local-prefix=/usr/local --infodir=/usr/share/info > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > --enable-languages=c,c++,objc,fortran,obj-c++,java > --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 > --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 > --with-system-zlib --enable-shared --enable-__cxa_atexit > --enable-libstdcxx-allocator=new --program-suffix= > --enable-version-specific-runtime-libs --without-system-libunwind > --with-tune=z9-109 --with-arch=z900 --with-long-double-128 > --host=s390x-suse-linux > Thread model: posix > gcc version 4.1.2 20070115 (SUSE Linux) > > Frank Krout Senior Software Engineer > Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 > Tel 203.563.3314 Fax 203.563.3434 Web eurorscg.com > > [image: Image] [image: Image] > [image: Image] > * > ____________________________________________________________________________________________________________________ > * > The views and opinions expressed in this e-mail and any accompanying > attachment, are those of the author and do not > necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. > To learn more about Euro RSCG, please visit our website at * > www.eurorscg.com* > > [image: Image]*Please consider the environment before printing this email. > * > > _____________________________________________________________________________________________________ > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Nov 8 13:07:01 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Nov 2011 13:07:01 +0100 Subject: Compiling gnutls 3.0.5 on x86_64 in 32bit mode In-Reply-To: <4EB7A34E.9080308@xinu.at> References: <4EB7A34E.9080308@xinu.at> Message-ID: On Mon, Nov 7, 2011 at 10:22 AM, Florian Pritz wrote: > Hi, > I'm trying to compile gnutls 3.0.5 on a x86_64 host, but as a 32bit > library so it can be used for a multilib environment. The problem is > that it tries to compile 64bit assembler and fails [1][2]. > If I add --host=i686 to ./configure it compiles fine, but only builds > the static library and not the shared one (config.log [3]) although I > use --disable-static. Am I missing something here? Shouldn't you provide --host=mingw32? regards, Nikos From nmav at gnutls.org Tue Nov 8 15:51:23 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Nov 2011 15:51:23 +0100 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? In-Reply-To: References: Message-ID: It could be that gnutls_record_check_pending() returns zero. That would be if you have already read all pending data before calling it. This means that you use a large buffer that is enough to store the whole data packet(s) sent by the peer. However, you cannot rely on that being true with any peer. If you want to test if it is working just reduce your read buffer. regards, Nikos On Tue, Nov 8, 2011 at 3:31 PM, wrote: > > Thanks for the reply, Nikos. > > I do get that ?point. What I'm seeing is that for my gnutls secure sessions the function > gnutls_record_check_pending() never returns a value > 0. > When I remove the gnutls_record_check_pending call from my app and let the code issue the SMTP commands to send an email (after handshake) > and then go right into the receive response logic, calling gnutls_record_recv all most immediately, it all works. I successfully deliver emails. > > For some reason the gnutls_record_check_pending() call never finds any data. > > The example I quote, cli.c, is because given that code as a base, I can't be sure that gnutls_record_check_pending() > is working there for a secure session. I've seen gnutls_record_recv() work off of a select on the same socket. Not correct > coding, I get that. > > I'm wondering if I have an environment issue possibly... > c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> gcc -v > Using built-in specs. > Target: s390x-suse-linux > > library issue ... I'm linking in all of these ?-lgnutls -lgnutlsxx -lgnutls-extra > > Just not quite sure what's going on... > > I'm reviewing all my code but I got to a point where I'm looking for thoughts? > Regards, Frank Krout > > Frank Krout Senior Software Engineer > Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 > Tel 203.563.3314 Fax 203.563.3434 ?Web eurorscg.com > > > ____________________________________________________________________________________________________________________ > The views and opinions expressed in this e-mail and any accompanying attachment, are those of the author and do not > necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. > To learn more about Euro RSCG, please visit our website at www.eurorscg.com > > Please consider the environment before printing this email. > _____________________________________________________________________________________________________ > > > > > Nikos Mavrogiannopoulos > Sent by: n.mavrogiannopoulos at gmail.com > > 11/08/2011 06:57 AM > > To > frank.krout at eurorscg.com > cc > help-gnutls at gnu.org > Subject > Re: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? > > > > > > > Hi, > ?Please check the documentation for gnutls_record_check_pending() at: > http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_record_check_pending > > This function checks for data in the gnutls buffers, not for received network data. As you notice in the example you quote, for network data select() is being used. > > regards, > Nikos > > On Mon, Nov 7, 2011 at 11:37 PM, wrote: > Hello, > > Using gnutls_record_check_pending() to check for received data in a function that sleeps a few times if no data present: > > ie. > ? ? ? ? ? ? ? ? ? if (esmtpInfo.gnutls.ringBuffer.currentIndex == 0){//ringbuffer empty, look for more data > ? ? ? ? ? ? ? ? ? ? ? ? ? int count = 0; > ? ? ? ? ? ? ? ? ? ? ? ? ? int loop ? = 0; > ? ? ? ? ? ? ? ? ? ? ? ? ? do { //add sleep function call here > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? loop++; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sleep( INTERNET_DEFAULT_TIMEOUT_SECONDS ); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? count = gnutls_record_check_pending( esmtpInfo.gnutls.session ); > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? //count = esmtpInfo.gnutls.session->internals.record_buffer.byte_length; > ? ? ? ? ? ? ? ? ? ?}while ( count <= 0 && loop < 3 ); > ? ? ? ? ? ? ? ? ? ?if (count > 0) ?return NMQ_SUCCESS; > ? ? ? ? ? ? ? ? ? ?if ( count == 0) ?return NMQ_NET_TIMEOUT; > ? ? ? ? ? ? ? ? ? } > > Using this in multi-threaded mailer... problem is gnutls_record_check_pending() fails EVERY time. > That is, it never indicates any data has been received. > > If I remove the check completely and just go to the receive logic after sending an ESMTP command and call gnutls_record_recv() > all works fine. I successfully deliver complete emails. > > Looking at gnutls_record_check_pending()'s use in cli.c I see it's really inconclusive... the select might detect the incoming data... > static int check_net_or_keyboard_input(socket_st* hd) > { > ? int maxfd; > ? fd_set rset; > ? int err; > ? struct timeval tv; > > ? do > ? ? { > ? ? ? FD_ZERO (&rset); > ? ? ? FD_SET (fileno (stdin), &rset); > ? ? ? FD_SET (hd->fd, &rset); > > ? ? ? maxfd = MAX (fileno (stdin), hd->fd); > ? ? ? tv.tv_sec = 0; > ? ? ? tv.tv_usec = 500 * 1000; > > ? ? ? if (hd->secure == 1) > ? ? ? ? if (gnutls_record_check_pending(hd->session)) > ? ? ? ? ? return IN_NET; > > ? ? ? err = select (maxfd + 1, &rset, NULL, NULL, &tv); > ? ? ? if (err < 0) > ? ? ? ? continue; > > ? ? ? if (FD_ISSET (hd->fd, &rset)) > ? ? ? ? return IN_NET; > > > ? ? ? if (FD_ISSET (fileno (stdin), &rset)) > ? ? ? ? return IN_KEYBOARD; > ? ? } > ? while(err == 0); > > ? return IN_NONE; > } > > FYI, I'm linking in all of these ?-lgnutls -lgnutlsxx -lgnutls-extra > I'm going to need to implement a timeout so threads don't hang, > I suppose I could do it on the gnutls_record_recv() call, but ?will that block on no data received? > > Any ?thoughts? > Regards, > Frank > > System info: > c01z0047:~/projects/MassMailer/MassMailer_Linux_Release_4_0_0/MassMailer> gcc -v > Using built-in specs. > Target: s390x-suse-linux > Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix= --enable-version-specific-runtime-libs --without-system-libunwind --with-tune=z9-109 --with-arch=z900 --with-long-double-128 --host=s390x-suse-linux > Thread model: posix > gcc version 4.1.2 20070115 (SUSE Linux) > > Frank Krout Senior Software Engineer > Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 > Tel 203.563.3314 Fax 203.563.3434 ?Web eurorscg.com > > > ____________________________________________________________________________________________________________________ > > The views and opinions expressed in this e-mail and any accompanying attachment, are those of the author and do not > necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. > To learn more about Euro RSCG, please visit our website at www.eurorscg.com > > Please consider the environment before printing this email. > _____________________________________________________________________________________________________ > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls > > From hoyt6 at llnl.gov Tue Nov 8 19:52:32 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Tue, 8 Nov 2011 10:52:32 -0800 Subject: Compiling gnutls 3.0.5 on x86_64 in 32bit mode In-Reply-To: <4EB7A34E.9080308@xinu.at> References: <4EB7A34E.9080308@xinu.at> Message-ID: > If I add --host=i686 to ./configure it compiles fine, but only builds the static library and not the shared one (config.log [3]) although I use --disable-static. Libtool is finicky and at least in my configuration, it does not seem to recognize that ws2_32 (the winsock2 library) is in the library path and it thinks it cannot resolve all the symbols. Passing "lt_cv_deplibs_check_method=pass_all" to configure tells libtool to ignore those errors and forge on ahead. The command would look like: lt_cv_deplibs_check_method=pass_all ./configure --host=i686 ... Hope that helps, - David Hoyt From nmav at gnutls.org Wed Nov 9 12:56:57 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 9 Nov 2011 12:56:57 +0100 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? In-Reply-To: References: Message-ID: On Tue, Nov 8, 2011 at 10:16 PM, wrote: > This is weird, I reduced my receive calls to > peekLen = (long) gnutls_record_recv (esmtpInfo.gnutls.session, > esmtpInfo.gnutls.ringBuffer.data, 8); > Yes, 8 bytes at a time .... gnutls_record_check_pending()still does not > work. It gets called after every complete line of response is received. > Again, runs fine without it. > I would hate to have to put a mandatory sleep after every smtp command, > prior to looking for a response. > I don't fully understand your issue. Why do you have to put a sleep? Moreover I don't know your code, thus I cannot understand why you see that behavior. Try doing the following: client: gnutls_record_send(1024 bytes) server: gnutls_record_recv(4 bytes) gnutls_record_check_pending() should return 1020. (please keep the mailing list in CC) regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.krout at eurorscg.com Wed Nov 9 15:30:35 2011 From: frank.krout at eurorscg.com (frank.krout at eurorscg.com) Date: Wed, 9 Nov 2011 09:30:35 -0500 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? In-Reply-To: References: Message-ID: I'm integrating secure email support into an existing mailer app that functions essentially as a mail client. So, in sending emails, the processing of SMTP command responses may be delayed while waiting for a particular server. The legacy code handles this delay using the socket select() call to check for input and timeout if nothing is coming back from a server. So it is in the client side that I am using the gnutls_record_check_pending() Unless I'm missing something, with gnutls I need to emulate socket select() with something like: do { //add sleep function call here loop++; sleep( tv.tv_sec ); count_pending = gnutls_record_check_pending( session ); }while ( count_pending <= 0 && loop < whatever); hence, my reasoning for the need to sleep. In theory if I can't get gnutls_record_check_pending() working, then I'd need to do the sleep unconditionally after every command. gnutls_record_recv() blocks if it has no data, yes?? Thanks, Frank Nikos Mavrogiannopoulos Sent by: n.mavrogiannopoulos at gmail.com 11/09/2011 06:56 AM To frank.krout at eurorscg.com cc GnuTLS mailing list Subject Re: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? On Tue, Nov 8, 2011 at 10:16 PM, wrote: This is weird, I reduced my receive calls to peekLen = (long) gnutls_record_recv (esmtpInfo.gnutls.session, esmtpInfo.gnutls.ringBuffer.data, 8); Yes, 8 bytes at a time .... gnutls_record_check_pending()still does not work. It gets called after every complete line of response is received. Again, runs fine without it. I would hate to have to put a mandatory sleep after every smtp command, prior to looking for a response. I don't fully understand your issue. Why do you have to put a sleep? Moreover I don't know your code, thus I cannot understand why you see that behavior. Try doing the following: client: gnutls_record_send(1024 bytes) server: gnutls_record_recv(4 bytes) gnutls_record_check_pending() should return 1020. (please keep the mailing list in CC) regards, Nikos Frank Krout Senior Software Engineer Office Euro RSCG 4D, 372 Danbury Rd, Wilton, Connecticut 06897 Tel 203.563.3314 Fax 203.563.3434 Web eurorscg.com ???? ________________________________________________________________________________ ____________________________________ The views and opinions expressed in this e-mail and any accompanying attachment, are those of the author and do not necessarily represent the views or opinion of Euro RSCG Worldwide, Inc. To learn more about Euro RSCG, please visit our website at www.eurorscg.com Please consider the environment before printing this email. ________________________________________________________________________________ _____________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1491 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1131 bytes Desc: not available URL: From nmav at gnutls.org Wed Nov 9 15:40:40 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 Nov 2011 15:40:40 +0100 Subject: gnutls_record_check_pending() issue in GNUTLS 3.0.3 ?? In-Reply-To: References: Message-ID: <4EBA90E8.7090209@gnutls.org> On 11/09/2011 03:30 PM, frank.krout at eurorscg.com wrote: > I'm integrating secure email support into an existing mailer app that > functions essentially as a mail client. > So, in sending emails, the processing of SMTP command responses may be > delayed while waiting for a particular server. > The legacy code handles this delay using the socket select() call to check > for input and timeout if nothing is coming back from a server. You should continue using select() then. gnutls_check_pending() checks for data in the gnutls_session_t buffers, not in the network buffers. You should use it to complement select() (i.e., call select() if gnutls_record_check_pending() returned zero). This is what gnutls-cli does. > hence, my reasoning for the need to sleep. You don't need it. Use select() instead. > gnutls_record_recv() blocks if it has no data, yes?? If your socket is set to block it will block. regards, Nikos From fabrice.gautier at gmail.com Thu Nov 10 06:53:36 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Wed, 9 Nov 2011 21:53:36 -0800 Subject: Generating EC keys with certtool Message-ID: Hi, When i generate an EC key with certtool,I get this: $ /usr/local/bin/certtool -p --ecc Generating a 224 bit ECC private key... Public Key Info: Public Key Algorithm: ECC Key Security Level: Normal curve: SECP224R1 private key: 68:28:11:b0:30:0d:ff:cd:62:5f:4a:9e:47:26:de: 3c:a9:6a:7e:66:34:36:6d:c6:64:94:3a:21: x: 00:85:dc:f2:83:e7:0d:87:5a:0f:ac:0a:af:ec:93: 7b:b8:b8:89:ce:03:46:8a:23:06:91:8e:95:03: y: 4b:b3:f9:23:62:aa:b7:0d:5e:0f:ea:0d:76:91:66: f3:02:68:7d:6b:3f:cc:5f:15:87:d1:54:76: Public Key ID: 51:0D:86:15:74:B3:F6:38:58:AC:25:C0:A9:3E:AF:C8:A7:73:71:E0 -----BEGIN EC PRIVATE KEY----- MGgCAQEEHEuz+SNiqrcNXg/qDXaRZvMCaH1rP8xfFYfRVHagBwYFK4EEACGhPAM6 AASF3PKD5w2HWg+sCq/sk3u4uInOA0aKIwaRjpUDS7P5I2Kqtw1eD+oNdpFm8wJo fWs/zF8Vh9FUdg== -----END EC PRIVATE KEY----- I am pretty sure that this command used to (in 3.0.5) only output the encoded part, not the textual part. This also end up in the file when specifying a file with --outfile The textual part should be output on stderr, if at all. The "Generating a 224 bit ECC private key..." message is indeed output on stderr. It seems that certtool itself does not mind this extra text, but openssl seems to mind. From kip at thevertigo.com Thu Nov 10 10:09:25 2011 From: kip at thevertigo.com (Kip Warner) Date: Thu, 10 Nov 2011 01:09:25 -0800 Subject: Hardware Accelerator Advice Message-ID: <1320916165.3066.54.camel@kip-laptop> Hey folks, I'd like the advice of anyone who would like to offer some regarding my intended usage of GnuTLS. I'd like to use it as part of a game server to ensure secure client / server authentication during the handshake. During that process, I understand that it can be resource intensive on the server when there may be hundreds of clients attempting to do the same thing at the same time. I know that there is a such thing as SSL hardware accelerator cards that can have this computation offloaded to them, but seek informed advice from the community for this situation. (1) It's hard to get up to date information these devices. Are they superannuated by something else? (2) Would one even be appropriate for this situation on the server? (3) Can anyone recommend a card compatible with GnuTLS? I believe any that implement /dev/crypto, correct? Assume that the server would be running GNU/Linux with a relatively recent kernel. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com -------------- 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 nmav at gnutls.org Thu Nov 10 13:31:19 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 13:31:19 +0100 Subject: Hardware Accelerator Advice In-Reply-To: <1320916165.3066.54.camel@kip-laptop> References: <1320916165.3066.54.camel@kip-laptop> Message-ID: On Thu, Nov 10, 2011 at 10:09 AM, Kip Warner wrote: > Hey folks, > I'd like the advice of anyone who would like to offer some regarding my > intended usage of GnuTLS. > I'd like to use it as part of a game server to ensure secure client / > server authentication during the handshake. During that process, I > understand that it can be resource intensive on the server when there > may be hundreds of clients attempting to do the same thing at the same > time. I know that there is a such thing as SSL hardware accelerator > cards that can have this computation offloaded to them, but seek > informed advice from the community for this situation. Hello, In gnutls you can use instruction based optimizations on CPU's like via (with padlock) or intel/amd (with AES-NI), to optimize the operations on AES and/or SHA. There are also embedded (usually) systems that provide a kernel driver (/dev/crypto) to access few cryptographic algorithms. Both of the above optimize the transfer of data between client and server. They do not optimize the handshake procedure. For that you will need something like a hardware accelerator (or security module) that provides a PKCS #11 interface (driver) to access operations on RSA (or ECDSA) keys. I cannot suggest any because I have only tested security modules that didn't really provide acceleration (they were used for key isolation). There are however, other ways to optimize the handshake for your server. That is using an elliptic curve (ECDSA) key instead of RSA, or using ephemeral elliptic curve diffie hellman instead of plain diffie hellman etc. If you have control over the client and server application you can configure them to use the ciphersuites that have the lesser impact in performance, and make use of session resumption. > (2) Would one even be appropriate for this situation on the server? It would if you really expect the server to be busy (in calculations). It might happen that with configuration tweaks the server remains idle even without one. > (3) Can anyone recommend a card compatible with GnuTLS? I believe any > that implement /dev/crypto, correct? Assume that the server would be > running GNU/Linux with a relatively recent kernel. I've you're looking for an optimizer of AES (or SHA), I'd suggest to get a cpu such the ones described above (intel/amd with AES-NI or via with padlock). If you also need to optimize RSA/ECDSA you'll need a hardware accelerator with PKCS #11 support. Such one should work out of the box because PKCS #11 is pretty simple, but you'd better ask the provider of the module for compatibility (especially if it is an expensive one). regards, Nikos From nmav at gnutls.org Thu Nov 10 18:12:53 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 18:12:53 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: Message-ID: <4EBC0615.7000602@gnutls.org> On 11/10/2011 06:53 AM, Fabrice Gautier wrote: > Hi, > > When i generate an EC key with certtool,I get this: [...] > I am pretty sure that this command used to (in 3.0.5) only output the > encoded part, not the textual part. > This also end up in the file when specifying a file with --outfile > The textual part should be output on stderr, if at all. The > "Generating a 224 bit ECC private key..." message is indeed output on Hello, Printing the key information is deliberate, and also deliberate it is sent to stdout. What is the issue that you have with openssl? regards, Nikos From fabrice.gautier at gmail.com Thu Nov 10 19:29:35 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 10 Nov 2011 10:29:35 -0800 Subject: Generating EC keys with certtool In-Reply-To: <4EBC0615.7000602@gnutls.org> References: <4EBC0615.7000602@gnutls.org> Message-ID: On Thu, Nov 10, 2011 at 9:12 AM, Nikos Mavrogiannopoulos wrote: > On 11/10/2011 06:53 AM, Fabrice Gautier wrote: >> Hi, >> >> When i generate an EC key with certtool,I get this: > [...] >> I am pretty sure that this command used to (in 3.0.5) only output the >> encoded part, not the textual part. >> This also end up in the file when specifying a file with --outfile >> The textual part should be output on stderr, if at all. The >> "Generating a 224 bit ECC private key..." message is indeed output on > > Hello, > ?Printing the key information is deliberate, and also deliberate it is > sent to stdout. What is the issue that you have with openssl? > I'm generating a key with gnutls, then generating a CSR and cert with openssl. ${GNUTLS_CERTTOOL} -p --ecc --sec-param high --outfile ClientKey.ecc.pem ${OPENSSL} req -new -nodes -days 365 -subj '/CN=Client Cert (ECC)' -key ClientKey.ecc.pem -out ClientReq.ecc.pem ${OPENSSL} x509 -req -in ClientReq.ecc.pem -CA CACert.pem -CAkey CAKey.pem -set_serial 1003 -out ClientCert.ecc.pem The last command returns:"Signature did not match the certificate request" If I use openssl to try to verify the request I also get an error: $ ${OPENSSL} req -verify -noout -in ClientReq.ecc.pem verify failure 140735082790172:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:184: That said, the extra text does not seem to be the cause of this, I tried to remove it and just use the encoded blob and got the same result. And it looks like its not new from 3.0.7. The reason I mix-n-match gnutls/openssl is that gnutls does not parse EC key generated by openssl properly, as I reported before. It looks like openssl has some trouble with gnutls EC key somehow, although I'm kind of baffled at the moment, because I'm pretty sure it used to work at some point... From fabrice.gautier at gmail.com Thu Nov 10 19:48:29 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 10 Nov 2011 10:48:29 -0800 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> Message-ID: Ahah, so it happens to work on one of my machines, but not on the other two. The machine were it works is a mac running Lion, the other two are macs running SnowLeopard. I'm recompiling gnutls from source on all of them, openssl is also recompiled (either from source or through macports) so I'm guessing that something went wrong while compiling. On some machine, I used the gmp that came with macport, on others I recompiled myself, so who knows where the problem lies... Is there a way to verify a CSR with gnutls's certtool ? -- Fabrice On Thu, Nov 10, 2011 at 10:29 AM, Fabrice Gautier wrote: > On Thu, Nov 10, 2011 at 9:12 AM, Nikos Mavrogiannopoulos > wrote: >> On 11/10/2011 06:53 AM, Fabrice Gautier wrote: >>> Hi, >>> >>> When i generate an EC key with certtool,I get this: >> [...] >>> I am pretty sure that this command used to (in 3.0.5) only output the >>> encoded part, not the textual part. >>> This also end up in the file when specifying a file with --outfile >>> The textual part should be output on stderr, if at all. The >>> "Generating a 224 bit ECC private key..." message is indeed output on >> >> Hello, >> ?Printing the key information is deliberate, and also deliberate it is >> sent to stdout. What is the issue that you have with openssl? >> > > I'm generating a key with gnutls, then generating a CSR and cert with openssl. > > ${GNUTLS_CERTTOOL} -p ?--ecc --sec-param high --outfile ClientKey.ecc.pem > > ${OPENSSL} req -new -nodes -days 365 -subj '/CN=Client Cert (ECC)' > -key ClientKey.ecc.pem -out ClientReq.ecc.pem > ${OPENSSL} x509 -req -in ClientReq.ecc.pem -CA CACert.pem -CAkey > CAKey.pem -set_serial 1003 -out ClientCert.ecc.pem > > > The last command returns:"Signature did not match the certificate request" > > If I use openssl to try to verify the request I also get an error: > $ ${OPENSSL} req -verify -noout -in ClientReq.ecc.pem > verify failure > 140735082790172:error:0D0C5006:asn1 encoding > routines:ASN1_item_verify:EVP lib:a_verify.c:184: > > That said, the extra text does not seem to be the cause of this, I > tried to remove it and just use the encoded blob and got the same > result. And it looks like its not new from 3.0.7. > > The reason I mix-n-match gnutls/openssl is that gnutls does not parse > EC key generated by openssl properly, as I reported before. It looks > like openssl has some trouble with gnutls EC key somehow, although I'm > kind of baffled at the moment, because I'm pretty sure it used to work > at some point... > From nmav at gnutls.org Thu Nov 10 20:10:30 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 20:10:30 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> Message-ID: <4EBC21A6.4090109@gnutls.org> On 11/10/2011 07:29 PM, Fabrice Gautier wrote: >> Hello, >> Printing the key information is deliberate, and also deliberate it is >> sent to stdout. What is the issue that you have with openssl? >> > > I'm generating a key with gnutls, then generating a CSR and cert with openssl. [...] > The reason I mix-n-match gnutls/openssl is that gnutls does not parse > EC key generated by openssl properly, as I reported before. It looks > like openssl has some trouble with gnutls EC key somehow, although I'm > kind of baffled at the moment, because I'm pretty sure it used to work > at some point... Why not generate the certificate request with certtool as well? From nmav at gnutls.org Thu Nov 10 20:16:11 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 20:16:11 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> Message-ID: <4EBC22FB.3080209@gnutls.org> On 11/10/2011 07:48 PM, Fabrice Gautier wrote: > Ahah, so it happens to work on one of my machines, but not on the other two. > The machine were it works is a mac running Lion, the other two are > macs running SnowLeopard. > I'm recompiling gnutls from source on all of them, openssl is also > recompiled (either from source or through macports) so I'm guessing > that something went wrong while compiling. On some machine, I used the > gmp that came with macport, on others I recompiled myself, so who > knows where the problem lies... > Is there a way to verify a CSR with gnutls's certtool ? What do you mean verify a CSR? Verify the self signature? That is being done automatically when it is signed. regards, Nikos From fabrice.gautier at gmail.com Thu Nov 10 20:44:05 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 10 Nov 2011 11:44:05 -0800 Subject: Generating EC keys with certtool In-Reply-To: <4EBC22FB.3080209@gnutls.org> References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> Message-ID: On Thu, Nov 10, 2011 at 11:16 AM, Nikos Mavrogiannopoulos wrote: > On 11/10/2011 07:48 PM, Fabrice Gautier wrote: > >> Ahah, so it happens to work on one of my machines, but not on the other two. >> The machine were it works is a mac running Lion, the other two are >> macs running SnowLeopard. >> I'm recompiling gnutls from source on all of them, openssl is also >> recompiled (either from source or through macports) so I'm guessing >> that something went wrong while compiling. On some machine, I used the >> gmp that came with macport, on others I recompiled myself, so who >> knows where the problem lies... >> Is there a way to verify a CSR with gnutls's certtool ? > > What do you mean verify a CSR? Verify the self signature? That is being > done automatically when it is signed. Ah yes, I see that. Openssl has a command to verify without signing. The reason I'm not using certtool to generate the request is that I already had a script to generate certs using openssl. The only reason I used certtool for the key was that gnutls does not read openssl ec keys (Thats the issue I reported a few days ago). After investigating, it appears that the problem lies in gnutls generating a bad EC key on the BAD system. Both gnutls and openssl (on both GOOD and BAD systems) will happily generate a CSR using that bad key, but both will fail the verification when trying to sign the CSR. The rest of gnutls on the BAD system seems to work fine, I have been using the BAD system as a server, using keys and certs that were generated on the GOOD system. At least that's what it looks like so far... I'm attaching what I think is a BAD key if anybody wants to poke at it. > regards, > Nikos > -------------- next part -------------- A non-text attachment was scrubbed... Name: ClientKey.ecc.pem Type: application/octet-stream Size: 722 bytes Desc: not available URL: From nmav at gnutls.org Thu Nov 10 20:58:37 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 20:58:37 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> Message-ID: <4EBC2CED.5040607@gnutls.org> On 11/10/2011 08:44 PM, Fabrice Gautier wrote: > On Thu, Nov 10, 2011 at 11:16 AM, Nikos Mavrogiannopoulos > wrote: >> On 11/10/2011 07:48 PM, Fabrice Gautier wrote: >> >>> Ahah, so it happens to work on one of my machines, but not on the other two. >>> The machine were it works is a mac running Lion, the other two are >>> macs running SnowLeopard. >>> I'm recompiling gnutls from source on all of them, openssl is also >>> recompiled (either from source or through macports) so I'm guessing >>> that something went wrong while compiling. On some machine, I used the >>> gmp that came with macport, on others I recompiled myself, so who >>> knows where the problem lies... >>> Is there a way to verify a CSR with gnutls's certtool ? >> >> What do you mean verify a CSR? Verify the self signature? That is being >> done automatically when it is signed. > Ah yes, I see that. Openssl has a command to verify without signing. > The reason I'm not using certtool to generate the request is that I > already had a script to generate certs using openssl. The only reason > I used certtool for the key was that gnutls does not read openssl ec > keys (Thats the issue I reported a few days ago). > After investigating, it appears that the problem lies in gnutls > generating a bad EC key on the BAD system. Both gnutls and openssl (on > both GOOD and BAD systems) will happily generate a CSR using that bad > key, but both will fail the verification when trying to sign the CSR. Can you send me that (bad) key? What kind of system is the BAD system? regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Nov 10 21:08:46 2011 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 21:08:46 +0100 Subject: Generating EC keys with certtool In-Reply-To: <4EBC2CED.5040607@gnutls.org> References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> Message-ID: <4EBC2F4E.5010602@gmail.com> On 11/10/2011 08:58 PM, Nikos Mavrogiannopoulos wrote: >>> What do you mean verify a CSR? Verify the self signature? That is being >>> done automatically when it is signed. >> Ah yes, I see that. Openssl has a command to verify without signing. >> The reason I'm not using certtool to generate the request is that I >> already had a script to generate certs using openssl. The only reason >> I used certtool for the key was that gnutls does not read openssl ec >> keys (Thats the issue I reported a few days ago). >> After investigating, it appears that the problem lies in gnutls >> generating a bad EC key on the BAD system. Both gnutls and openssl (on >> both GOOD and BAD systems) will happily generate a CSR using that bad >> key, but both will fail the verification when trying to sign the CSR. > Can you send me that (bad) key? What kind of system is the BAD system? I just noticed it was attached. It is indeed incorrect. Did you run "make check" on the gnutls source on that system? Could you provide information about the CPU (32-bit/64-bit, endianness etc.). regards, Nikos From fabrice.gautier at gmail.com Thu Nov 10 21:59:28 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 10 Nov 2011 12:59:28 -0800 Subject: Generating EC keys with certtool In-Reply-To: <4EBC2F4E.5010602@gmail.com> References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> Message-ID: On Thu, Nov 10, 2011 at 12:08 PM, Nikos Mavrogiannopoulos wrote: > On 11/10/2011 08:58 PM, Nikos Mavrogiannopoulos wrote: > >>>> What do you mean verify a CSR? Verify the self signature? That is being >>>> done automatically when it is signed. >>> Ah yes, I see that. Openssl has a command to verify without signing. >>> The reason I'm not using certtool to generate the request is that I >>> already had a script to generate certs using openssl. The only reason >>> I used certtool for the key was that gnutls does not read openssl ec >>> keys (Thats the issue I reported a few days ago). >>> After investigating, it appears that the problem lies in gnutls >>> generating a bad EC key on the BAD system. Both gnutls and openssl (on >>> both GOOD and BAD systems) will happily generate a CSR using that bad >>> key, but both will fail the verification when trying to sign the CSR. >> Can you send me that (bad) key? What kind of system is the BAD system? > > I just noticed it was attached. It is indeed incorrect. Did you run > "make check" on the gnutls source on that system? Could you provide > information about the CPU (32-bit/64-bit, endianness etc.). > The bad systems are a MacBook Pro (Intel Core i7 / MacBokPro6,2) and a Mac Pro (Quad-Core Intel Xeon / MacPro4,1), both running Snow Leopard (10.6.8) Those are using gnutls 3.0.7 Those register as x86_64-apple-darwin10.8.0 The good system is an iMac (Intel Core i7 / iMac12,2) running Lion (10.7.2) This is with gnutls 3.0.5 This one register as x86_64-apple-darwin11.2.0 I had to disable assembly and hardware acceleration for nettle and gnutls because assembly would not compile. make check failed in all cases with "../gl/getopt.h:197: error: redefinition of 'struct option'" -- Fabrice From fabrice.gautier at gmail.com Thu Nov 10 22:11:02 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Thu, 10 Nov 2011 13:11:02 -0800 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> Message-ID: Hum, so actually I upgrade to 3.0.7 on the Good system, and now its bad... Bug introduced between 3.0.5 and 3.0.7 ? -- Fabrice On Thu, Nov 10, 2011 at 12:59 PM, Fabrice Gautier wrote: > On Thu, Nov 10, 2011 at 12:08 PM, Nikos Mavrogiannopoulos > wrote: >> On 11/10/2011 08:58 PM, Nikos Mavrogiannopoulos wrote: >> >>>>> What do you mean verify a CSR? Verify the self signature? That is being >>>>> done automatically when it is signed. >>>> Ah yes, I see that. Openssl has a command to verify without signing. >>>> The reason I'm not using certtool to generate the request is that I >>>> already had a script to generate certs using openssl. The only reason >>>> I used certtool for the key was that gnutls does not read openssl ec >>>> keys (Thats the issue I reported a few days ago). >>>> After investigating, it appears that the problem lies in gnutls >>>> generating a bad EC key on the BAD system. Both gnutls and openssl (on >>>> both GOOD and BAD systems) will happily generate a CSR using that bad >>>> key, but both will fail the verification when trying to sign the CSR. >>> Can you send me that (bad) key? What kind of system is the BAD system? >> >> I just noticed it was attached. It is indeed incorrect. Did you run >> "make check" on the gnutls source on that system? Could you provide >> information about the CPU (32-bit/64-bit, endianness etc.). >> > > The bad systems are a MacBook Pro (Intel Core i7 / MacBokPro6,2) and a > Mac Pro (Quad-Core Intel Xeon / MacPro4,1), both running Snow Leopard > (10.6.8) > Those are using gnutls 3.0.7 > Those ?register as x86_64-apple-darwin10.8.0 > > The good system is an iMac (Intel Core i7 / iMac12,2) ?running Lion (10.7.2) > This is with gnutls 3.0.5 > This one ?register as x86_64-apple-darwin11.2.0 > > > I had to disable assembly and hardware acceleration for nettle and > gnutls because assembly would not compile. > > > make check failed in all cases with "../gl/getopt.h:197: error: > redefinition of 'struct option'" > > -- Fabrice > From nmav at gnutls.org Thu Nov 10 22:19:21 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 22:19:21 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> Message-ID: <4EBC3FD9.3040400@gnutls.org> On 11/10/2011 10:11 PM, Fabrice Gautier wrote: > Hum, so actually I upgrade to 3.0.7 on the Good system, and now its bad... > Bug introduced between 3.0.5 and 3.0.7 ? Unfortunately yes. It does not export working ECDSA keys. I've fixed the issue and added test cases in master. That is the reason you had that issue. From kip at thevertigo.com Fri Nov 11 03:27:13 2011 From: kip at thevertigo.com (Kip Warner) Date: Thu, 10 Nov 2011 18:27:13 -0800 Subject: Hardware Accelerator Advice In-Reply-To: References: <1320916165.3066.54.camel@kip-laptop> Message-ID: <1320978433.3066.73.camel@kip-laptop> On Thu, 2011-11-10 at 13:31 +0100, Nikos Mavrogiannopoulos wrote: > On Thu, Nov 10, 2011 at 10:09 AM, Kip Warner wrote: > > Hey folks, > > I'd like the advice of anyone who would like to offer some regarding my > > intended usage of GnuTLS. > > I'd like to use it as part of a game server to ensure secure client / > > server authentication during the handshake. During that process, I > > understand that it can be resource intensive on the server when there > > may be hundreds of clients attempting to do the same thing at the same > > time. I know that there is a such thing as SSL hardware accelerator > > cards that can have this computation offloaded to them, but seek > > informed advice from the community for this situation. > > Hello, > In gnutls you can use instruction based optimizations on CPU's like > via (with padlock) or intel/amd (with AES-NI), to optimize the > operations on AES and/or SHA. There are also embedded (usually) > systems that provide a kernel driver (/dev/crypto) to access few > cryptographic algorithms. Both of the above optimize the transfer of > data between client and server. They do not optimize the handshake > procedure. For that you will need something like a hardware > accelerator (or security module) that provides a PKCS #11 interface > (driver) to access operations on RSA (or ECDSA) keys. I cannot suggest > any because I have only tested security modules that didn't really > provide acceleration (they were used for key isolation). > > There are however, other ways to optimize the handshake for your > server. That is using an elliptic curve (ECDSA) key instead of RSA, or > using ephemeral elliptic curve diffie hellman instead of plain diffie > hellman etc. If you have control over the client and server > application you can configure them to use the ciphersuites that have > the lesser impact in performance, and make use of session resumption. > > > (2) Would one even be appropriate for this situation on the server? > > It would if you really expect the server to be busy (in calculations). > It might happen that with configuration tweaks the server remains idle > even without one. > > > (3) Can anyone recommend a card compatible with GnuTLS? I believe any > > that implement /dev/crypto, correct? Assume that the server would be > > running GNU/Linux with a relatively recent kernel. > > I've you're looking for an optimizer of AES (or SHA), I'd suggest to > get a cpu such the ones described above (intel/amd with AES-NI or via > with padlock). If you also need to optimize RSA/ECDSA you'll need a > hardware accelerator with PKCS #11 support. Such one should work out > of the box because PKCS #11 is pretty simple, but you'd better ask the > provider of the module for compatibility (especially if it is an > expensive one). > > regards, > Nikos Thanks Nikos. That was fairly comprehensive. From the looks of it, the only SSL hardware accelerator cards I can find are in the tens of thousands of dollar range which is not an option for me anyways. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com -------------- 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 fabrice.gautier at gmail.com Fri Nov 11 22:27:45 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Fri, 11 Nov 2011 13:27:45 -0800 Subject: Generating EC keys with certtool In-Reply-To: <4EBC3FD9.3040400@gnutls.org> References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> <4EBC3FD9.3040400@gnutls.org> Message-ID: What do I need to build gnutls from the git repo ? It does not have the configure script in there, so I guess I need to use autoconf or automake to generate them, but I'm unsure on how this is done, or which version of those tools it would require. Thanks -- Fabrice On Thu, Nov 10, 2011 at 1:19 PM, Nikos Mavrogiannopoulos wrote: > On 11/10/2011 10:11 PM, Fabrice Gautier wrote: >> Hum, so actually I upgrade to 3.0.7 on the Good system, and now its bad... >> Bug introduced between 3.0.5 and 3.0.7 ? > > Unfortunately yes. It does not export working ECDSA keys. I've fixed the > issue and added test cases in master. That is the reason you had that issue. > > > From hoyt6 at llnl.gov Fri Nov 11 22:31:43 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Fri, 11 Nov 2011 13:31:43 -0800 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> <4EBC3FD9.3040400@gnutls.org> Message-ID: > What do I need to build gnutls from the git repo? Use "make -f cfg.mk autoreconf" From nmav at gnutls.org Sat Nov 12 16:11:11 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Nov 2011 16:11:11 +0100 Subject: gnutls 3.0.8 Message-ID: <4EBE8C8F.6040503@gnutls.org> Hello, I've just released gnutls 3.0.8. This release fixes issues in ECC key generation, and reduces the timing information provided to an adversary in DTLS. * Version 3.0.8 (released 2011-11-12) ** certtool: Certtool -e returns error code on verification failure. ** certtool: Verifies parameters of generated keys. ** libgnutls: Corrected ECC key generation (introduced in 3.0.6) ** libgnutls: Provide less timing information when decoding TLS/DTLS record packets. ** doc: man pages for API functions were removed. The reason was that the code that auto-generated the man pages missed many APIs and we couldn't fix it (volunteers welcome). See the info manual or the GTK-DOC manual instead. ** API and ABI modifications: gnutls_x509_privkey_verify_params: 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.8.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.8.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.8.tar.xz.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 simon at josefsson.org Sun Nov 13 12:37:05 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Nov 2011 12:37:05 +0100 Subject: Compiling gnutls 3.0.5 on x86_64 in 32bit mode In-Reply-To: (David Hoyt's message of "Tue, 8 Nov 2011 10:52:32 -0800") References: <4EB7A34E.9080308@xinu.at> Message-ID: <87ipmonti6.fsf@latte.josefsson.org> "Hoyt, David" writes: >> If I add --host=i686 to ./configure it compiles fine, but only > builds the static library and not the shared one (config.log [3]) > although I use --disable-static. > > Libtool is finicky and at least in my configuration, it does not seem > to recognize that ws2_32 (the winsock2 library) is in the library path > and it thinks it cannot resolve all the symbols. Passing > "lt_cv_deplibs_check_method=pass_all" to configure tells libtool to > ignore those errors and forge on ahead. The command would look like: > > lt_cv_deplibs_check_method=pass_all ./configure --host=i686 ... I recall that issue as well, and I think it is resolved if you run a recent libtool. Which version are you using? Try at least 2.2.10. /Simon From nmav at gnutls.org Thu Nov 17 23:57:49 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Nov 2011 23:57:49 +0100 Subject: gnutls_e_asn1_element_not_found In-Reply-To: References: <4EC2E5C3.1050501@gnutls.org> Message-ID: <4EC5916D.2070205@gnutls.org> On 11/16/2011 11:07 AM, Tapiwa Gutu wrote: > Hey, > > So you were on the mark, as I suspected the credentials were allocated > before gnutls_global_init() was called. Changing the little bit of code > allows the program to work perfectly. Now I have another problem. *5.4.1 Simple > client example with anonymous authentication* works only if I call* > gnutls_credentials_set > (session, GNUTLS_CRD_CERTIFICATE anoncred)* instead of *gnutls_credentials_set > (session, GNUTLS_CRD_ANON, anoncred)*. The handshake fails with a > gnutls_e_fatal_alert_received error. What do you mean by works? In order for anonymous authentication to work the peer has to support anonymous authentication as well. If you change the credentials to certificate credentials probably it works because you are connecting to a server that supports certificates. (please keep the mailing list in CC) regards, Nikos From rebelneurofog at gmail.com Fri Nov 18 04:33:32 2011 From: rebelneurofog at gmail.com (Rebel Neurofog) Date: Fri, 18 Nov 2011 06:33:32 +0300 Subject: Help needed with x.509 certificate Message-ID: Hi! I'm implementing network security for my project. But now I'm stuck writing a sample with both client and server certificates. So here's what happens: 1. I've generated all the keys and certificates needed to run GnuTLS examples. 2. Server works fine and client gets it's echo message as in examples. 3. But even though I do 'gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST);' on server side and also do 'gnutls_certificate_set_x509_key_file (xcred, CERTFILE, KEYFILE, GNUTLS_X509_FMT_PEM));' on client side which returns no error, there's no certificate received by server. 4. And if I do 'gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUIRE);' instead of REQUEST, server of course declines handshake with "The peer did not send any certificate." message. I guess, I miss something... Could you please help me with my confusion? GnuTLS version I'm using is 3.0.8 Here are all the files packed if it is helpful: ftp://neurofog.nomrhis.net/GNUTLS-CERT.tar.gz Best regards, Neurofog From mike at zentific.com Fri Nov 18 05:03:23 2011 From: mike at zentific.com (Mike Blumenkrantz) Date: Thu, 17 Nov 2011 23:03:23 -0500 Subject: Help needed with x.509 certificate In-Reply-To: References: Message-ID: <20111117230323.0325f192@darc.ath.cx> On Fri, 18 Nov 2011 06:33:32 +0300 Rebel Neurofog wrote: > Hi! > > I'm implementing network security for my project. > But now I'm stuck writing a sample with both client and server certificates. > So here's what happens: > > 1. I've generated all the keys and certificates needed to run GnuTLS examples. > 2. Server works fine and client gets it's echo message as in examples. > 3. But even though I do 'gnutls_certificate_server_set_request > (session, GNUTLS_CERT_REQUEST);' > on server side and also do 'gnutls_certificate_set_x509_key_file > (xcred, CERTFILE, KEYFILE, GNUTLS_X509_FMT_PEM));' > on client side which returns no error, there's no certificate received > by server. > 4. And if I do 'gnutls_certificate_server_set_request (session, > GNUTLS_CERT_REQUIRE);' instead of REQUEST, > server of course declines handshake with "The peer did not send any > certificate." message. > > I guess, I miss something... > Could you please help me with my confusion? > GnuTLS version I'm using is 3.0.8 > Here are all the files packed if it is helpful: > ftp://neurofog.nomrhis.net/GNUTLS-CERT.tar.gz > > Best regards, > Neurofog > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls This may seem like a dumb question, but are you calling gnutls_certificate_allocate_credentials() properly? Not sure it will help, but here is a functioning async certificate (client+server) implementation that I wrote some time ago that may provide some clues: https://svn.enlightenment.org/svn/e/trunk/ecore/src/lib/ecore_con/ecore_con_ssl.c -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. From rebelneurofog at gmail.com Fri Nov 18 16:01:07 2011 From: rebelneurofog at gmail.com (Rebel Neurofog) Date: Fri, 18 Nov 2011 18:01:07 +0300 Subject: Help needed with x.509 certificate In-Reply-To: <20111117230323.0325f192@darc.ath.cx> References: <20111117230323.0325f192@darc.ath.cx> Message-ID: > This may seem like a dumb question, but are you calling > gnutls_certificate_allocate_credentials() properly? > > Not sure it will help, but here is a functioning async certificate > (client+server) implementation that I wrote some time ago that may provide > some clues: > https://svn.enlightenment.org/svn/e/trunk/ecore/src/lib/ecore_con/ecore_con_ssl.c > > -- > Mike Blumenkrantz > Zentific: Doctor recommended, mother approved. > Thanks for suggestions. I've checked all that. So I'm beginning to think that I actually have incorrectly generated all the PEM stuff. Here's the code (I suppose there's something stupid there): # CA certtool --generate-privkey --outfile ca-key.pem certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem --template ca.cfg # Server cert certtool --generate-privkey --outfile server-key.pem certtool --generate-request --load-privkey server-key.pem --outfile server-request.pem --template server.cfg certtool --generate-certificate --load-request server-request.pem --outfile server-cert.pem --load-ca-certificate ca-cert.pem \ --load-ca-privkey ca-key.pem --template ca-server.cfg # Client cert certtool --generate-privkey --outfile client-key.pem certtool --generate-request --load-privkey client-key.pem --outfile client-request.pem --template client.cfg certtool --generate-certificate --load-request client-request.pem --outfile client-cert.pem --load-ca-certificate server-cert.pem \ --load-ca-privkey server-key.pem --template sv-client.cfg Yet I still don't understand how client certificate is distinguished from server certificate (at least in non-www cases where no "tls_www_client" and "tls_www_server" entries are used in templates) Say, the CA signed a server certificate. If server certificate have authority to sign certificate then the server can sign client certificates. But why then client certificates can't be used as server? And also which trust file have to be used by 'gnutls_certificate_set_x509_trust_file ()' on client side and which one on server? Best regards, Neurofog From nmav at gnutls.org Fri Nov 18 18:38:52 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 18 Nov 2011 18:38:52 +0100 Subject: Help needed with x.509 certificate In-Reply-To: References: <20111117230323.0325f192@darc.ath.cx> Message-ID: <4EC6982C.9080502@gnutls.org> On 11/18/2011 04:01 PM, Rebel Neurofog wrote: > Yet I still don't understand how client certificate is distinguished > from server certificate > (at least in non-www cases where no "tls_www_client" and > "tls_www_server" entries are used in templates) > Say, the CA signed a server certificate. If server certificate have > authority to sign certificate then the server > can sign client certificates. But why then client certificates can't > be used as server? Welcome to the X.509 world. Certificates are being distinguished by the extensions they are tagged with. I.e. you can tag the certificate as a CA or not (using X.509v3 extensions). If you don't use the tls_www_server then the only way to distinguish server from client certificates are the text fields of the distinguished name. > And also which trust file have to be used by > 'gnutls_certificate_set_x509_trust_file ()' on client side > and which one on server? There they put the CA the trust to verify their peers. If it is a common one they put the common one. regards, Nikos From nmav at gnutls.org Fri Nov 18 18:44:25 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 18 Nov 2011 18:44:25 +0100 Subject: Help needed with x.509 certificate In-Reply-To: References: Message-ID: <4EC69979.6070803@gnutls.org> On 11/18/2011 04:33 AM, Rebel Neurofog wrote: > Hi! > > I'm implementing network security for my project. > But now I'm stuck writing a sample with both client and server certificates. > So here's what happens: > > 1. I've generated all the keys and certificates needed to run GnuTLS examples. > 2. Server works fine and client gets it's echo message as in examples. > 3. But even though I do 'gnutls_certificate_server_set_request > (session, GNUTLS_CERT_REQUEST);' > on server side and also do 'gnutls_certificate_set_x509_key_file > (xcred, CERTFILE, KEYFILE, GNUTLS_X509_FMT_PEM));' > on client side which returns no error, there's no certificate received > by server. > 4. And if I do 'gnutls_certificate_server_set_request (session, > GNUTLS_CERT_REQUIRE);' instead of REQUEST, > server of course declines handshake with "The peer did not send any > certificate." message. > > I guess, I miss something... As Mike mentioned, you must be missing something. What you need to do is just use the client example from the documentation and add a call to gnutls_certificate_set_x509_key_file(), or use the example "Using a callback to select the certificate to use". regards, Nikos From rebelneurofog at gmail.com Sat Nov 19 16:32:06 2011 From: rebelneurofog at gmail.com (Rebel Neurofog) Date: Sat, 19 Nov 2011 18:32:06 +0300 Subject: SRP question Message-ID: Hi again! I've got the picture with X.509. But now I'm trying to handle SRP authentication. Simply using http://www.gnu.org/s/gnutls/manual/html_node/Echo-Server-with-SRP-authentication.html don't help much 'cause it is missing code getting information about user authenticated (or not authenticated). I've added "gnutls_srp_server_get_username (session)" after handshake but it returns NULL. So could please tell me what's missing in SRP server example to get information about user? Best regards, Neurofog From nmav at gnutls.org Sat Nov 19 17:04:56 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 19 Nov 2011 17:04:56 +0100 Subject: SRP question In-Reply-To: References: Message-ID: <4EC7D3A8.5010302@gnutls.org> On 11/19/2011 04:32 PM, Rebel Neurofog wrote: > Hi again! > > I've got the picture with X.509. > But now I'm trying to handle SRP authentication. > > Simply using > http://www.gnu.org/s/gnutls/manual/html_node/Echo-Server-with-SRP-authentication.html > don't help much 'cause it is missing code getting information about > user authenticated (or not authenticated). > I've added "gnutls_srp_server_get_username (session)" after handshake > but it returns NULL. Then most probably it wasn't SRP that got negotiated. Check the negotiated key exchange using gnutls_kx_get(). If you want to force SRP then use a priority string of the form "NORMAL:-KX-ALL:+SRP-RSA:+SRP-DSS:+SRP" regards, Nikos From nmav at gnutls.org Sat Nov 19 19:51:00 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 19 Nov 2011 19:51:00 +0100 Subject: Help needed with x.509 certificate In-Reply-To: References: <20111117230323.0325f192@darc.ath.cx> <4EC6982C.9080502@gnutls.org> Message-ID: <4EC7FA94.3050101@gnutls.org> On 11/18/2011 07:04 PM, Rebel Neurofog wrote: >> Welcome to the X.509 world. Certificates are being distinguished by the >> extensions they are tagged with. I.e. you can tag the certificate as a >> CA or not (using X.509v3 extensions). If you don't use the >> tls_www_server then the only way to distinguish server from client >> certificates are the text fields of the distinguished name. > But if I don't use tls_www_server and tls_www_client I actually get > some error message and things don't work. This wasn't your issue (I think I pointed that out in a previous e-mail). > 1. So, "www" is misused and not related to Web actually, right? Not really. It is a hint to the peer on what to expect on the certificate, nothing more than that. Most certificates don't include it. > 2. Just using tls_www_server and tls_www_client is enough to be sure > of correct certificate usage - GnuTLS will ensure that (failing in > case of misusing certificate), right? No. GnuTLS will only honors the key usage flags (that is the flags that say whether the certificate is sign only or encrypt only -e.g. in RSA certificates). > In case of common CA and same 'gnutls_certificate_set_x509_trust_file ()' > the may be a following situation: > - server A and server B has certificates from the same CA > - server A gives certificate to client X What do you mean server gives certificate to X? A CA signs and "gives" certificates, not a server. (Typically only certificates with the CA flag are allowed to sign other certificates). > - client X uses certificate given by server A to connect to server B > - and it works You have to be more precise on what you mean by works. When you call gnutls_certificate_set_x509_trust_file() on the server side you instruct the server to request the client a certificate from one of the included CAs. If the server sees another certificate then it would consider it untrusted. regards, Nikos From mrsam at courier-mta.com Sun Nov 20 04:38:07 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 19 Nov 2011 22:38:07 -0500 Subject: Change in =?UTF-8?Q?gnutls=5Fcertificate=5Fset=5Fx509=5Fkey()?= API from 2.10 to 2.12 Message-ID: I updated from gnutls 2.10 to 2.12 (Fedora 15 to 16). I'm seeing memory corruption after recompiling my gnutls client apps. I think I figured out why, and I want to make sure that my understanding is correct. Looking at gnutls 2.10 source, gnutls_certificate_set_x509_key() calls an internal function, _gnutls_x509_privkey_to_gkey() to essentially make a copy of the contents of the gnutls_x509_privkey_t parameter. So, in 2.10, the caller to gnutls_certificate_set_x509_key() maintains exclusive ownership of the gnutls_x509_privkey_t. The caller can destroy the gnutls_x509_privkey_t as soon as gnutls_certificate_set_x509_key() returns, without affecting the credentials object. That's what I am doing. In gnutls 2.12, gnutls_certificate_set_x509_key() is completely different. It looks to me like in 2.12, the gnutls_certificate_credentials_t object saves a pointer to the gnutls_x509_privkey_t structure, essentially, so it /cannot/ be destroyed, and must remain in existence as long as gnutls_certificate_credentials_t exists, correct? I was destroying gnutls_x509_privkey_t immediately after gnutls_certificate_set_x509_key(), I no longer needed it. This works in 2.10, but doesn't appear to work in 2.12. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Sun Nov 20 08:55:28 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Nov 2011 08:55:28 +0100 Subject: Change in gnutls_certificate_set_x509_key() API from 2.10 to 2.12 In-Reply-To: References: Message-ID: <4EC8B270.2050304@gnutls.org> On 11/20/2011 04:38 AM, Sam Varshavchik wrote: > I updated from gnutls 2.10 to 2.12 (Fedora 15 to 16). I'm seeing memory > corruption after recompiling my gnutls client apps. I think I figured > out why, and I want to make sure that my understanding is correct. > > Looking at gnutls 2.10 source, gnutls_certificate_set_x509_key() calls > an internal function, _gnutls_x509_privkey_to_gkey() to essentially make > a copy of the contents of the gnutls_x509_privkey_t parameter. So, in > 2.10, the caller to gnutls_certificate_set_x509_key() maintains > exclusive ownership of the gnutls_x509_privkey_t. The caller can destroy > the gnutls_x509_privkey_t as soon as gnutls_certificate_set_x509_key() > returns, without affecting the credentials object. That's what I am doing. > In gnutls 2.12, gnutls_certificate_set_x509_key() is completely > different. It looks to me like in 2.12, the > gnutls_certificate_credentials_t object saves a pointer to the > gnutls_x509_privkey_t structure, essentially, so it /cannot/ be > destroyed, and must remain in existence as long as > gnutls_certificate_credentials_t exists, correct? I was destroying > gnutls_x509_privkey_t immediately after > gnutls_certificate_set_x509_key(), I no longer needed it. This works in > 2.10, but doesn't appear to work in 2.12. Have you checked 2.12.10+? At that version the behavior of gnutls_certificate_set_x509_key() was made consistent with 2.10.x. regards, Nikos