From rogerdpack2 at gmail.com Fri Apr 1 18:44:13 2016 From: rogerdpack2 at gmail.com (Roger Pack) Date: Fri, 1 Apr 2016 10:44:13 -0600 Subject: [gnutls-help] warning message In-Reply-To: References: Message-ID: On 5/15/14, Nikos Mavrogiannopoulos wrote: > On Wed, May 14, 2014 at 8:57 PM, Roger Pack wrote: >> Hello. As a note, with 3.2.14 I get this (somewhat annoying) error >> message when linking against gnutls static: >> /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): >> warning: multiple common of `_gnutls_x86_cpuid_s' > > I don't see any obvious multiple definition on these files. It could > be an issue I couldn't figure though, if it is, a fix is welcome. Linking against 3.4.10 libgnutls.a file: .../lib/libgnutls.a(sha256-ssse3-x86.o): warning: common of `_gnutls_x86_cpuid_s' overriding smaller common ...lib/libgnutls.a(x86-common.o): warning: smaller common is here declarations appear to be here: lib/accelerated/x86/x86-common.c 49:unsigned int _gnutls_x86_cpuid_s[3]; lib/accelerated/x86/coff/sha256-ssse3-x86.s 67: leal __gnutls_x86_cpuid_s-.L001K256(%ebp),%edx 3400:.comm __gnutls_x86_cpuid_s,16 perhaps the comm directive redefines it, or perhaps that's just under mingw that it does? gnutls-3.4.10 $ i686-w64-mingw32-gcc-nm -a ./lib/accelerated/x86/x86-common.o | grep _gnutls_x86_cpuid_s 0000000c C __gnutls_x86_cpuid_s gnutls-3.4.10 $ i686-w64-mingw32-gcc-nm -a ./lib/accelerated/x86/coff/sha256-ssse3-x86.o | grep _gnutls_x86_cpuid_s 00000010 C __gnutls_x86_cpuid_s FWIW. Thanks! -roger- From rogerdpack2 at gmail.com Fri Apr 1 18:44:38 2016 From: rogerdpack2 at gmail.com (Roger Pack) Date: Fri, 1 Apr 2016 10:44:38 -0600 Subject: [gnutls-help] warning message In-Reply-To: References: Message-ID: On 5/15/14, Nikos Mavrogiannopoulos wrote: > On Wed, May 14, 2014 at 8:57 PM, Roger Pack wrote: >> Hello. As a note, with 3.2.14 I get this (somewhat annoying) error >> message when linking against gnutls static: >> /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): >> warning: multiple common of `_gnutls_x86_cpuid_s' > > I don't see any obvious multiple definition on these files. It could > be an issue I couldn't figure though, if it is, a fix is welcome. Linking against 3.4.10 libgnutls.a file: .../lib/libgnutls.a(sha256-ssse3-x86.o): warning: common of `_gnutls_x86_cpuid_s' overriding smaller common ...lib/libgnutls.a(x86-common.o): warning: smaller common is here declarations appear to be here: lib/accelerated/x86/x86-common.c 49:unsigned int _gnutls_x86_cpuid_s[3]; lib/accelerated/x86/coff/sha256-ssse3-x86.s 67: leal __gnutls_x86_cpuid_s-.L001K256(%ebp),%edx 3400:.comm __gnutls_x86_cpuid_s,16 perhaps the comm directive redefines it, or perhaps that's just under mingw that it does? gnutls-3.4.10 $ i686-w64-mingw32-gcc-nm -a ./lib/accelerated/x86/x86-common.o | grep _gnutls_x86_cpuid_s 0000000c C __gnutls_x86_cpuid_s gnutls-3.4.10 $ i686-w64-mingw32-gcc-nm -a ./lib/accelerated/x86/coff/sha256-ssse3-x86.o | grep _gnutls_x86_cpuid_s 00000010 C __gnutls_x86_cpuid_s FWIW. Thanks! -roger- From n.mavrogiannopoulos at gmail.com Sun Apr 3 09:44:16 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 03 Apr 2016 09:44:16 +0200 Subject: [gnutls-help] warning message In-Reply-To: References: Message-ID: <1459669456.32317.2.camel@gmail.com> On Fri, 2016-04-01 at 10:44 -0600, Roger Pack wrote: > On 5/15/14, Nikos Mavrogiannopoulos wrote: > > On Wed, May 14, 2014 at 8:57 PM, Roger Pack > > wrote: > > > Hello. As a note, with 3.2.14 I get this (somewhat annoying) > > > error > > > message when linking against gnutls static: > > > /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw > > > -w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): > > > warning: multiple common of `_gnutls_x86_cpuid_s' > > > > I don't see any obvious multiple definition on these files. It > > could > > be an issue I couldn't figure though, if it is, a fix is welcome. > > Linking against 3.4.10 libgnutls.a file: > > .../lib/libgnutls.a(sha256-ssse3-x86.o): warning: common of > `_gnutls_x86_cpuid_s' overriding smaller common > ...lib/libgnutls.a(x86-common.o): warning: smaller common is here > > declarations appear to be here: > > lib/accelerated/x86/x86-common.c > 49:unsigned int _gnutls_x86_cpuid_s[3]; > lib/accelerated/x86/coff/sha256-ssse3-x86.s > 67: leal __gnutls_x86_cpuid_s-.L001K256(%ebp),%edx > 3400:.comm __gnutls_x86_cpuid_s,16 If you change the unsigned int _gnutls_x86_cpuid_s[3] to unsigned int _gnutls_x86_cpuid_s[4] would it compile? ld should have allocated the largest size for this symbol automatically, but it could be some incompatibility with that platform's ld. regards, Nikos From gnutls at wodny.org Mon Apr 4 23:10:10 2016 From: gnutls at wodny.org (Marcin Szewczyk) Date: Mon, 4 Apr 2016 23:10:10 +0200 Subject: [gnutls-help] Availability of gnutls.org over HTTPS In-Reply-To: <87ziv8bar8.fsf@vigenere.g10code.de> References: <20160209150600.GB3060@orkisz> <87ziv8bar8.fsf@vigenere.g10code.de> Message-ID: <20160404211010.GC3239@orkisz> On Wed, Feb 10, 2016 at 08:55:55PM +0100, Werner Koch wrote: > On Wed, 10 Feb 2016 09:59, nmav at gnutls.org said: > > > The reason is that the server we are hosted did not support SSL/TLS. > > However, now I see that there is https available for www.gnupg.org. > > For a long time actually. > > > Werner could TLS be enabled for gnutls as well? > > I am currently travelling but I can take care of this on Friday. I have just noticed that a certificate has been issued on 23rd March. Thanks, -- Marcin Szewczyk http://wodny.org From TKnight at osgoode.yorku.ca Thu Apr 7 17:11:57 2016 From: TKnight at osgoode.yorku.ca (TKnight at osgoode.yorku.ca) Date: Thu, 7 Apr 2016 11:11:57 -0400 Subject: [gnutls-help] GnuTLS error -15: An unexpected TLS packet was received. Message-ID: Hello gnutls-help, I'm setting up vsftpd on apache and using SSL. When I try logging in with FileZilla I get this error message. Error: GnuTLS error -15: An unexpected TLS packet was received. Error: Could not connect to server I am new to server configuration and not sure what this error means. I have added the following parameters in vsftpd.conf: # enable TLS/SSL ssl_enable=YES # force client to use TLS when logging in allow_anon_ssl=NO force_local_data_ssl=YES force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO require_ssl_reuse=NO ssl_ciphers=HIGH # specify SSL certificate/private key rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem Any help you can offer appreciated. Thanks. Best regards, Tim ___________________________________________ F. Tim Knight Associate Librarian Head of Technical Services Osgoode Hall Law School Library Ignat Kaneff Building York University 4700 Keele Street, Toronto, ON, Canada M3J 1P3 T: 416-650-8403 F: 416-736-5298 E: tknight at osgoode.yorku.ca W: http://www.osgoode.yorku.ca/faculty-and-staff/knight-f-tim/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3206 bytes Desc: not available URL: From alex at alex.org.uk Fri Apr 8 10:36:07 2016 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 8 Apr 2016 09:36:07 +0100 Subject: [gnutls-help] Truly non-blocking example of gnutls usage Message-ID: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> Is there a simple, easy to reuse, example of gnu-tls acting like a proxy which is truly non-blocking? By truly non-blocking I mean using non-blocking writes as well as non-blocking reads. The danger I am concerned about is receiving a large amount of plain-text, gnutls converting that to cypher-text, attempting to write it but blocking because the remote side is not ready to receive it. The remote side is not ready to receive it because it has its own output blocked as gnutls is not polling for reads as it's blocked above, meaning deadlock. I've done this for OpenSSL, and it was a pain (frankly). I'd now like to do it for gnutls as I'd like to incorporate the result into a GPL project, and OpenSSL's licensing may be considered problematic. Therefore an example which is GPL / GPL-compatible would be great. Otherwise an example of how I could do it would be good. Something like stunnel written with gnutls would be ideal. Unless I'm missing something gnutls-cli only does non-blocking reads (not non-blocking writes). -- Alex Bligh From nmav at gnutls.org Fri Apr 8 15:35:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 8 Apr 2016 15:35:29 +0200 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> Message-ID: On Fri, Apr 8, 2016 at 10:36 AM, Alex Bligh wrote: > Is there a simple, easy to reuse, example of gnu-tls acting like a > proxy which is truly non-blocking? By truly non-blocking I mean using > non-blocking writes as well as non-blocking reads. The danger I > am concerned about is receiving a large amount of plain-text, > gnutls converting that to cypher-text, attempting to write it > but blocking because the remote side is not ready to receive it. > The remote side is not ready to receive it because it has its > own output blocked as gnutls is not polling for reads as > it's blocked above, meaning deadlock. Blocking is a matter of the underlying socket functions. If you set the sockets to non blocking mode gnutls operates in a non-blocking way almost identically to berkeley sockets. Have you checked the manual? https://www.gnutls.org/manual/html_node/Asynchronous-operation.html The simplest example is mini-eagain.c from the test suite which verifies the asynchronous operation of gnutls_record_send and recv. regards, Nikos From alex at alex.org.uk Fri Apr 8 18:16:06 2016 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 8 Apr 2016 17:16:06 +0100 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> Message-ID: <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> Nikos, Thanks for your reply. On 8 Apr 2016, at 14:35, Nikos Mavrogiannopoulos wrote: > On Fri, Apr 8, 2016 at 10:36 AM, Alex Bligh wrote: >> Is there a simple, easy to reuse, example of gnu-tls acting like a >> proxy which is truly non-blocking? By truly non-blocking I mean using >> non-blocking writes as well as non-blocking reads. The danger I >> am concerned about is receiving a large amount of plain-text, >> gnutls converting that to cypher-text, attempting to write it >> but blocking because the remote side is not ready to receive it. >> The remote side is not ready to receive it because it has its >> own output blocked as gnutls is not polling for reads as >> it's blocked above, meaning deadlock. > > Blocking is a matter of the underlying socket functions. Perhaps I should have used the word 'asynchronous' > If you set > the sockets to non blocking mode gnutls operates in a non-blocking way > almost identically to berkeley sockets. Have you checked the manual? > https://www.gnutls.org/manual/html_node/Asynchronous-operation.html I had done, but it was not fantastically helpful. The manual says "GnuTLS does not keep a write buffer, thus when writing no additional actions are required." which I took to mean it was writing synchronously (but reading async). > The simplest example is mini-eagain.c from the test suite which > verifies the asynchronous operation of gnutls_record_send and recv. Thanks - that was helpful. But it doesn't do a select loop as far as I can tell. The examples there set their own push/pull functions, which I understand to be to read/write the crypted traffic. I was planning if possible to use straight sockets. Does a select loop now look something like the code below? (pseudo-code, error checking omitted) I'm guessing here, and an example would be really helpful. Also do I need to manually verify certificates after a handshake? src/cli.c seems to do this with its own callback functions, but I don't know whether that's for debugging purposes only? int tls_wr_interrupted = 0; while (1) { size_t buffered = gnutls_record_check_pending (); if (buffered) timeout = 0; // don't wait on select if we have buffered data else timeout = infinite; if (!bufIsEmpty (plainToCrypt) || tls_wr_interrupted) FD_SET (crypt, write_fd_set); if (!bufIsEmpty (cryptToPlain)) FD_SET (plain, write_fd_set); if (!bufIsFull (plainToCrypt)) FD_SET (plain, read_fd_set); if (!bufIsFull (cryptToPlain)) FD_SET (crypt, read_fd_set); select (read_fd_set, write_fd_set, 0, timeout); if (FD_IS_SET (crypt, read_fd_set) || buffered) buffer (cryptToPlain, gnutls_record_recv ( ...)); if (FD_IS_SET (crypt, write_fd_set)) { if tls_wr_interrupted { err = gnutls_record_send (NULL); } else { err = gnutls_record_send (unbuffer (plainToCrypt), ...); } tls_wr_interrupted = (err == GNUTLS_E_INTERRUPTED); } if (FD_IS_SET (plain, read_fd_set)) buffer (plainToCrypt, read (plain, ...)); if (FD_IS_SET (plain, write_fd_set)) write (plain, unbuffer (cryptToPlain) ...); } -- Alex Bligh From n.mavrogiannopoulos at gmail.com Fri Apr 8 19:25:16 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 08 Apr 2016 19:25:16 +0200 Subject: [gnutls-help] Make check fails on gnutls 3.4.9 In-Reply-To: <20160405131044.a2a27e39017416ff46cd466d@jcoppens.com> References: <20160405131044.a2a27e39017416ff46cd466d@jcoppens.com> Message-ID: <1460136316.1794.11.camel@gmail.com> On Tue, 2016-04-05 at 13:10 -0300, John Coppens wrote: > Hello people, Please use the bugs at gnutls.org only for non public bugs. I'm forwarding your mail to the mailing list. > > Doing a make check on just-compiled gnutls 3.4.9 (on Linux), I get > this: > > make[4]: Entering directory `/usr/local/src/internet/gnutls > -3.4.9/guile/tests' > FAIL: anonymous-auth.scm > FAIL: session-record-port.scm > FAIL: pkcs-import-export.scm > FAIL: errors.scm > FAIL: x509-certificates.scm > FAIL: x509-auth.scm > FAIL: priorities.scm > FAIL: openpgp-keys.scm > FAIL: openpgp-keyring.scm > FAIL: openpgp-auth.scm > FAIL: srp-base64.scm Most likely a guile issue in your system. > Except for just a couple of SKIPs in the previous tests, all previous > tests > went well. Though I normally confide and don't run checks (shame on > me), I > did run them now, because I get a Segmentation Fault when running > Gobby, > which I can't seem to find the cause of: > > #0 0x00007ffff1c03060 in __memcpy_sse2_unaligned () from > /lib64/libc.so.6 > #1 0x00007ffff2a57f16 in _asn1_set_value (node=node at entry=0xad0a10, > value=0x2f53555f6e652f65, len=1298088780) > at parser_aux.c:245 > #2 0x00007ffff2a59405 in _asn1_copy_structure3 > (source_node=0x8121a0) at structure.c:417 > #3 0x00007ffff2a5c05e in asn1_der_coding (element=, > name=, ider=0x0, > len=0x7fffffffbd50, ErrorDescription=0x0) at coding.c:1029 > #4 0x00007ffff29de67d in _gnutls_x509_der_encode (src=0x8121a0, > src_name=0x7ffff2a6bea9 "", res=0x7fffffffbde0, > str=str at entry=0) at common.c:1255 > #5 0x00007ffff29de936 in _gnutls_x509_export_int_named2 > (asn1_data=, name=, > format=, pem_header=, > out=) at common.c:1004 > #6 0x00007ffff29dea4c in _gnutls_x509_export_int_named > (asn1_data=, name=, > format=GNUTLS_X509_FMT_DER, pem_header=, > output_data=0x0, output_data_size=0x7fffffffbe28) > at common.c:961 > #7 0x00007ffff2a085dd in _gnutls_x509_crt_cpy (dest=0xac3e90, > src=0x7ee930) at x509.c:116 > #8 0x00007ffff29c0a64 in gnutls_certificate_set_x509_trust > (res=0xac3e00, ca_list=, > ca_list_size=151) at gnutls_x509.c:1557 > #9 0x000000000047c1d0 in Gobby::CertificateManager::make_credentials > (this=this at entry=0x7fffffffc790) > at certificatemanager.cpp:442 > #10 0x000000000047d17e in Gobby::CertificateManager::load_trust ( > this=this at entry=0x7fffffffc790) > at certificatemanager.cpp:388 > #11 0x000000000047d585 in > Gobby::CertificateManager::CertificateManager (this=0x7fffffffc790, > preferences=...) > at certificatemanager.cpp:53 > #12 0x000000000042422e in main (argc=1, argv=0x7fffffffdd98) at > main.cpp:287 It looks like a certificate is crashing the parser, but I have no idea whether this is a valid certificate provided, or some it involves some invalid memory addresses. If you can reproduce that with a certificate and certtool, after verifying that you are using a recent gnutls and libtasn1 versions, please report them as a bug with a reproducer. regards, Nikos From nmav at gnutls.org Fri Apr 8 19:44:23 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 08 Apr 2016 19:44:23 +0200 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> Message-ID: <1460137463.1794.15.camel@gnutls.org> On Fri, 2016-04-08 at 17:16 +0100, Alex Bligh wrote: > Nikos, > > Thanks for your reply. > > On 8 Apr 2016, at 14:35, Nikos Mavrogiannopoulos > wrote: > > > On Fri, Apr 8, 2016 at 10:36 AM, Alex Bligh > > wrote: > > > Is there a simple, easy to reuse, example of gnu-tls acting like > > > a > > > proxy which is truly non-blocking? By truly non-blocking I mean > > > using > > > non-blocking writes as well as non-blocking reads. The danger I > > > am concerned about is receiving a large amount of plain-text, > > > gnutls converting that to cypher-text, attempting to write it > > > but blocking because the remote side is not ready to receive it. > > > The remote side is not ready to receive it because it has its > > > own output blocked as gnutls is not polling for reads as > > > it's blocked above, meaning deadlock. > > > > Blocking is a matter of the underlying socket functions. > > Perhaps I should have used the word 'asynchronous' > > > If you set > > the sockets to non blocking mode gnutls operates in a non-blocking > > way > > almost identically to berkeley sockets. Have you checked the > > manual? > > https://www.gnutls.org/manual/html_node/Asynchronous-operation.html > > I had done, but it was not fantastically helpful. > > The manual says "GnuTLS does not keep a write buffer, thus when > writing > no additional actions are required." which I took to mean it was > writing > synchronously (but reading async). That sentence is indeed confusing. I've removed it. > > > The simplest example is mini-eagain.c from the test suite which > > verifies the asynchronous operation of gnutls_record_send and recv. > Thanks - that was helpful. But it doesn't do a select loop > as far as I can tell. No. A select loop will be complex and I don't know if one could have a reasonable example. If you have one consider contributing it. To see a real world example check ocserv's main loop: https://gitlab.com/ocserv/ocserv/blob/master/src/worker-vpn.c#L1892 It uses both TLS and DTLS sockets in async mode (with poll, there is no reason to use select() as it has terrible semantics). regards, Nikos From alex at alex.org.uk Sun Apr 10 00:59:51 2016 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 9 Apr 2016 23:59:51 +0100 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: <1460137463.1794.15.camel@gnutls.org> References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> <1460137463.1794.15.camel@gnutls.org> Message-ID: Nikos, On 8 Apr 2016, at 18:44, Nikos Mavrogiannopoulos wrote: >>> >>> The simplest example is mini-eagain.c from the test suite which >>> verifies the asynchronous operation of gnutls_record_send and recv. >> Thanks - that was helpful. But it doesn't do a select loop >> as far as I can tell. > > No. A select loop will be complex and I don't know if one could have a > reasonable example. If you have one consider contributing it. I do now: https://github.com/abligh/tlsproxy I've tried to keep it pretty simple, and put all the crypto stuff in one place (crypto.c). In essence, it's a very simple version of stunnel. I've tested compilation on Linux (only). It's designed to work with older GnuTLS libraries as well. You're welcome to use it. I'm not convinced I've done all the GnuTLS stuff right (it's my first attempt at a 'from scratch' piece of GnuTLS code). In particular I *think* I'm handling GNUTLS_E_AGAIN, GNUTLS_E_INTERRUPTED and gnutls_record_check_pending right, but I'm sure they could do with a quick look over. Also I am conscious my X.509 handling is simplistic (meaning 'borrowed wholesale from the examples'). I've checked it with a few homemade certificates and it seems to do what it says. It's MIT licensed at the moment. I think some of your examples are GPL and some are in the public domain. Hope that's OK. If not, do shout. -- Alex Bligh From nmav at gnutls.org Mon Apr 11 09:21:44 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 11 Apr 2016 09:21:44 +0200 Subject: [gnutls-help] gnutls 3.4.11 Message-ID: <1460359304.1786.13.camel@gnutls.org> Hello, I've just released gnutls 3.4.11. This is a bug fix release of the current stable branch. * Version 3.4.11 (released 2016-04-11) ** libgnutls: Fixes in gnutls_record_get/set_state() with DTLS. Reported by Fridolin Pokorny. ** libgnutls: Fixes in DSA key generation under PKCS #11. Report and patches by Jan Vcelak. ** libgnutls: Corrected behavior of ALPN extension parsing during session resumption. Report and patches by Yuriy M. Kaminskiy. ** libgnutls: Corrected regression (since 3.4.0) in gnutls_server_name_set() which caused it not to accept non-null- terminated hostnames. Reported by Tim Ruehsen. ** libgnutls: Corrected printing of the IP Adress name constraints. ** ocsptool: use HTTP/1.0 for requests. This avoids issue with servers serving chunk encoding which ocsptool doesn't support. Reported by Thomas Klute. ** certtool: do not require a CA for OCSP signing tag. This follows the recommendations in RFC6960 in 4.2.2.2 which allow a CA to delegate OCSP signing to another certificate without requiring it to be a CA. Reported by Thomas Klute. ** API and ABI modifications: No changes since last version. 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.4/gnutls-3.4.11.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.11.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 Thu Apr 14 10:49:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 14 Apr 2016 10:49:29 +0200 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> <1460137463.1794.15.camel@gnutls.org> Message-ID: On Sun, Apr 10, 2016 at 12:59 AM, Alex Bligh wrote: > Nikos, > On 8 Apr 2016, at 18:44, Nikos Mavrogiannopoulos wrote: >>>> >>>> The simplest example is mini-eagain.c from the test suite which >>>> verifies the asynchronous operation of gnutls_record_send and recv. >>> Thanks - that was helpful. But it doesn't do a select loop >>> as far as I can tell. >> >> No. A select loop will be complex and I don't know if one could have a >> reasonable example. If you have one consider contributing it. > > I do now: > https://github.com/abligh/tlsproxy Thank you. That seems quite a nice and concise example, although it is not as small (1-3 pages) to include in the manual. I've added a reference instead and included it in gnutls as a submodule under doc/examples/tlsproxy. Do you plan to keep/update that repository? regards, Nikos PS. Few comments: I would not use select() any more. It is hard to get right and under glibc it causes stack overflow if any of the fds is over 1024. You could further simplify the example by using gnutls_certificate_verification_status_print() instead of checking statuses manually (that would introduce dependency to gnutls over 3.1.4, but it is future proof with regards to message reporting). You seem to call gnutls_bye() unconditionally. It may be better to send gnutls_alert_send_appropriate() on error condition, and gnutls_bye() with _WR only, since you are not interested in properly closing the channel at this point. RDWR is suitable for the cases that you want to close the channel and re-use it (send unencrypted data). regards, Nikos From alex at alex.org.uk Thu Apr 14 11:00:15 2016 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 14 Apr 2016 10:00:15 +0100 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> <1460137463.1794.15.camel@gnutls.org> Message-ID: Nikos, On 14 Apr 2016, at 09:49, Nikos Mavrogiannopoulos wrote: >> I do now: >> https://github.com/abligh/tlsproxy > > Thank you. That seems quite a nice and concise example, Thanks. > although it is > not as small (1-3 pages) to include in the manual. I've added a > reference instead and included it in gnutls as a submodule under > doc/examples/tlsproxy. Do you plan to keep/update that repository? Yes I do, though hopefully it won't change too often. I've submitted tlsproxy.c to nbd (network block device), so it should have at least one user. > PS. Few comments: > I would not use select() any more. It is hard to get right and under > glibc it causes stack overflow if any of the fds is over 1024. I agree. But determining whether poll / ppoll etc. is available is a pain, and in this instance there are only two FDs. I can't remember how prevalent poll is (as opposed to ppoll); perhaps I convert it to use poll(). > You could further simplify the example by using > gnutls_certificate_verification_status_print() instead of checking > statuses manually (that would introduce dependency to gnutls over > 3.1.4, but it is future proof with regards to message reporting). Again I agree, but I wanted this to compile on LTS Ubuntu (currently 14.04) which ships with 2.12.23-12ubuntu2.4 (unfortunately). > You seem to call gnutls_bye() unconditionally. It may be better to > send gnutls_alert_send_appropriate() on error condition, and > gnutls_bye() with _WR only, since you are not interested in properly > closing the channel at this point. RDWR is suitable for the cases that > you want to close the channel and re-use it (send unencrypted data). OK I should probably look at that one, thanks. -- Alex Bligh From nmav at gnutls.org Thu Apr 14 11:09:47 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 14 Apr 2016 11:09:47 +0200 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> <1460137463.1794.15.camel@gnutls.org> Message-ID: On Thu, Apr 14, 2016 at 11:00 AM, Alex Bligh wrote: > I agree. But determining whether poll / ppoll etc. is available > is a pain, and in this instance there are only two FDs. I > can't remember how prevalent poll is (as opposed to ppoll); > perhaps I convert it to use poll(). Note that the limitation of select is on the actual fd value, not on the number of fds. I happened to have a select() call with 2 input fds and had occasional crashes to my program. The culprit was that overall the program had many open fds and this particular code although it was using 2 fds, they often happened to be over 1024. Note that this is not really about your example. I just wanted to rant about it :) After my experience I've already convinced the manpages maintainer to add a strong language against select() early in the man page. >> You could further simplify the example by using >> gnutls_certificate_verification_status_print() instead of checking >> statuses manually (that would introduce dependency to gnutls over >> 3.1.4, but it is future proof with regards to message reporting). > Again I agree, but I wanted this to compile on LTS Ubuntu > (currently 14.04) which ships with 2.12.23-12ubuntu2.4 (unfortunately). ouch. regards, Nikos From alex at alex.org.uk Thu Apr 14 11:29:16 2016 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 14 Apr 2016 10:29:16 +0100 Subject: [gnutls-help] Truly non-blocking example of gnutls usage In-Reply-To: References: <17D66C15-8DC2-41B5-ACE4-37BE04F94387@alex.org.uk> <5645FC4A-D090-4946-A49D-C6CF54DC76CC@alex.org.uk> <1460137463.1794.15.camel@gnutls.org> Message-ID: <5E8B9B63-9636-40FE-9F41-DF432158F234@alex.org.uk> On 14 Apr 2016, at 10:09, Nikos Mavrogiannopoulos wrote: > Note that the limitation of select is on the actual fd value, not on > the number of fds. I happened to have a select() call with 2 input fds > and had occasional crashes to my program. The culprit was that overall > the program had many open fds and this particular code although it was > using 2 fds, they often happened to be over 1024. > > Note that this is not really about your example. I just wanted to rant > about it :) After my experience I've already convinced the manpages > maintainer to add a strong language against select() early in the man > page. Indeed. This is why, on reflection, it's probably worth me fixing it. -- Alex Bligh From jonetsu at teksavvy.com Fri Apr 15 16:15:18 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 15 Apr 2016 10:15:18 -0400 Subject: [gnutls-help] Does GnuTLS support NIST SP 800-56B ? Message-ID: <2f7d894babb295cc7263270f05538ca8@teksavvy.com> Hello, Does GnuTLS support NIST SP 800-56B recommendation for pair-wise key establishment schemes using integer factorization cryptography ? eg.: http://csrc.nist.gov/publications/nistpubs/800-56B/sp800-56B.pdf Thanks. From rick at openfortress.nl Mon Apr 25 13:26:34 2016 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 25 Apr 2016 13:26:34 +0200 Subject: [gnutls-help] DANE caching with dane_state_t Message-ID: <571DFEEA.3020306@openfortress.nl> Hello, I am not certain how to use dane_state_t. I found Note that the dane_state_t structure that is accepted by both verification functions is optional. It is required when many queries are performed to facilitate caching. The following flags are returned by the verify functions to indicate the status of the verification. I assume it is not really "required" under this vague ("many queries") constraint. I would however like to use caching. Should I [A] use a separate dane_state_t on each query, with its own dane_state_init() and dane_state_deinit() around it, or [B] share one setup by dane_state_init() when initialising my program and one dane_state_deinit() when tearing it up? Thanks, -Rick From nmav at gnutls.org Tue Apr 26 09:21:32 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 26 Apr 2016 09:21:32 +0200 Subject: [gnutls-help] DANE caching with dane_state_t In-Reply-To: <571DFEEA.3020306@openfortress.nl> References: <571DFEEA.3020306@openfortress.nl> Message-ID: On Mon, Apr 25, 2016 at 1:26 PM, Rick van Rein wrote: > Hello, Hi Rick, > I am not certain how to use dane_state_t. I found > Note that the dane_state_t structure that is accepted by > both verification functions is optional. It is required > when many queries are performed to facilitate caching. The > following flags are returned by the verify functions to > indicate the status of the verification. > I assume it is not really "required" under this vague ("many queries") > constraint. Indeed. The text is too vague. What about "Note that the dane_state_t structure that is accepted by both verification functions is optional. It is required when many queries are performed to optimize against multiple re-initializations of the resolving back-end and loading of DNSSEC keys." Is that more clear? > I would however like to use caching. Should I > [A] use a separate dane_state_t on each query, with its own > dane_state_init() and dane_state_deinit() around it, or > [B] share one setup by dane_state_init() when initialising my > program and one dane_state_deinit() when tearing it up? The intention is to be able to re-use the state for multiple resolvings. regards, Nikos From jonetsu at teksavvy.com Thu Apr 28 23:43:42 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Thu, 28 Apr 2016 17:43:42 -0400 Subject: [gnutls-help] OCSP functionality in GnutTLS Message-ID: <8d50ac42066548f011dca60f04a1b5dd@teksavvy.com> Can you please shed a light on the following basic use case regarding OCSP ?? When TLS is used, as for instance rsyslog is using it to establish a secure remote logging communication, using certificates, is the certification validation using OCSP automatically handled by GnuTLS ?? Eg. is it transparent to the application, or should the application add GnuTLS calls to handle it ? Thanks. From nmav at gnutls.org Fri Apr 29 08:55:54 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 29 Apr 2016 08:55:54 +0200 Subject: [gnutls-help] OCSP functionality in GnutTLS In-Reply-To: <8d50ac42066548f011dca60f04a1b5dd@teksavvy.com> References: <8d50ac42066548f011dca60f04a1b5dd@teksavvy.com> Message-ID: On Thu, Apr 28, 2016 at 11:43 PM, jonetsu wrote: > Can you please shed a light on the following basic use case > regarding OCSP ? When TLS is used, as for instance rsyslog is > using it to establish a secure remote logging communication, > using certificates, is the certification validation using OCSP > automatically handled by GnuTLS ? Eg. is it transparent to the > application, or should the application add GnuTLS calls to handle > it ? The OCSP verification is transparent only when the server is using the certificate status request TLS extension (aka OCSP stapling). Otherwise the application has to handle the communication with the OCSP server. regards, Nikos From jonetsu at teksavvy.com Fri Apr 29 16:44:19 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 29 Apr 2016 10:44:19 -0400 Subject: [gnutls-help] Disabling all uses of elliptical curves Message-ID: Hello, It was suggested previously to compile with the '--disable-ecdhe' option to disable the use of elliptical curves.? Will this compile option effectively get rid of all and every uses of elliptical curves or will there still be some uses allowed ? Thanks.