From nmav at gnutls.org Wed Feb 1 08:44:57 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 1 Feb 2017 08:44:57 +0100 Subject: [gnutls-help] Getting Object Type From Usb Token In-Reply-To: References: Message-ID: On Tue, Jan 31, 2017 at 5:46 PM, Mandar Joshi wrote: > Hello, > I want to retrieve the URLs and type of all objects in a token. > > I am able to get the object list using > gnutls_pkcs11_obj_list_import_url4 (...) using the code in examples on > the gnutls website. > > Now, while iterating over the object list, I tried using > > ----------------------------------------------------------------------------------------------------- > struct gnutls_pkcs11_obj_st *x = (struct gnutls_pkcs11_obj_st *) obj_list[i]; > g_message ("Type: %d", x->type); This is an opaque pointer, you don't have direct access to it. You can access it via functions like gnutls_pkcs11_obj_get_type(). regards, Nikos From emailmandar at gmail.com Wed Feb 1 10:41:50 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Wed, 1 Feb 2017 15:11:50 +0530 Subject: [gnutls-help] Getting Object Type From Usb Token In-Reply-To: References: Message-ID: > > This is an opaque pointer, you don't have direct access to it. You can > access it via functions like gnutls_pkcs11_obj_get_type(). > Thanks. That's what I was looking for. I have everything working with GnuTLS under Linux (Fedora 25 x86_64). Is it possible to use GnuTLS with USB Tokens under Windows ? I have OpenSC and GnuTLS installed under Windows 7. With OpenSC installed, I can see my ePass2003 USB Token with "pkcs11-tool.exe -L" But p11tool doesn't find them. --------------------------------------------------------------------------------------------------------- C:\Downloads\gnutls-3.4.9-w32\bin>p11tool.exe --list-all warning: no token URL was provided for this operation; the available tokens are --------------------------------------------------------------------------------------------------------- I tried setting the provider option to opensc-pkcs11.dll but that gave me this error -------------------------------------------------------------------------------------------------------------- C:\Downloads\gnutls-3.4.9-w32\bin>p11tool.exe --provider=opensc-pkcs11.dll --list-all p11-kit: couldn't load module: /home/nmav/cvs/gnutls/win32/win32/lib/pkcs11\open sc-pkcs11.dll: The specified module could not be found. -------------------------------------------------------------------------------------------------------------- Is there some config file I am missing? Thanks Mandar Joshi From emailmandar at gmail.com Wed Feb 1 11:13:27 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Wed, 1 Feb 2017 15:43:27 +0530 Subject: [gnutls-help] Getting Object Type From Usb Token In-Reply-To: References: Message-ID: > I tried setting the provider option to opensc-pkcs11.dll but that gave > me this error > > -------------------------------------------------------------------------------------------------------------- > C:\Downloads\gnutls-3.4.9-w32\bin>p11tool.exe > --provider=opensc-pkcs11.dll --list-all > p11-kit: couldn't load module: /home/nmav/cvs/gnutls/win32/win32/lib/pkcs11\open > sc-pkcs11.dll: The specified module could not be found. > -------------------------------------------------------------------------------------------------------------- > > Is there some config file I am missing? It worked!. Just had to provide the full path p11tool --provider=c:\Windows\SysWOW64\opensc-pkcs11.dll --list-all --login From jgh at wizmail.org Fri Feb 3 00:11:50 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 2 Feb 2017 23:11:50 +0000 Subject: [gnutls-help] crash in gnutls_x509_trust_list_add_trust_file() Message-ID: <207b22d0-21c0-d39d-e93e-c3dee86de0dc@wizmail.org> Hi, I'm seeing a segfault in an application using gnutls_x509_trust_list_add_system_trust() [ fedora 25; GnuTLS 3.5.8 ] The application previously built and ran ok on Fedora 24. Any clues? :- Program terminated with signal SIGSEGV, Segmentation fault. #0 __GI___libc_free (mem=0x38) at malloc.c:2963 2963 if (chunk_is_mmapped (p)) /* release mmapped memory. */ (gdb) bt #0 __GI___libc_free (mem=0x38) at malloc.c:2963 #1 0x00007f6524c4c07c in gnutls_pkcs11_obj_list_import_url3 (p_list=p_list at entry=0x0, n_list=n_list at entry=0x7ffeeea5f890, url=url at entry=0x7f6524cf3640 "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit", flags=flags at entry=264194) at pkcs11.c:3069 #2 0x00007f6524c95d84 in gnutls_x509_trust_list_add_trust_file (list=0x12c9f70, ca_file=, ca_file at entry=0x7f6524cf3640 "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit", crl_file=crl_file at entry=0x0, type=type at entry=GNUTLS_X509_FMT_DER, tl_flags=6, tl_vflags=) at verify-high2.c:332 #3 0x00007f6524c2d09d in add_system_trust (tl_vflags=, tl_flags=, list=) at system/certs.c:113 #4 gnutls_x509_trust_list_add_system_trust (list=, tl_flags=, tl_vflags=) at system/certs.c:300 #5 0x0000000000486502 in tls_expand_session_files () #6 0x0000000000487336 in tls_init () #7 0x000000000048847d in tls_server_start () #8 0x000000000047e898 in smtp_setup_msg () #9 0x000000000042410b in daemon_go () #10 0x000000000043a9b2 in main () -- Thanks, Jeremy From nmav at gnutls.org Fri Feb 3 15:51:57 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 3 Feb 2017 15:51:57 +0100 Subject: [gnutls-help] crash in gnutls_x509_trust_list_add_trust_file() In-Reply-To: <207b22d0-21c0-d39d-e93e-c3dee86de0dc@wizmail.org> References: <207b22d0-21c0-d39d-e93e-c3dee86de0dc@wizmail.org> Message-ID: On Fri, Feb 3, 2017 at 12:11 AM, Jeremy Harris wrote: > Hi, > > I'm seeing a segfault in an application using > gnutls_x509_trust_list_add_system_trust() > > [ fedora 25; GnuTLS 3.5.8 ] Can you provide a valgrind run of the application and with debug symbols installed? Any way to reproduce? regards, Nikos From jgh at wizmail.org Fri Feb 3 17:02:46 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 3 Feb 2017 16:02:46 +0000 Subject: [gnutls-help] crash in gnutls_x509_trust_list_add_trust_file() In-Reply-To: References: <207b22d0-21c0-d39d-e93e-c3dee86de0dc@wizmail.org> Message-ID: <9e4b8168-1201-024a-97a5-5cf8d5c374d6@wizmail.org> On 03/02/17 14:51, Nikos Mavrogiannopoulos wrote: > On Fri, Feb 3, 2017 at 12:11 AM, Jeremy Harris wrote: >> I'm seeing a segfault in an application using >> gnutls_x509_trust_list_add_system_trust() >> >> [ fedora 25; GnuTLS 3.5.8 ] > > Can you provide a valgrind run of the application and with debug > symbols installed? Any way to reproduce? The repro is testcase 2003 of the Exim testsuite. Unfortunately trying to mash valgrind in there is being difficult; so far it seem to hang the testharness that runs the exim daemon getting the problem. Running the valgrind manually fails with a refusal to run a suid executable. -- Cheers, Jeremy From emailmandar at gmail.com Wed Feb 8 01:45:08 2017 From: emailmandar at gmail.com (Mandar Joshi) Date: Wed, 8 Feb 2017 06:15:08 +0530 Subject: [gnutls-help] Exporting Private Key from a USB Token Message-ID: I am using an ePass2003 USB Token in a network application. The private key on the token has been generated on the token. This is because I haven't been able to use --load-privkey to write a PEM for Key to this token. Does anybody have an idea why this may be? The error I get is ----------------------------------------------------------------------------------------------- Error in pkcs11_write:723: The requested PKCS #11 object is not available ----------------------------------------------------------------------------------------------- The certificate gets written and is exportable as given in the GnuTLS docs. I would like to able to export the private key in PEM format. But from what I know, I don't think it's possible if the private key has been generated on the USB token. Am I correct? The error code I get while trying to export a private key is -56. I would appreciate any suggestions on how I can speed up access to the certificate and private key stored on a USB Token. Also, are private keys written to USB Tokens not exportable using any library/toolkit for (eg. openssl, pkccs#11 API etc) or is it just with GnuTLS? I have used various SmartCards using APDUs in PCSC-LIte directly. This is the first time I am using a higher level API to communicate with a token. Regards Mandar Joshi From zhengrq.fnst at cn.fujitsu.com Thu Feb 9 03:41:57 2017 From: zhengrq.fnst at cn.fujitsu.com (Zheng, Ruoqin) Date: Thu, 9 Feb 2017 02:41:57 +0000 Subject: [gnutls-help] Problem of gnutls on armv8 Message-ID: <33D4DBCAC5F2D74E96B07F6E7632BF73204CA633@G08CNEXMBPEKD01.g08.fujitsu.local> Hi I want to use curl to request https in an armv8 board ls1046. Here is the log: root # curl -v -k https://192.168.246.2 * Rebuilt URL to: https://192.168.246.2/ * Trying 192.168.246.2... * Connected to 192.168.246.2 (192.168.246.2) port 443 (#0) * found 177 certificates in /etc/ssl/certs/ca-certificates.crt * ALPN, offering http/1.1 * gnutls_handshake() failed: Bad record MAC * Closing connection 0 curl: (35) gnutls_handshake() failed: Bad record MAC And here is the kernel, the OS is arm32be compiled by yocto. root # uname -a Linux ubinux-armv8be 4.1.30-rt34+ #6 SMP Thu Jan 19 19:05:01 JST 2017 armv7b GNU/Linux Then I found that curl is using gnutls lib, so I check the tls with gnutls-cli-debug: root # gnutls-cli-debug 192.168.246.2 GnuTLS debug client 3.3.17 Checking 192.168.246.2:443 for SSL 3.0 (RFC6101) support... no whether we need to disable TLS 1.2... yes whether we need to disable TLS 1.1... yes whether we need to disable TLS 1.0... yes whether %NO_EXTENSIONS is required... yes whether %COMPAT is required... yes for TLS 1.0 (RFC2246) support... no Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2 By the way, I ensure that the server is normal. So is anyone who met this problem or have any solutions? Thank you Zheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Feb 9 11:45:21 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 9 Feb 2017 11:45:21 +0100 Subject: [gnutls-help] Problem of gnutls on armv8 In-Reply-To: <33D4DBCAC5F2D74E96B07F6E7632BF73204CA633@G08CNEXMBPEKD01.g08.fujitsu.local> References: <33D4DBCAC5F2D74E96B07F6E7632BF73204CA633@G08CNEXMBPEKD01.g08.fujitsu.local> Message-ID: On Thu, Feb 9, 2017 at 3:41 AM, Zheng, Ruoqin wrote: > Hi > > I want to use curl to request https in an armv8 board ls1046. > > Here is the log: > > root # curl -v -k https://192.168.246.2 > > * Rebuilt URL to: https://192.168.246.2/ > > * Trying 192.168.246.2... > > * Connected to 192.168.246.2 (192.168.246.2) port 443 (#0) > > * found 177 certificates in /etc/ssl/certs/ca-certificates.crt > > * ALPN, offering http/1.1 > > * gnutls_handshake() failed: Bad record MAC > > * Closing connection 0 > > curl: (35) gnutls_handshake() failed: Bad record MAC > > > > And here is the kernel, the OS is arm32be compiled by yocto. > > root # uname -a > > Linux ubinux-armv8be 4.1.30-rt34+ #6 SMP Thu Jan 19 19:05:01 JST 2017 armv7b > GNU/Linux There are few new optimizations for gnutls in aarch64 which could be in effect. You can test whether this is the culprit try the same tests that you have with the environment variable GNUTLS_CPUID_OVERRIDE=1. If that still fails, the issue could be on a different place. I'd suggest then to try the following: 1. compile the nettle library, and run make check 2. compile the gnutls library and run make check regards, Nikos From nmav at gnutls.org Sun Feb 12 11:23:15 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 12 Feb 2017 11:23:15 +0100 Subject: [gnutls-help] gnutls 3.5.9 Message-ID: <1486894995.2137.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.9. This is a bug fix release on the 3.5.x branch. * Version 3.5.9 (released 2017-02-12) ** libgnutls: Removed any references to OpenPGP functionality in documentation, ???and marked all functions in openpgp.h as deprecated. That functionality ???is considered deprecated and should not be used for other reason than ???backwards compatibility. ** libgnutls: Improve detection of AVX support. In certain cases when ???when the instruction was available on the host, but not on a VM running ???gnutls, detection could fail causing illegal instruction usage. ** libgnutls: Added support for IDNA2008 for internationalized DNS names. ???If gnutls is compiled using libidn2 (the latest version is recommended), ???it will support IDNA2008 instead of the now obsolete IDNA2003 standard. ???Resolves gitlab issue #150. Based on patch by Tim Ruehsen. ** p11tool: re-use ID from corresponding objects when writing certificates. ???That is, when writing a certificate which has a corresponding public key, ???or private key in the token, ensure that we use the same ID for the ???certificate. ** API and ABI modifications: gnutls_idna_map: Added gnutls_idna_reverse_map: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.9.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.9.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 sean at seangreenslade.com Mon Feb 13 22:28:06 2017 From: sean at seangreenslade.com (Sean Greenslade) Date: Mon, 13 Feb 2017 13:28:06 -0800 Subject: [gnutls-help] DTLS and gnutls_bye Message-ID: <20170213212806.GA28007@coach> Hello, all. I've been writing a small server-client application that's using GnuTLS's DTLS functionality. I must admit I'm not super familiar with TLS in general, and it seems that DTLS is not used very often, so I can't find too many examples of its use online. My question is this: is gnutls_bye intended to be used with DTLS "connections"? I realize that there isn't a proper connection in UDP, but it seems like it would be useful to inform the other end of a connection that there will be no further communications in this TLS session. Specifically, the behavior I'm seeing is this. gnutls_bye does send the close alert message over the wire, however the receiving end does not raise an alert error when checking for received packets. I tested other alerts, which go through and raise the proper alert error on the remote end. Also, after receiving the packet containing the close alert, the remote end is still able to send packets back without error. Is this a bug, or intended behavior? Thanks for the help, --Sean From nmav at gnutls.org Tue Feb 14 21:01:34 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Feb 2017 21:01:34 +0100 Subject: [gnutls-help] DTLS and gnutls_bye In-Reply-To: <20170213212806.GA28007@coach> References: <20170213212806.GA28007@coach> Message-ID: On Mon, Feb 13, 2017 at 10:28 PM, Sean Greenslade wrote: > Hello, all. I've been writing a small server-client application that's > using GnuTLS's DTLS functionality. I must admit I'm not super familiar > with TLS in general, and it seems that DTLS is not used very often, so I > can't find too many examples of its use online. > > My question is this: is gnutls_bye intended to be used with DTLS > "connections"? I realize that there isn't a proper connection in UDP, > but it seems like it would be useful to inform the other end of a > connection that there will be no further communications in this TLS > session. > > Specifically, the behavior I'm seeing is this. gnutls_bye does send the > close alert message over the wire, however the receiving end does not > raise an alert error when checking for received packets. What does the other side receive? regards, Nikos From sean at seangreenslade.com Wed Feb 15 03:07:07 2017 From: sean at seangreenslade.com (Sean Greenslade) Date: Tue, 14 Feb 2017 18:07:07 -0800 Subject: [gnutls-help] DTLS and gnutls_bye In-Reply-To: References: <20170213212806.GA28007@coach> Message-ID: <20170215020706.GA20020@coach> On Tue, Feb 14, 2017 at 09:01:34PM +0100, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 13, 2017 at 10:28 PM, Sean Greenslade > wrote: > > Hello, all. I've been writing a small server-client application that's > > using GnuTLS's DTLS functionality. I must admit I'm not super familiar > > with TLS in general, and it seems that DTLS is not used very often, so I > > can't find too many examples of its use online. > > > > My question is this: is gnutls_bye intended to be used with DTLS > > "connections"? I realize that there isn't a proper connection in UDP, > > but it seems like it would be useful to inform the other end of a > > connection that there will be no further communications in this TLS > > session. > > > > Specifically, the behavior I'm seeing is this. gnutls_bye does send the > > close alert message over the wire, however the receiving end does not > > raise an alert error when checking for received packets. > > What does the other side receive? When the close alert packet gets sent from the client to the server, I can see it on the wire (encrypted, of course). The server has a multiplexer function that handles multiple clients simultaneously, and it sees a packet from the client and calls gnutls_record_recv() to process it. gnutls_record_recv() returns zero, apparently ignoring the alert flag while consuming the packet. --Sean From nmav at gnutls.org Thu Feb 16 05:18:06 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Feb 2017 05:18:06 +0100 Subject: [gnutls-help] DTLS and gnutls_bye In-Reply-To: <20170215020706.GA20020@coach> References: <20170213212806.GA28007@coach> <20170215020706.GA20020@coach> Message-ID: <1487218686.2009.2.camel@gnutls.org> On Tue, 2017-02-14 at 18:07 -0800, Sean Greenslade wrote: > > > Specifically, the behavior I'm seeing is this. gnutls_bye does > > > send the > > > close alert message over the wire, however the receiving end does > > > not > > > raise an alert error when checking for received packets. > > > > What does the other side receive? > > When the close alert packet gets sent from the client to the server, > I > can see it on the wire (encrypted, of course). The server has a > multiplexer function that handles multiple clients simultaneously, > and > it sees a packet from the client and calls gnutls_record_recv() to > process it. gnutls_record_recv() returns zero, apparently ignoring > the > alert flag while consuming the packet. Returning zero is the expected behavior (EOF) from gnutls_record_recv, when the closure alert is received. regards, Nikos From sean at seangreenslade.com Thu Feb 16 06:16:32 2017 From: sean at seangreenslade.com (Sean Greenslade) Date: Wed, 15 Feb 2017 21:16:32 -0800 Subject: [gnutls-help] DTLS and gnutls_bye In-Reply-To: <1487218686.2009.2.camel@gnutls.org> References: <20170213212806.GA28007@coach> <20170215020706.GA20020@coach> <1487218686.2009.2.camel@gnutls.org> Message-ID: <20170216051631.GA13259@coach> On Thu, Feb 16, 2017 at 05:18:06AM +0100, Nikos Mavrogiannopoulos wrote: > On Tue, 2017-02-14 at 18:07 -0800, Sean Greenslade wrote: > > > > > Specifically, the behavior I'm seeing is this. gnutls_bye does > > > > send the > > > > close alert message over the wire, however the receiving end does > > > > not > > > > raise an alert error when checking for received packets. > > > > > > What does the other side receive? > > > > When the close alert packet gets sent from the client to the server, > > I > > can see it on the wire (encrypted, of course). The server has a > > multiplexer function that handles multiple clients simultaneously, > > and > > it sees a packet from the client and calls gnutls_record_recv() to > > process it. gnutls_record_recv() returns zero, apparently ignoring > > the > > alert flag while consuming the packet. > > Returning zero is the expected behavior (EOF) from gnutls_record_recv, > when the closure alert is received. OK, I kind of figured it was something like that. I'll just implement timeouts on both ends. Thanks for the help! --Sean From carles.llobet at upc.edu Thu Feb 16 16:10:59 2017 From: carles.llobet at upc.edu (Carles Llobet) Date: Thu, 16 Feb 2017 16:10:59 +0100 Subject: [gnutls-help] OpenVAS gnutils compiling error Message-ID: <58A5C103.3030404@upc.edu> Hi, I am trying to compile OpenVAS-8 on a OpenSUSE server. When I try to compile gnutls 3.5.9, (i have also tried with 3.5.8 and 2.12.9) i get an /"undefined reference"/ error, pointing to p11-kit and libtasn1. They have been installed in their current last stable version, and the libraries are correctly pointed to /"/usr/local/lib64"/. I have tried to compile configuring gnutls with the flags /--without-p11-kit/ and /--with-included-libtasn1/ and gnutls compiles and installs correctly, but when i compile openvas-libraries (8.0.8) i get the same error as when compiling gnutls with the default configuration. You can find the error on an attached screenshot and right below on text. Has somebody found the same trouble? How could I get rid of this error? */[ 40%] Building C object misc/CMakeFiles/openvas_misc_shared.dir/ldap_connect_auth.c.o [ 42%] Linking C shared library libopenvas_misc.so [ 42%] Built target openvas_misc_shared [ 43%] Building C object base/CMakeFiles/test-hosts.dir/test-hosts.c.o [ 44%] Linking C executable test-hosts /usr/local/lib64/libgnutls.so: undefined reference to `asn1_der_decoding2 at LIBTASN1_0_3' /usr/local/lib64/libgnutls.so: undefined reference to `asn1_decode_simple_ber at LIBTASN1_0_3' /usr/local/lib64/libgnutls.so: undefined reference to `p11_kit_uri_get_pin_value' collect2: error: ld returned 1 exit status base/CMakeFiles/test-hosts.dir/build.make:97: recipe for target 'base/test-hosts' failed make[2]: *** [base/test-hosts] Error 1 CMakeFiles/Makefile2:160: recipe for target 'base/CMakeFiles/test-hosts.dir/all' failed make[1]: *** [base/CMakeFiles/test-hosts.dir/all] Error 2 Makefile:160: recipe for target 'all' failed make: *** [all] Error 2 /*Thanks for your attention, -- inLabFIB - Talent & Tech *Carles Llobet Pons* carles.llobet at fib.upc.edu +34 93 401 77 39 *Facultat d'Inform?tica de Barcelona* *Universitat Polit?cnica de Catalunya* - Barcelona Tech ------------------------------------------------------------------------ ADVERTIMENT / TEXT LEGAL: Aquest missatge pot contenir informaci? confidencial o legalment protegida i est? exclusivament adre?at a la persona o entitat destinat?ria. Si vost? no es el destinatari final o persona encarregada de recollir-lo, no est? autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si ha rebut aquest correu electr?nic per error, li preguem que informi al remitent i elimini del seu sistema el missatge i el material annex que pugui contenir. Gr?cies per la seva col?laboraci?. WARNING / LEGAL NOTICE: This message may contain confidential or legally protected information and is intended only for the recipient person or entity. If you are not the final recipient or person in charge of receiving it, you are not allowed to read it, keep it, modify it, distribute it, copy it or disclose its content. If you should not have received this, please inform the sender and delete the message from your system, along with any attached content. Thanks for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 16812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Logo_inLabFIB.png Type: image/png Size: 24465 bytes Desc: not available URL: From teddy+gnutls at recompile.se Sat Feb 18 15:26:15 2017 From: teddy+gnutls at recompile.se (Teddy Hogeborn) Date: Sat, 18 Feb 2017 15:26:15 +0100 Subject: [gnutls-help] gnutls 3.5.9 In-Reply-To: <1486894995.2137.3.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 12 Feb 2017 11:23:15 +0100") References: <1486894995.2137.3.camel@gnutls.org> Message-ID: <87lgt360e0.fsf@recompile.se> Nikos Mavrogiannopoulos writes: > Hello, > ?I've just released gnutls 3.5.9. This is a bug fix release on the > 3.5.x branch. > > > * Version 3.5.9 (released 2017-02-12) > > ** libgnutls: Removed any references to OpenPGP functionality in > ???documentation, and marked all functions in openpgp.h as > ???deprecated. That functionality is considered deprecated and should > ???not be used for other reason than backwards compatibility. I really hope that the functions will not be actually *removed* until support for raw public keys are added? (From RFC 7250, Issue #26: ) /Teddy Hogeborn -- The Mandos Project https://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From nmav at gnutls.org Sun Feb 19 11:03:16 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 19 Feb 2017 11:03:16 +0100 Subject: [gnutls-help] gnutls 3.5.9 In-Reply-To: <87lgt360e0.fsf@recompile.se> References: <1486894995.2137.3.camel@gnutls.org> <87lgt360e0.fsf@recompile.se> Message-ID: On Sat, Feb 18, 2017 at 3:26 PM, Teddy Hogeborn wrote: >> ** libgnutls: Removed any references to OpenPGP functionality in >> documentation, and marked all functions in openpgp.h as >> deprecated. That functionality is considered deprecated and should >> not be used for other reason than backwards compatibility. > > I really hope that the functions will not be actually *removed* until > support for raw public keys are added? (From RFC 7250, Issue #26: > ) That was the original plan. Tom Vrancken (in CC) has had an initial patch for RFC7250 support. Tom are you still pursuing adding RFC7250 support to gnutls? regards, Nikos From nmav at gnutls.org Sun Feb 19 11:04:31 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 19 Feb 2017 11:04:31 +0100 Subject: [gnutls-help] OpenVAS gnutils compiling error In-Reply-To: <58A5C103.3030404@upc.edu> References: <58A5C103.3030404@upc.edu> Message-ID: On Thu, Feb 16, 2017 at 4:10 PM, Carles Llobet wrote: > Hi, > > I am trying to compile OpenVAS-8 on a OpenSUSE server. > When I try to compile gnutls 3.5.9, (i have also tried with 3.5.8 and > 2.12.9) i get an *"undefined reference"* error, pointing to p11-kit and > libtasn1. They have been installed in their current last stable version, > and the libraries are correctly pointed to *"/usr/local/lib64"*. > You are linking with a different library than the one you are compiling with. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at schlittermann.de Thu Feb 23 12:44:11 2017 From: hs at schlittermann.de (Heiko Schlittermann) Date: Thu, 23 Feb 2017 12:44:11 +0100 Subject: [gnutls-help] Exim + GnuTLS 2.12.20 and inbound connections from outlook.com Message-ID: <20170223114411.GI30718@jumper.schlittermann.de> Hello, I experience a strange issue with Exim (4.80), GnuTLS 2.12.20 on "my" side and outlook.com on the other side. Exim+GnuTLS are running as a server. Outlook.com is configured to send via authenticated SMTP via my server. They try to establish a connection to port 587 and fail right after "change cipher spec" and "encrypted handshake message". I'll append a pcap file, in case somebody can get more information from this. Exim uses (IMHO) default settings when initializing the GnuTLS library. A recent Exim version (4.88) doesn't change the behaviour. But if I exchange GnuTLS for OpenSSL the issues goes away. Is there any way to configure (priority string?) GnuTLS for interoperability with outlook.com. Some observation from Exim debugging: GnuTLS using default session cipher/priority "NORMAL" cipher: TLS1.2:RSA_AES_256_CBC_SHA256:256 followed by an connection drop (outlook.com sends FIN). Working connections from outlook.com use ECDHE-RSA-AES256-GCM-SHA384 when I have OpenSSL on my side. Any hint is appreciated. Does Exim need to do something when initializing the GnuTLS library (I'm asking as an Exim developer). Best regards from Dresden/Germany Viele Gr??e aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ - -------------- next part -------------- A non-text attachment was scrubbed... Name: outlook.pcap Type: application/vnd.tcpdump.pcap Size: 7800 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From nmav at gnutls.org Thu Feb 23 13:36:43 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Feb 2017 13:36:43 +0100 Subject: [gnutls-help] Exim + GnuTLS 2.12.20 and inbound connections from outlook.com In-Reply-To: <20170223114411.GI30718@jumper.schlittermann.de> References: <20170223114411.GI30718@jumper.schlittermann.de> Message-ID: On Thu, Feb 23, 2017 at 12:44 PM, Heiko Schlittermann wrote: > Hello, > I experience a strange issue with Exim (4.80), GnuTLS 2.12.20 on "my" > side and outlook.com on the other side. > Exim+GnuTLS are running as a server. Outlook.com is configured to send > via authenticated SMTP via my server. They try to establish a > connection to port 587 and fail right after "change cipher spec" and > "encrypted handshake message". > > I'll append a pcap file, in case somebody can get more information from > this. > > Exim uses (IMHO) default settings when initializing the GnuTLS library. > A recent Exim version (4.88) doesn't change the behaviour. But if I > exchange GnuTLS for OpenSSL the issues goes away. Hi, Versions prior to GnuTLS 2.12.24 had few issues related to TLS 1.2 that were addressed with the recently released 2.12.24. Thus my first recommendation would be to try with that version first. > Is there any way to configure (priority string?) GnuTLS for > interoperability with outlook.com. > > > Some observation from Exim debugging: > > GnuTLS using default session cipher/priority "NORMAL" > cipher: TLS1.2:RSA_AES_256_CBC_SHA256:256 > > followed by an connection drop (outlook.com sends FIN). > > Working connections from outlook.com use ECDHE-RSA-AES256-GCM-SHA384 > when I have OpenSSL on my side. Gnutls prior to 3.0.x does not have support for GCM or ECDHE. Thus servers which have been restricted only to ECDHE or GCM will fail to interoperate. To find out whether that's the case you can use gnutls-cli-debug and gnutls-cli to test against that domain. regards, Nikos