From ranpengui at gmail.com Fri Apr 3 09:52:58 2015 From: ranpengui at gmail.com (pengui ran) Date: Fri, 3 Apr 2015 15:52:58 +0800 Subject: [gnutls-help] =?utf-8?q?Does_GnuTLS_support_path_discovery?= =?utf-8?b?77yf?= Message-ID: Dear everyone, I am currently trying to test SSL implementations with PKITS. We already done the Path Validation part and trying to do the Path Discovery part. The questions is *I can't find the right APIs for Path Discovery. Does GnuTLS support Path Discovery*(automatically locate/download the intermediate certs CRLs) and verify the target cert? And does any other SSL implementations support this, like openssl, polarssl? Please help, I am confused. Best regards, Ranpengui -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranpengui at gmail.com Fri Apr 3 09:34:38 2015 From: ranpengui at gmail.com (pengui ran) Date: Fri, 3 Apr 2015 15:34:38 +0800 Subject: [gnutls-help] =?utf-8?q?CAN_GnuTLS_support_path_discovery?= =?utf-8?b?77yf?= Message-ID: Dear everyone, I am currently trying to test SSL implementations with PKITS. We already done the Path Validation part and trying to do the Path Discovery part. The questions is *I can't find the right APIs for Path Discovery. Does GnuTLS support Path Discovery*(automatically locate/download the intermediate certs CRLs) and verify the target cert? And does any other SSL implementations support this, like openssl, polarssl? Please help, I am confused. Best regards, Ranpengui -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Apr 8 08:35:42 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 08 Apr 2015 08:35:42 +0200 Subject: [gnutls-help] GnuTLS 3.4.0 released Message-ID: <1428474942.4991.7.camel@gnutls.org> We are proud to announce a new GnuTLS release: Version 3.4.0. GnuTLS is a modern C library that implements the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and as well as Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2 (or later). The "extra" GnuTLS library (which contains), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnutls.org/ What's New ========== Version 3.4.0 is the first stable release on the 3.4.x branch and is the result of a year of planning and work [0] on the git master branch. The GnuTLS 3.4.x branch is marked as stable-next, meaning it is considered of stable quality but will not yet replace the current stable releases based on 3.3.0, which will continue to be supported. [0]. https://gitlab.com/gnutls/gnutls/wikis/Plan3_4 * Version 3.4.0 ** libgnutls: Added support for AES-CCM and AES-CCM-8 (RFC6655 and RFC7251) ciphersuites. The former are enabled by default, the latter need to be explicitly enabled, since they reduce the overall security level. ** libgnutls: Added support for Chacha20-Poly1305 ciphersuites following draft-mavrogiannopoulos-chacha-tls-05 and draft-irtf-cfrg-chacha20-poly1305-10. That is currently provided as technology preview and is not enabled by default, since there are no assigned ciphersuite points by IETF and there is no guarrantee of compatibility between draft versions. The ciphersuite priority string to enable it is "+CHACHA20-POLY1305". ** libgnutls: Added support for encrypt-then-authenticate in CBC ciphersuites (RFC7366 -taking into account its errata text). This is enabled by default and can be disabled using the %NO_ETM priority string. ** libgnutls: Added support for the extended master secret (triple-handshake fix) following draft-ietf-tls-session-hash-02. ** libgnutls: Added a new simple and hard to misuse AEAD API (crypto.h). ** libgnutls: SSL 3.0 is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+VERS-SSL3.0". ** libgnutls: ARCFOUR (RC4) is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+ARCFOUR-128". ** libgnutls: DSA signatures and DHE-DSS are no longer included in the default priorities list. They have to be explicitly enabled, e.g., with a string like "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1". The DSA ciphersuites were dropped because they had no deployment at all on the internet, to justify their inclusion. ** libgnutls: The priority string EXPORT was completely removed. The string was already defunc as support for the EXPORT ciphersuites was removed in GnuTLS 3.2.0. ** libgnutls: Added API to utilize system specific private keys in "gnutls/system-keys.h". It is currently provided as technology preview and is restricted to windows CNG keys. ** libgnutls: gnutls_x509_crt_check_hostname() and friends will use RFC6125 comparison of hostnames. That introduces a dependency on libidn. ** libgnutls: Depend on p11-kit 0.23.1 to comply with the final PKCS #11 URLs draft (draft-pechanec-pkcs11uri-21). ** libgnutls: Depend on nettle 3.1. ** libgnutls: Use getrandom() or getentropy() when available. That avoids the complexity of file descriptor handling and issues with applications closing all open file descriptors on startup. ** libgnutls: Use pthread_atfork() to detect fork when available. ** libgnutls: The gnutls_handshake() process will enforce a timeout by default. ** libgnutls: If a key purpose (extended key usage) is specified for verification, it is applied into intermediate certificates. The verification result GNUTLS_CERT_PURPOSE_MISMATCH is also introduced. ** libgnutls: When gnutls_certificate_set_x509_key_file2() is used in combination with PKCS #11, or TPM URLs, it will utilize the provided password as PIN if required. That removes the requirement for the application to set a callback for PINs in that case. ** libgnutls: priority strings VERS-TLS-ALL and VERS-DTLS-ALL are restricted to the corresponding protocols only, and the VERS-ALL string is introduced to catch all possible protocols. ** libgnutls: Added helper functions to obtain information on PKCS #8 structures. ** libgnutls: Certificate chains which are provided to gnutls_certificate_credentials_t will automatically be sorted instead of failing with GNUTLS_E_CERTIFICATE_LIST_UNSORTED. ** libgnutls: Added functions to export and set the record state. That allows for gnutls_record_send() and recv() to be offloaded (to kernel, hardware or any other subsystem). ** libgnutls: Added the ability to register application specific URL types, which express certificates and keys using gnutls_register_custom_url(). ** libgnutls: Added API to override existing ciphers, digests and MACs, e.g., to override AES-GCM using a system-specific accelerator. That is, (crypto.h) gnutls_crypto_register_cipher(), gnutls_crypto_register_aead_cipher(), gnutls_crypto_register_mac(), and gnutls_crypto_register_digest(). ** libgnutls: Added gnutls_ext_register() to register custom extensions. Contributed by Thierry Quemerais. ** libgnutls: Added gnutls_supplemental_register() to register custom supplemental data handshake messages. Contributed by Thierry Quemerais. ** libgnutls-openssl: it is no longer built by default. ** certtool: Added --p8-info option, which will print PKCS #8 information even if the password is not available. ** certtool: --key-info option will print PKCS #8 encryption information when available. ** certtool: Added the --key-id and --fingerprint options. ** certtool: Added the --verify-hostname, --verify-email and --verify-purpose options to be used in certificate chain verification, to simulate verification for specific hostname and key purpose (extended key usage). ** certtool: --p12-info option will print PKCS #12 MAC and cipher information when available. ** certtool: it will print the A-label (ACE) names in addition to UTF-8. ** p11tool: added options --set-id and --set-label. ** gnutls-cli: added options --priority-list and --save-cert. ** guile: Deprecated priority API has been removed. The old priority API, which had been deprecated for some time, is now gone; use 'set-session-priorities!' instead. ** guile: Remove RSA parameters and related procedures. This API had been deprecated. ** guile: Fix compilation on MinGW. Previously only the static version of the 'guile-gnutls-v-2' library would be built, preventing dynamic loading from Guile. ** API and ABI modifications: Many new additions and removals of obsolete functions. Check the NEWS file in the distribution. Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnutls.org/mailman/listinfo/gnutls-help If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnutls.org/mailman/listinfo/gnutls-dev Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From ranpengui at gmail.com Fri Apr 10 08:37:36 2015 From: ranpengui at gmail.com (pengui ran) Date: Fri, 10 Apr 2015 14:37:36 +0800 Subject: [gnutls-help] =?utf-8?q?Does_GnuTLS_support_path_discovery?= =?utf-8?b?77yf?= In-Reply-To: References: Message-ID: Hello ~~ Anyone know this? I just wanna know whether *GnuTLS support path discovery or not*? Best regards, Ranpengui 2015-04-03 15:52 GMT+08:00 pengui ran : > Dear everyone, > > > I am currently trying to test SSL implementations with PKITS. We already > done the Path Validation part and trying to do the Path Discovery part. > > The questions is *I can't find the right APIs for Path Discovery. Does > GnuTLS support Path Discovery*(automatically locate/download the > intermediate certs CRLs) and verify the target cert? > > And does any other SSL implementations support this, like > openssl, polarssl? > > Please help, I am confused. > > Best regards, > Ranpengui > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Apr 10 16:27:06 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Apr 2015 17:27:06 +0300 Subject: [gnutls-help] =?utf-8?q?=5Bgnutls-devel=5D_Does_GnuTLS_support_pa?= =?utf-8?b?dGggZGlzY292ZXJ577yf?= In-Reply-To: References: Message-ID: On Fri, Apr 10, 2015 at 9:37 AM, pengui ran wrote: > Hello ~~ Anyone know this? > I just wanna know whether GnuTLS support path discovery or not? No. From rrusso at lsu.edu Wed Apr 15 20:45:38 2015 From: rrusso at lsu.edu (Robert) Date: Wed, 15 Apr 2015 18:45:38 +0000 (UTC) Subject: [gnutls-help] gnutls-cli - handshake failed References: <1420754479.11467.1.camel@gnutls.org> Message-ID: Nikos Mavrogiannopoulos gnutls.org> writes: > > There is no point to try debugging such an old version of gnutls; the > best is to use a more modern version (the 2.12 branch is from 2011). > > regards, > Nikos > Normally I would agree with you, but 2.12.23 is the version on Ubuntu 14.04 and several of our vendors use the 14.04 LTS version of ubuntu. From nmav at gnutls.org Thu Apr 16 10:19:36 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Apr 2015 11:19:36 +0300 Subject: [gnutls-help] gnutls-cli - handshake failed In-Reply-To: References: <1420754479.11467.1.camel@gnutls.org> Message-ID: <1429172376.4364.4.camel@gnutls.org> On Wed, 2015-04-15 at 18:45 +0000, Robert wrote: > > There is no point to try debugging such an old version of gnutls; the > > best is to use a more modern version (the 2.12 branch is from 2011). > Normally I would agree with you, but 2.12.23 is the version on Ubuntu 14.04 > and several of our vendors use the 14.04 LTS version of ubuntu. In that case the issues should be reported to ubuntu. Even if there is a fix for the issue, there will not be a new gnutls 2.12 release (unless of course there is a maintainer for that branch, but no-one has shown interest for that so far). regards, Nikos From jonetsu at teksavvy.com Thu Apr 16 21:11:24 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Thu, 16 Apr 2015 15:11:24 -0400 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 Message-ID: Hello, ? According to recent FIPS documentation, TLS v1.0 is no longer permitted.? Would it be possible to have it removed ?? Last time i checked it was listed when doing a : GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL. Regards. From nmav at gnutls.org Fri Apr 17 12:18:51 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Apr 2015 13:18:51 +0300 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 In-Reply-To: References: Message-ID: <1429265931.2453.1.camel@gnutls.org> On Thu, 2015-04-16 at 15:11 -0400, jonetsu wrote: > Hello, > > According to recent FIPS documentation, TLS v1.0 is no longer permitted. Would it be possible to have it removed ? Last time i checked it was listed when doing a : GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL. Could you be more specific about the FIPS documentation that forbids TLS 1.0? Which document forbids that, and where is it referenced in FIPS140-2? regards, Nikos From jonetsu at teksavvy.com Fri Apr 17 13:53:24 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 17 Apr 2015 07:53:24 -0400 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 In-Reply-To: <1429265931.2453.1.camel@gnutls.org> References: <1429265931.2453.1.camel@gnutls.org> Message-ID: <5a98ce6cf5c9cc554716226fa1a29d24@teksavvy.com> > From: "Nikos Mavrogiannopoulos" > Date: 04/17/15 06:19 > > On Thu, 2015-04-16 at 15:11 -0400, jonetsu wrote: > > Hello, > > > > ? According to recent FIPS documentation, TLS v1.0 is no longer permitted. ?Would it be possible to have it removed ? ?Last time i checked it was listed when doing a : GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL. ? > Could you be more specific about the FIPS documentation that forbids TLS > 1.0? Which document forbids that, and where is it referenced in > FIPS140-2? I got a brief from a consultancy.? I should get details today or next week.? It has to do with a recent NDcPP.? I'll post more details when I get them. Regards. From gnutls+etherape at kernelbug.org Sun Apr 19 11:38:54 2015 From: gnutls+etherape at kernelbug.org (Victorian Spirit) Date: Sun, 19 Apr 2015 11:38:54 +0200 Subject: [gnutls-help] CRL revoked certs ignored Message-ID: <20150419093853.GA16719@kernelbug.org> Dear all, I'm trying to get slapd (compiled against libgnutls) working with CRL checking. So i created a CRL via certtool based on a cert i want to revoke. In slapd i used 'TLSCRLFile' this seems to be ignored. To make sure gnutls is not the issue i tested CRL via gnutls-cli / gnutls-serv Server: gnutls-serv --x509keyfile=clients/lrc-ldap.key \ --x509certfile=clients/lrc-ldap.crt \ --x509crlfile=crl.pem \ --x509cafile=ca-cert.pem --echo client: gnutls-cli --x509cafile=../ca-cert.pem lrc-ldap -p5556 \ --x509certfile=lrc-ldapsearch.crt \ --x509crlfile=../crl.pem The client certificate is revoked and the CRL is verified with success, certtool --generate-crl --load-ca-privkey=ca-key.pem --load-ca-certificate=ca-cert.pem --outfile=crl.pem certtool --verify-crl --load-ca-certificate ca-cert.pem < crl.pem Still the client can establish a connection. I hope i didn't miss something obvious but i'm working on this for two days already and i'm completely stuck. Many thanks, Etherape From nmav at gnutls.org Mon Apr 20 12:40:57 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Apr 2015 12:40:57 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: <20150419093853.GA16719@kernelbug.org> References: <20150419093853.GA16719@kernelbug.org> Message-ID: On Sun, Apr 19, 2015 at 11:38 AM, Victorian Spirit wrote: > Dear all, > I'm trying to get slapd (compiled against libgnutls) working with CRL checking. > So i created a CRL via certtool based on a cert i want to revoke. > In slapd i used 'TLSCRLFile' this seems to be ignored. > The client certificate is revoked and the CRL is verified with success, > certtool --generate-crl --load-ca-privkey=ca-key.pem --load-ca-certificate=ca-cert.pem --outfile=crl.pem This command generates an empty CRL. What is the output of crl-info? For an example to generate a CRL using certtool see "Certificate revocation list generation" in http://www.gnutls.org/manual/html_node/certtool-Invocation.html > gnutls-serv --x509keyfile=clients/lrc-ldap.key \ > --x509certfile=clients/lrc-ldap.crt \ > --x509crlfile=crl.pem \ > --x509cafile=ca-cert.pem --echo This command does not verify the client certificate. To enable client certificate verification use "-r" or --verify-client-cert. regards, Nikos From gnutls+etherape at kernelbug.org Mon Apr 20 13:18:54 2015 From: gnutls+etherape at kernelbug.org (gnutls+etherape at kernelbug.org) Date: Mon, 20 Apr 2015 13:18:54 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: References: <20150419093853.GA16719@kernelbug.org> Message-ID: <20150420111854.GA6581@kernelbug.org> Hmm i see i didn't put the last working CRL generate command there, this is what i did yesterday, certtool --generate-crl --load-ca-privkey=ca-key.pem \ --load-ca-certificate=ca-cert.pem \ --load-certificate lrc-ldap_client.gnutls.crt \ --outfile=crl.pem So lrc-ldap_client.gnutls.crt should be revoked, right? I'm running the server now with verify-client (the same server command but extended with --verify-client-cert Client: ------ - Status: The certificate is trusted. - Successfully sent 0 certificate(s) to server. - Description: (TLS1.2)-(ECDHE-RSA-SECP192R1)-(AES-128-GCM) - Session ID: E3:9C:29:DA:E4:86:FC:74:6B:19:62:DF:25:BA:E6:53:DD:97:8A:98:8B:1B:40:9A:A0:AB:C7:01:A4:54:C8:BD - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP192R1 - Curve size: 192 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-128-GCM - MAC: AEAD - Compression: NULL - Handshake was completed Server: ------ Processed 1 CA certificate(s). Processed 1 CRL(s). Echo Server listening on IPv4 0.0.0.0 port 5556...done Echo Server listening on IPv6 :: port 5556...done * Accepted connection from IPv4 10.50.2.12 port 48559 on Mon Apr 20 13:06:31 2015 - Description: (TLS1.2)-(ECDHE-RSA-SECP192R1)-(AES-128-GCM) - Session ID: 13:74:51:E3:69:B6:CB:02:07:38:A1:A8:40:42:00:70:BF:A4:98:C4:BC:D7:FE:F8:D4:7E:B0:86:A7:8F:ED:23 - Given server name[1]: lrc-ldap No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP192R1 - Curve size: 192 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-128-GCM - MAC: AEAD - Compression: NULL - Channel binding 'tls-unique': 17480355da49f20e21775f7c It's interesting that the server now says 'No certificates found!' i don't know if this has something to do with the revocation. But still i'm able to write data to the server which is received. client: - Simple Client Mode: asd asd Server: *** Processing 4 bytes command: asd Regards, Etherape On Mon, Apr 20, 2015 at 12:40:57PM +0200, Nikos Mavrogiannopoulos wrote: > On Sun, Apr 19, 2015 at 11:38 AM, Victorian Spirit > wrote: > > Dear all, > > I'm trying to get slapd (compiled against libgnutls) working with CRL checking. > > So i created a CRL via certtool based on a cert i want to revoke. > > In slapd i used 'TLSCRLFile' this seems to be ignored. > > The client certificate is revoked and the CRL is verified with success, > > certtool --generate-crl --load-ca-privkey=ca-key.pem --load-ca-certificate=ca-cert.pem --outfile=crl.pem > > This command generates an empty CRL. What is the output of crl-info? > For an example to generate a CRL using certtool see "Certificate > revocation list generation" in > http://www.gnutls.org/manual/html_node/certtool-Invocation.html > > > gnutls-serv --x509keyfile=clients/lrc-ldap.key \ > > --x509certfile=clients/lrc-ldap.crt \ > > --x509crlfile=crl.pem \ > > --x509cafile=ca-cert.pem --echo > > This command does not verify the client certificate. To enable client > certificate verification use "-r" or --verify-client-cert. > > regards, > Nikos > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From nmav at gnutls.org Mon Apr 20 13:11:24 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Apr 2015 13:11:24 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: <20150420111854.GA6581@kernelbug.org> References: <20150419093853.GA16719@kernelbug.org> <20150420111854.GA6581@kernelbug.org> Message-ID: On Mon, Apr 20, 2015 at 1:18 PM, wrote: > Hmm i see i didn't put the last working CRL generate command there, this is what i did yesterday, > > certtool --generate-crl --load-ca-privkey=ca-key.pem \ > --load-ca-certificate=ca-cert.pem \ > --load-certificate lrc-ldap_client.gnutls.crt \ > --outfile=crl.pem > So lrc-ldap_client.gnutls.crt should be revoked, right? Correct. > * Accepted connection from IPv4 10.50.2.12 port 48559 on Mon Apr 20 13:06:31 2015 > - Description: (TLS1.2)-(ECDHE-RSA-SECP192R1)-(AES-128-GCM) > - Session ID: 13:74:51:E3:69:B6:CB:02:07:38:A1:A8:40:42:00:70:BF:A4:98:C4:BC:D7:FE:F8:D4:7E:B0:86:A7:8F:ED:23 > - Given server name[1]: lrc-ldap > No certificates found! > - Ephemeral EC Diffie-Hellman parameters > - Using curve: SECP192R1 > - Curve size: 192 bits > - Version: TLS1.2 > - Key Exchange: ECDHE-RSA > - Server Signature: RSA-SHA256 > - Cipher: AES-128-GCM > - MAC: AEAD > - Compression: NULL > - Channel binding 'tls-unique': 17480355da49f20e21775f7c > It's interesting that the server now says 'No certificates found!' i don't know if this has something to do with the revocation. > But still i'm able to write data to the server which is received. That message means that the client didn't send any certificates. Use "-r" on gnutls-serv to force the client send its certificate. regards, Nikos From debian-user+Etherape at kernelbug.org Mon Apr 20 14:10:46 2015 From: debian-user+Etherape at kernelbug.org (Dark Victorian Spirit) Date: Mon, 20 Apr 2015 14:10:46 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: References: <20150419093853.GA16719@kernelbug.org> <20150420111854.GA6581@kernelbug.org> Message-ID: <20150420121045.GC6581@kernelbug.org> Cool! That's clear. In the gnutlc-cli command i can't find how to send a certificate. Which option should be used for that? On Mon, Apr 20, 2015 at 01:11:24PM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, Apr 20, 2015 at 1:18 PM, wrote: > > Hmm i see i didn't put the last working CRL generate command there, this is what i did yesterday, > > > > certtool --generate-crl --load-ca-privkey=ca-key.pem \ > > --load-ca-certificate=ca-cert.pem \ > > --load-certificate lrc-ldap_client.gnutls.crt \ > > --outfile=crl.pem > > So lrc-ldap_client.gnutls.crt should be revoked, right? > > Correct. > > > * Accepted connection from IPv4 10.50.2.12 port 48559 on Mon Apr 20 13:06:31 2015 > > - Description: (TLS1.2)-(ECDHE-RSA-SECP192R1)-(AES-128-GCM) > > - Session ID: 13:74:51:E3:69:B6:CB:02:07:38:A1:A8:40:42:00:70:BF:A4:98:C4:BC:D7:FE:F8:D4:7E:B0:86:A7:8F:ED:23 > > - Given server name[1]: lrc-ldap > > No certificates found! > > - Ephemeral EC Diffie-Hellman parameters > > - Using curve: SECP192R1 > > - Curve size: 192 bits > > - Version: TLS1.2 > > - Key Exchange: ECDHE-RSA > > - Server Signature: RSA-SHA256 > > - Cipher: AES-128-GCM > > - MAC: AEAD > > - Compression: NULL > > - Channel binding 'tls-unique': 17480355da49f20e21775f7c > > It's interesting that the server now says 'No certificates found!' i don't know if this has something to do with the revocation. > > But still i'm able to write data to the server which is received. > > That message means that the client didn't send any certificates. Use > "-r" on gnutls-serv to force the client send its certificate. > > regards, > Nikos > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From nmav at gnutls.org Mon Apr 20 16:29:09 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Apr 2015 16:29:09 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: <20150420121045.GC6581@kernelbug.org> References: <20150419093853.GA16719@kernelbug.org> <20150420111854.GA6581@kernelbug.org> <20150420121045.GC6581@kernelbug.org> Message-ID: On Mon, Apr 20, 2015 at 2:10 PM, Dark Victorian Spirit wrote: > Cool! That's clear. > In the gnutlc-cli command i can't find how to send a certificate. > Which option should be used for that? You need --x509certfile and --x509keyfile. From gnutls+etherape at kernelbug.org Mon Apr 20 17:13:47 2015 From: gnutls+etherape at kernelbug.org (gnutls+etherape at kernelbug.org) Date: Mon, 20 Apr 2015 17:13:47 +0200 Subject: [gnutls-help] CRL revoked certs ignored In-Reply-To: References: <20150419093853.GA16719@kernelbug.org> <20150420111854.GA6581@kernelbug.org> <20150420121045.GC6581@kernelbug.org> Message-ID: <20150420151346.GA9342@kernelbug.org> Nice, this works!! Using the keyfile is the solution. My next step is to get this working with ldapsearch, sssd & slapd. There this scenario doesn't work yet. But now i know for sure that gnutls is doing its job well. Many thanks! On Mon, Apr 20, 2015 at 04:29:09PM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, Apr 20, 2015 at 2:10 PM, Dark Victorian Spirit > wrote: > > Cool! That's clear. > > In the gnutlc-cli command i can't find how to send a certificate. > > Which option should be used for that? > > You need --x509certfile and --x509keyfile. From mattroisang at gmail.com Tue Apr 21 22:52:51 2015 From: mattroisang at gmail.com (Mat Troi) Date: Tue, 21 Apr 2015 13:52:51 -0700 Subject: [gnutls-help] Is GnuTLS version 3.4 backward compatible with 2.8.6? Message-ID: Hi, We want to update our GnuTLS 2.8.6 to GnuTLS version 3.4. From looking at the online documentation, it looks like 3.4 should be backward compatible with 2.8.6 minus these deprecated/replaced functions in http://gnutls.org/manual/html_node/Compatibility-API.html. Is there anything else we should watch out for? Thanks, Mat -------------- next part -------------- An HTML attachment was scrubbed... URL: From lavr at ncbi.nlm.nih.gov Wed Apr 22 02:31:56 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Wed, 22 Apr 2015 00:31:56 +0000 Subject: [gnutls-help] Certificate callback questions Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CD06AF@msgb06.nih.gov> Hi, I've been using basic GnuTLS features until a recent fallout with certificate-based connection authentication prompted me to look into more advanced techniques such as callbacks. I would appreciate if somebody could answer these questions: 1. It's unclear to me why "gnutls_certificate_set_verify_function()" is a function of credentials rather than a session: I assumed that the same credentials added to a session via "gnutls_credentials_set()" can be reused. Which means that certificate verification will be done on any such session rather than selected on a per-session basis. I think my understanding is incomplete (yet API documentation does not provide any insight here). 2. There's something odd with the description of the "gnutls_certificate_set_retrieve_function*()" API: callbacks are documented as: int (*callback)(gnutls_session_t, const gnutls_datum_t* req_ca_dn,...) but parameter descriptions that follow (for either call) refer to nonexistent name "req_ca_cert". I assume "req_ca_dn" was meant to be there, but I'm not sure. Please confirm. Also, is there the word "key" missing after "public" in the following description: "pcert should contain a single certificate and public or a list of them." 3. Can you please explain this phrase to me: "Contains a list with the CA names that the server considers trusted. Normally we should send a certificate that is signed by one of these CAs." Is this a requirement? In other words, if my server tells me it wants a GoDaddy's issued cert, and I send a Digicert's one instead, then I should expect the server to drop the connection on me? 4. Is there a way to pass some context to a callback that is set with "gnutls_certificate_set_retrieve_function*()"? I.e. similar to "gnutls_session_set_ptr()" but for credentials. 5. If there is a certificate set in credentials (e.g. such as with "gnutls_certificate_set_x509_simple_pkcs12_file()") along with a certificate retrieval callback, what wins? I apologize if my questions are na?ve but I would appreciate any help I can get on this list. Thank you, Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Wed Apr 22 11:31:38 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 22 Apr 2015 11:31:38 +0200 Subject: [gnutls-help] Is GnuTLS version 3.4 backward compatible with 2.8.6? In-Reply-To: References: Message-ID: On Tue, Apr 21, 2015 at 10:52 PM, Mat Troi wrote: > Hi, > We want to update our GnuTLS 2.8.6 to GnuTLS version 3.4. From looking at > the online documentation, it looks like 3.4 should be backward compatible > with 2.8.6 minus these deprecated/replaced functions in > http://gnutls.org/manual/html_node/Compatibility-API.html. > Is there anything else we should watch out for? You mostly need to follow the information in that page: http://gnutls.org/manual/html_node/Upgrading-from-previous-versions.html#Upgrading-from-previous-versions regards, Nikos From nmav at gnutls.org Wed Apr 22 14:01:34 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 22 Apr 2015 14:01:34 +0200 Subject: [gnutls-help] Certificate callback questions In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D13CD06AF@msgb06.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D13CD06AF@msgb06.nih.gov> Message-ID: On Wed, Apr 22, 2015 at 2:31 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi, > I've been using basic GnuTLS features until a recent fallout with certificate-based connection authentication prompted > me to look into more advanced techniques such as callbacks. I would appreciate if somebody could answer these questions: > 1. It's unclear to me why "gnutls_certificate_set_verify_function()" is a function of credentials rather than a session: > I assumed that the same credentials added to a session via "gnutls_credentials_set()" can be reused. Which means that > certificate verification will be done on any such session rather than selected on a per-session basis. I think my > understanding is incomplete (yet API documentation does not provide any insight here). It was designed with the server mainly in mind which will typically have the same verify function for all possible clients. You can still however differentiate between sessions using gnutls_session_set/get_ptr(). Do you see an issue with this approach? > 2. There's something odd with the description of the "gnutls_certificate_set_retrieve_function*()" API: > callbacks are documented as: > int (*callback)(gnutls_session_t, const gnutls_datum_t* req_ca_dn,...) > but parameter descriptions that follow (for either call) refer to nonexistent name "req_ca_cert". I assume "req_ca_dn" > was meant to be there, but I'm not sure. Please confirm. Confirmed. I've fixed it. > Also, is there the word "key" missing after "public" in the following description: > "pcert should contain a single certificate and public or a list of them." Thanks. Fixed too. > 3. Can you please explain this phrase to me: "Contains a list with the CA names that the server considers trusted. > Normally we should send a certificate that is signed by one of these CAs." Is this a requirement? In other > words, if my server tells me it wants a GoDaddy's issued cert, and I send a Digicert's one instead, then I should > expect the server to drop the connection on me? It's up to the server to decide. You can send whatever you desire in the certificate field, but the server will have to accept it. The values you get in this callback are hints; you may use them or ignore them. Said that, for most applications the server will require a certificate that is signed by a CA it controls or trusts to authenticate its users. So sending him any random certificate wouldn't be useful to it. > 4. Is there a way to pass some context to a callback that is set with "gnutls_certificate_set_retrieve_function*()"? > I.e. similar to "gnutls_session_set_ptr()" but for credentials. Since you get a pointer to the session you can use the gnutls_session_set/get_ptr() for that. There is also gnutls_credentials_get() since gnutls 3.3.3, if I correctly understand what you mean. > 5. If there is a certificate set in credentials (e.g. such as with "gnutls_certificate_set_x509_simple_pkcs12_file()") > along with a certificate retrieval callback, what wins? Interesting question. The callback always take precedence. > I apologize if my questions are na?ve but I would appreciate any help I can get on this list. They are not. They certainly helped improve the documentation :) regards, Nikos From lavr at ncbi.nlm.nih.gov Wed Apr 22 17:31:51 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Wed, 22 Apr 2015 15:31:51 +0000 Subject: [gnutls-help] Certificate callback questions In-Reply-To: References: <5F8AAC04F9616747BC4CC0E803D5907D13CD06AF@msgb06.nih.gov> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CD081E@msgb06.nih.gov> Nikos, Thank you for your response! > You can still however differentiate between sessions using > gnutls_session_set/get_ptr(). Do you see an issue with this approach? I can, but the callback will be visited by all sessions that use that same credentials. BTW, could you please comment if the same credentials handle can be shared / reused for multiple (possibly, concurrent) sessions? It's unclear that it couldn't; and it seems to work for me just fine. > > to pass some context to a callback that is set with "gnutls_certificate_set_retrieve_function*()"? > Since you get a pointer to the session you can use the > gnutls_session_set/get_ptr() for that. And this is just a reverse situation of the certificate verification callback: it looks like retrieve is a method of credentials rather than a session. If I could treat the credentials as a container, and extract and return a suitable element out of it (i.e. there can be a handle to a file, which keeps all available certs), I would not want / need to give that handle to each and every session that use those credentials. Thank you, Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Thu Apr 23 13:19:45 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Apr 2015 13:19:45 +0200 Subject: [gnutls-help] Certificate callback questions In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D13CD081E@msgb06.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D13CD06AF@msgb06.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D13CD081E@msgb06.nih.gov> Message-ID: On Wed, Apr 22, 2015 at 5:31 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Nikos, > Thank you for your response! >> You can still however differentiate between sessions using >> gnutls_session_set/get_ptr(). Do you see an issue with this approach? > I can, but the callback will be visited by all sessions that use that same > credentials. BTW, could you please comment if the same credentials handle > can be shared / reused for multiple (possibly, concurrent) sessions? Yes. That is the purpose of credentials structures, to be re-used by multiple sessions. >> > to pass some context to a callback that is set with "gnutls_certificate_set_retrieve_function*()"? >> Since you get a pointer to the session you can use the >> gnutls_session_set/get_ptr() for that. > And this is just a reverse situation of the certificate verification callback: > it looks like retrieve is a method of credentials rather than a session. It is set on credentials but called by and with the session structure. > If I could > treat the credentials as a container, and extract and return a suitable element out of > it (i.e. there can be a handle to a file, which keeps all available certs), I would not > want / need to give that handle to each and every session that use those credentials. I'm not sure I follow. In that case wouldn't be better to use different credentials structures for different sessions? regards, Nikos From jonetsu at teksavvy.com Fri Apr 24 16:08:35 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 24 Apr 2015 10:08:35 -0400 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 + reference Message-ID: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com> Hello, ? Here is the reference to the exclusion of TLS 1.0: https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 Specifically: "FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0" "FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0" Regards. From nmav at gnutls.org Fri Apr 24 16:30:32 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Apr 2015 16:30:32 +0200 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 + reference In-Reply-To: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com> References: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com> Message-ID: On Fri, Apr 24, 2015 at 4:08 PM, jonetsu wrote: > Hello, > > Here is the reference to the exclusion of TLS 1.0: > https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 Thanks. This is a protection profile, but it has nothing to do with FIPS-140-2. The requirements for FIPS140-2 are specified in [0], and to the documents referred by it. I don't see you document being referred in that publication, but if it is, just let me know. regards, Nikos [0]. http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf From jonetsu at teksavvy.com Fri Apr 24 16:43:01 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 24 Apr 2015 10:43:01 -0400 Subject: [gnutls-help] GnuTLS and RNG Message-ID: <20e2f94bfbf1850596d7373bbf19bcf3@teksavvy.com> Hello, Does GnuTLS implements its own random number generator ?? If so, are there any documents describing it ? Regards. From jonetsu at teksavvy.com Fri Apr 24 16:47:29 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 24 Apr 2015 10:47:29 -0400 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 + reference In-Reply-To: References: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com> Message-ID: <6d731aa58a6e061172fb8c57ed09f774@teksavvy.com> > From: "Nikos Mavrogiannopoulos" > Date: 04/24/15 10:30 ? > Thanks. This is a protection profile, but it has nothing to do with FIPS-140-2. > The requirements for FIPS140-2 are specified in [0], and to the > documents referred by it. I don't see you document being referred in > that publication, but if it is, just let me know. > [0]. http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf Thanks.? There is something to be cleared about this.? I'll get back with more details.? Meanwhile, would it be possibl to compile GnuTLS w/o TLS 1.0 and SSL 3.0 support, while FIPS mode would take care of the rest ? Regards. From lavr at ncbi.nlm.nih.gov Fri Apr 24 23:20:43 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Fri, 24 Apr 2015 21:20:43 +0000 Subject: [gnutls-help] Cert retrieve callback question Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> Hi, I have code that sets cert retrieval callback with gnutls_certificate_set_retrieve_function2(), and from within that callback checks whether the server required the certificate by calling: gnutls_certificate_client_get_request_status() and expecting "non-zero". Looks like the latter returns 0 there, even though I see "CERTIFICATE REQUEST(13)" while looking at debug output: ... 04/24/15 16:55:39 GNUTLS3: HSK[0x150df00]: CERTIFICATE (11) was received. Length 3915[3915], frag offset 0, frag length: 3915, sequence: 0 04/24/15 16:55:39 3 certificates received from server <-- That's my code reports from a cert verify callback ... 04/24/15 16:55:39 GNUTLS4: REC[0x150df00]: SSL 3.3 Handshake packet received. Epoch 0, length: 6010 ... 04/24/15 16:55:39 GNUTLS6: BUF[REC]: Inserted 6010 bytes of Data(22) 04/24/15 16:55:39 GNUTLS3: HSK[0x150df00]: CERTIFICATE REQUEST (13) was received. Length 6006[6006], frag offset 0, frag length: 6006, sequence: 0 04/24/15 16:55:39 GNUTLS3: EXT[0x150df00]: rcvd signature algo (2.1) RSA-SHA1 04/24/15 16:55:39 Server does not require client authentication <-- This is my output when gnutls_certificate_client_get_request_status() returns 0 04/24/15 16:55:39 Server's 44 trusted certificate authorities: <-- There's 44 CAs sent by the server, nonetheless (it's in the retrieve callback, too) ... What I'm missing here? Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Sat Apr 25 09:08:50 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 25 Apr 2015 09:08:50 +0200 Subject: [gnutls-help] Cert retrieve callback question In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> Message-ID: <1429945730.1682.4.camel@gnutls.org> On Fri, 2015-04-24 at 21:20 +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi, > > I have code that sets cert retrieval callback with gnutls_certificate_set_retrieve_function2(), > and from within that callback checks whether the server required the certificate by calling: > gnutls_certificate_client_get_request_status() and expecting "non-zero". The value returned by this function is set after the callback is complete. I'll check to fix that, but you don't need to call this function to check whether a certificate has been requested. The callback is only called when a certificate has been requested. regards, Nikos From nmav at gnutls.org Sun Apr 26 00:32:23 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 26 Apr 2015 00:32:23 +0200 Subject: [gnutls-help] GnuTLS and RNG In-Reply-To: <20e2f94bfbf1850596d7373bbf19bcf3@teksavvy.com> References: <20e2f94bfbf1850596d7373bbf19bcf3@teksavvy.com> Message-ID: <1430001143.10139.3.camel@gnutls.org> On Fri, 2015-04-24 at 10:43 -0400, jonetsu wrote: > Hello, > > Does GnuTLS implements its own random number generator ? If so, are there any documents describing it ? It uses a salsa20 based random generator for nonces and yarrow for anything else. The source code in lib/nettle/rnd.c [0] is the reference for it, but most probably you are interested in the rnd-fips.c [1]. [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/nettle/rnd.c [1]. https://gitlab.com/gnutls/gnutls/blob/master/lib/nettle/rnd-fips.c regards, Nikos From lavr at ncbi.nlm.nih.gov Tue Apr 28 00:10:12 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Mon, 27 Apr 2015 22:10:12 +0000 Subject: [gnutls-help] Cert retrieve callback question In-Reply-To: <1429945730.1682.4.camel@gnutls.org> References: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> <1429945730.1682.4.camel@gnutls.org> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CD22CA@msgb06.nih.gov> > The callback is only called when a certificate has been requested. Thanks! Another question: how can I get the certificate and private key as they have been set by gnutls_certificate_set_x509_simple_pkcs12_file() via a credentials handle? In other words, I see that internally credentials handle is set with gnutls_certificate_set_x509_key(), but I can't find a respective getter for that. Your invaluable help is being kindly appreciated! Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Tue Apr 28 11:02:19 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 28 Apr 2015 11:02:19 +0200 Subject: [gnutls-help] Cert retrieve callback question In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D13CD22CA@msgb06.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> <1429945730.1682.4.camel@gnutls.org> <5F8AAC04F9616747BC4CC0E803D5907D13CD22CA@msgb06.nih.gov> Message-ID: On Tue, Apr 28, 2015 at 12:10 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> The callback is only called when a certificate has been requested. > Thanks! > Another question: how can I get the certificate and private key as they have been > set by gnutls_certificate_set_x509_simple_pkcs12_file() via a credentials handle? You can get these in 3.4.0 with gnutls_certificate_get_x509_key() and gnutls_certificate_get_x509_crt(). regards, Nikos From yshvedov at wimarksystems.com Tue Apr 28 11:20:05 2015 From: yshvedov at wimarksystems.com (Yury Shvedov) Date: Tue, 28 Apr 2015 12:20:05 +0300 Subject: [gnutls-help] Asynchronous transport Message-ID: <553F50C5.4060704@wimarksystems.com> Hi, I have an event-drivent system, based on libevent and extended with my own API and functionality. I'm trying to use gnutls to protect my channels with DTLS, but I'm confused with pull_timeout_function (http://gnutls.org/manual/html_node/Setting-up-the-transport-layer.html). I want to use my own asynchronous timers to tell gnutls about timeouts, but pull_timeout_function make to use select. Is there any way to get round this legally? -- Kind regards Yury Shvedov From nmav at gnutls.org Tue Apr 28 13:49:03 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 28 Apr 2015 13:49:03 +0200 Subject: [gnutls-help] Asynchronous transport In-Reply-To: <553F50C5.4060704@wimarksystems.com> References: <553F50C5.4060704@wimarksystems.com> Message-ID: On Tue, Apr 28, 2015 at 11:20 AM, Yury Shvedov wrote: > Hi, > I have an event-drivent system, based on libevent and extended with my own > API and functionality. I'm trying to use gnutls to protect my channels with > DTLS, but I'm confused with pull_timeout_function > (http://gnutls.org/manual/html_node/Setting-up-the-transport-layer.html). I > want to use my own asynchronous timers to tell gnutls about timeouts, but > pull_timeout_function make to use select. > Is there any way to get round this legally? If you are using your own event handling, wouldn't asynchronous operation be more suitable? In that case gnutls will not call the pull_timeout function. http://gnutls.org/manual/html_node/Asynchronous-operation.html#Asynchronous-operation From lavr at ncbi.nlm.nih.gov Tue Apr 28 22:17:51 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Tue, 28 Apr 2015 20:17:51 +0000 Subject: [gnutls-help] Cert retrieve callback question In-Reply-To: References: <5F8AAC04F9616747BC4CC0E803D5907D13CD0E97@msgb06.nih.gov> <1429945730.1682.4.camel@gnutls.org> <5F8AAC04F9616747BC4CC0E803D5907D13CD22CA@msgb06.nih.gov> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CD25E1@msgb06.nih.gov> > You can get these in 3.4.0 with gnutls_certificate_get_x509_key() and > gnutls_certificate_get_x509_crt(). Thanks again! Anton Lavrentiev Contractor NIH/NLM/NCBI From jonetsu at teksavvy.com Thu Apr 30 02:43:05 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Wed, 29 Apr 2015 20:43:05 -0400 Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 + reference In-Reply-To: References: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com> Message-ID: <20150429204305.09a50ed9@mevla> On Fri, 24 Apr 2015 16:30:32 +0200 Nikos Mavrogiannopoulos wrote: > On Fri, Apr 24, 2015 at 4:08 PM, jonetsu wrote: > > Hello, > > > > Here is the reference to the exclusion of TLS 1.0: > > https://www.niap-ccevs.org/pp/pp.cfm?id=CPP_ND_V1.0 > > Thanks. This is a protection profile, but it has nothing to do with > FIPS-140-2. The requirements for FIPS140-2 are specified in [0], and > to the documents referred by it. I don't see you document being > referred in that publication, but if it is, just let me know. > > regards, > Nikos > > [0]. http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf Hello, Here is the reference to NIST Special Publication SP 800-52 revision 1: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf Abstract: "This Special Publication provides guidance to the selection and configuration of TLS protocol implementations while making effective use of Federal Information Processing Stand ards (FIPS) and NIST- recommended cryptographic algorithms, and requires that TLS 1.1 configured with FIPS- based cipher suites as the minimum appropriate secure transport protocol and recommends that agencies develop migration plans to TLS 1.2 by January 1, 2015. This Special Publication also identifies TLS extensions for which mandatory support must be provided and other recommended extensions." Regards. From yshvedov at wimarksystems.com Thu Apr 30 09:49:40 2015 From: yshvedov at wimarksystems.com (Yury Shvedov) Date: Thu, 30 Apr 2015 10:49:40 +0300 Subject: [gnutls-help] Asynchronous transport In-Reply-To: References: <553F50C5.4060704@wimarksystems.com> Message-ID: <5541DE94.8090404@wimarksystems.com> Thank you for Your reply. So If i set my pull and push functions, which behave as non-blocking sendto and recvfrom respectively, gnutls won't call pull_timeout function because of |GNUTLS_NONBLOCK| flag in gnutls_init? ? ?????????, ???? ?????? WiMark Systems On 04/28/2015 02:49 PM, Nikos Mavrogiannopoulos wrote: > On Tue, Apr 28, 2015 at 11:20 AM, Yury Shvedov > wrote: >> Hi, >> I have an event-drivent system, based on libevent and extended with my own >> API and functionality. I'm trying to use gnutls to protect my channels with >> DTLS, but I'm confused with pull_timeout_function >> (http://gnutls.org/manual/html_node/Setting-up-the-transport-layer.html). I >> want to use my own asynchronous timers to tell gnutls about timeouts, but >> pull_timeout_function make to use select. >> Is there any way to get round this legally? > If you are using your own event handling, wouldn't asynchronous > operation be more suitable? In that case gnutls will not call the > pull_timeout function. > http://gnutls.org/manual/html_node/Asynchronous-operation.html#Asynchronous-operation -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Apr 30 12:52:26 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Apr 2015 12:52:26 +0200 Subject: [gnutls-help] Asynchronous transport In-Reply-To: <5541DE94.8090404@wimarksystems.com> References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> Message-ID: On Thu, Apr 30, 2015 at 9:49 AM, Yury Shvedov wrote: > Thank you for Your reply. > So If i set my pull and push functions, which behave as non-blocking sendto > and recvfrom respectively, gnutls won't call pull_timeout function because > of GNUTLS_NONBLOCK flag in gnutls_init? That is correct. From nmav at gnutls.org Thu Apr 30 14:28:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Apr 2015 14:28:47 +0200 Subject: [gnutls-help] Asynchronous transport In-Reply-To: References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> Message-ID: On Thu, Apr 30, 2015 at 12:52 PM, Nikos Mavrogiannopoulos wrote: > On Thu, Apr 30, 2015 at 9:49 AM, Yury Shvedov > wrote: >> Thank you for Your reply. >> So If i set my pull and push functions, which behave as non-blocking sendto >> and recvfrom respectively, gnutls won't call pull_timeout function because >> of GNUTLS_NONBLOCK flag in gnutls_init? Actually I was not correct. The pull timeout can still be called in non-blocking DTLS case, but then only with an @ms parameter of zero. That is to know whether there are data waiting or not. If you can not use select for that you can use recv in PEEK mode. regards, Nikos From yshvedov at wimarksystems.com Thu Apr 30 16:20:17 2015 From: yshvedov at wimarksystems.com (Yury Shvedov) Date: Thu, 30 Apr 2015 17:20:17 +0300 Subject: [gnutls-help] Asynchronous transport In-Reply-To: References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> Message-ID: <55423A21.9010104@wimarksystems.com> Unfortunately, it is still not correct. For the first time, my client gnutls_init(&m_session, GNUTLS_CLIENT | GNUTLS_DATAGRAM | GNUTLS_NONBLOCK); /* .... */ gnutls_dtls_set_mtu(m_session, 1000); gnutls_handshake_set_timeout(m_session, GNUTLS_DEFAULT_HANDSHAKE_TIMEOUT); requests pull_timeout with @ms = 0. But when server became to respond, it tries to set 4000 ms. Maybe I have to call gnutls_handshake_set_timeout differently? Using gnutls_dtls_set_timeouts? But will gnutls_dtls_get_timeout return correct values in that case? ? ?????????, ???? ?????? WiMark Systems On 04/30/2015 03:28 PM, Nikos Mavrogiannopoulos wrote: > On Thu, Apr 30, 2015 at 12:52 PM, Nikos Mavrogiannopoulos > wrote: >> On Thu, Apr 30, 2015 at 9:49 AM, Yury Shvedov >> wrote: >>> Thank you for Your reply. >>> So If i set my pull and push functions, which behave as non-blocking sendto >>> and recvfrom respectively, gnutls won't call pull_timeout function because >>> of GNUTLS_NONBLOCK flag in gnutls_init? > Actually I was not correct. The pull timeout can still be called in > non-blocking DTLS case, but then only with an @ms parameter of zero. > That is to know whether there are data waiting or not. If you can not > use select for that you can use recv in PEEK mode. > > regards, > Nikos From nmav at gnutls.org Thu Apr 30 16:27:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Apr 2015 16:27:39 +0200 Subject: [gnutls-help] Asynchronous transport In-Reply-To: <55423A21.9010104@wimarksystems.com> References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> <55423A21.9010104@wimarksystems.com> Message-ID: On Thu, Apr 30, 2015 at 4:20 PM, Yury Shvedov wrote: > Unfortunately, it is still not correct. For the first time, my client > > gnutls_init(&m_session, GNUTLS_CLIENT | GNUTLS_DATAGRAM | > GNUTLS_NONBLOCK); > /* .... */ > gnutls_dtls_set_mtu(m_session, 1000); > gnutls_handshake_set_timeout(m_session, > GNUTLS_DEFAULT_HANDSHAKE_TIMEOUT); In DTLS you have to use gnutls_dtls_set_timeouts(). Does that solve the issue? regards, Nikos From yshvedov at wimarksystems.com Thu Apr 30 17:04:24 2015 From: yshvedov at wimarksystems.com (Yury Shvedov) Date: Thu, 30 Apr 2015 18:04:24 +0300 Subject: [gnutls-help] Asynchronous transport In-Reply-To: References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> <55423A21.9010104@wimarksystems.com> Message-ID: <55424478.1070606@wimarksystems.com> Yes... I mean.. partly. Gnutls stopped using pull_timeout as synchronous timeout, but I still have problems: I used gnutls_dtls_set_timeouts(m_session, 1000, 60*1000); it helped, but from man pages: If the retransmission timeout is zero then the handshake will operate in a non-blocking way, i.e., return GNUTLS_E_AGAIN. If I set retrnasmission timeout to zero, the gnutls_dtls_get_timeout returns me zero every time. But according to man pages: This function is useful when DTLS is used in non-blocking mode. And gnutls_handshake() doesn't perform any sending after receiving server_hello. The problem is then I set retrnasmission timeout to zero, it returns me 0 again after 3 timeouts. What I have to do, when gnutls_dtls_get_timeout returns zero? P.S. I have another several question. 1. What I have to do when gnutls pass me to pull function the buffer of smaller size than one, I have the first in queue (in DTLS mode!)? Divide buffer? If not, return the size of requested buffer or size of full buffer? 2. Does gnutls supports the exchange without encryption? What if I want only fragmentation and authentication feature from this library? 3. The valgrind tells me that the buffer, gnutls_dtls_cookie_send passes to my push function (44 bytes), have an uninitialized values after first 0xa bytes. The buffer allocated on the stack. ? ?????????, ???? ?????? WiMark Systems On 04/30/2015 05:27 PM, Nikos Mavrogiannopoulos wrote: > On Thu, Apr 30, 2015 at 4:20 PM, Yury Shvedov > wrote: >> Unfortunately, it is still not correct. For the first time, my client >> >> gnutls_init(&m_session, GNUTLS_CLIENT | GNUTLS_DATAGRAM | >> GNUTLS_NONBLOCK); >> /* .... */ >> gnutls_dtls_set_mtu(m_session, 1000); >> gnutls_handshake_set_timeout(m_session, >> GNUTLS_DEFAULT_HANDSHAKE_TIMEOUT); > In DTLS you have to use gnutls_dtls_set_timeouts(). Does that solve the issue? > > regards, > Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Apr 30 18:53:03 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Apr 2015 18:53:03 +0200 Subject: [gnutls-help] Asynchronous transport In-Reply-To: <55424478.1070606@wimarksystems.com> References: <553F50C5.4060704@wimarksystems.com> <5541DE94.8090404@wimarksystems.com> <55423A21.9010104@wimarksystems.com> <55424478.1070606@wimarksystems.com> Message-ID: <1430412783.1920.5.camel@gnutls.org> On Thu, 2015-04-30 at 18:04 +0300, Yury Shvedov wrote: > Yes... I mean.. partly. Gnutls stopped using pull_timeout as > synchronous timeout, but I still have problems: > I used > gnutls_dtls_set_timeouts(m_session, 1000, 60*1000); > it helped, but from man pages: > If the retransmission timeout is zero then the handshake will > operate in a non-blocking way, i.e., return GNUTLS_E_AGAIN. I'll have to check it. However, the documentation seems wrong for that. Does the version with a second of retransmissions work? That should be the correct choice for blocking or non-blocking. > If I set retrnasmission timeout to zero, the gnutls_dtls_get_timeout > returns me zero every time. But according to man pages: > This function is useful when DTLS is used in non-blocking mode. > And gnutls_handshake() doesn't perform any sending after receiving > server_hello. The problem is then I set retrnasmission timeout to > zero, it returns me 0 again after 3 timeouts. What I have to do, when > gnutls_dtls_get_timeout returns zero? When gnutls_dtls_get_timeout is zero, you call gnutls_handshake(). > P.S. I have another several question. > 1. What I have to do when gnutls pass me to pull function the > buffer of smaller size than one, I have the first in queue (in > DTLS mode!)? Divide buffer? If not, return the size of > requested buffer or size of full buffer? I'm not sure I understand the question. > 1. Does gnutls supports the exchange without encryption? What if > I want only fragmentation and authentication feature from this > library? You have to enable the null cipher. E.g., use the priority string "NORMAL:-CIPHER-ALL:+NULL" to both peers. > 1. The valgrind tells me that the buffer, gnutls_dtls_cookie_send > passes to my push function (44 bytes), have an uninitialized > values after first 0xa bytes. The buffer allocated on the > stack. Could you reproduce that with gnutls' tests/mini-dtls-hello-verify.c? regards, Nikos