From sona.sarmadi at enea.com Tue Sep 1 08:32:20 2015 From: sona.sarmadi at enea.com (Sona Sarmadi) Date: Tue, 1 Sep 2015 06:32:20 +0000 Subject: [gnutls-devel] Use CVE-2015-6251 for GNUTLS-SA-2015-3. Message-ID: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se> Greetings, The Security Advisories page below says: "GNUTLS-SA-2015-2 No CVE assigned" http://www.gnutls.org/security.html#GNUTLS-SA-2015-1 Mitre has assigned CVE-2015-6251 for GNUTLS-SA-2015-3: http://www.openwall.com/lists/oss-security/2015/08/17/6 Just wanted to ping you to update the page, not sure though if this is the right mailing list. One question, Why "CVE-2015-3308 gnutls: use-after-free flaw in CRL distribution points parsing" is not listed in the Security Advisories page? (This is of some unknown reason for me still " ** RESERVED **" by Mitre: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3308) Thanks //Sona From nmav at gnutls.org Tue Sep 1 16:19:18 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 1 Sep 2015 16:19:18 +0200 Subject: [gnutls-devel] Use CVE-2015-6251 for GNUTLS-SA-2015-3. In-Reply-To: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se> References: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se> Message-ID: On Tue, Sep 1, 2015 at 8:32 AM, Sona Sarmadi wrote: > Greetings, > The Security Advisories page below says: "GNUTLS-SA-2015-2 No CVE assigned" > http://www.gnutls.org/security.html#GNUTLS-SA-2015-1 > Mitre has assigned CVE-2015-6251 for GNUTLS-SA-2015-3: > http://www.openwall.com/lists/oss-security/2015/08/17/6 > Just wanted to ping you to update the page, not sure though if this is the right mailing list. Hello Sona, This is the right mailing list. Not sure I understand the request. GNUTLS-SA-2015-3 has CVE-2015-6251 assigned, and I think that this is visible in the security page. GNUTLS-SA-2015-2 has indeed no CVE assigned which is also reflected in that page. > One question, > Why "CVE-2015-3308 gnutls: use-after-free flaw in CRL distribution points parsing" is not listed in > the Security Advisories page? I tend to prioritise advisories for issues that affect the majority of applications. E.g., if there is a bug which causes a crash in all gnutls clients, it will get an advisory as soon, for issues that affect only a small set of applications an advisory may be skipped. For these issues we rely mostly on 3rd parties' advisories. That's not ideal, but a compromise due to limited time at the moment. > (This is of some unknown reason for me still " ** RESERVED **" by Mitre: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3308) Is that related with the no CVE assigned issue above? regards, Nikos From snover1992 at gmail.com Tue Sep 8 10:41:35 2015 From: snover1992 at gmail.com (Loc Vu) Date: Tue, 8 Sep 2015 15:41:35 +0700 Subject: [gnutls-devel] Fwd: install gnutls fail in kali linux In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Loc Vu Date: 2015-09-08 11:27 GMT+07:00 Subject: install gnutls fail in kali linux To: gnutls-help at lists.gnutls.org HI.I have a problem when try to install gnutls in kali linux. in configure process : root at lco:~/Downloads/gnutls-3.4.4# ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes *** *** Checking for compilation programs... checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for Minix Amsterdam compiler... no checking for ar... ar checking for ranlib... ranlib checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking for _LARGEFILE_SOURCE value needed for large files... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking dependency style of gcc... gcc3 checking the archiver (ar) interface... ar checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for bison... no checking for byacc... no checking for a sed that does not truncate output... /bin/sed checking for autogen... /bin/true configure: WARNING: *** *** autogen not found. Will not link against libopts. *** checking for inline... inline checking for ANSI C header files... (cached) yes checking cpuid.h usability... yes checking cpuid.h presence... yes checking for cpuid.h... yes checking for getrandom... no checking for getentropy... no checking for NETTLE... no configure: error: *** *** Libnettle 3.1 was not found. I have manually isntalll libnettle3.1 but it's still not found.My English is not good so hope you can understand. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tzz at lifelogs.com Tue Sep 8 16:21:49 2015 From: tzz at lifelogs.com (Ted Zlatanov) Date: Tue, 08 Sep 2015 10:21:49 -0400 Subject: [gnutls-devel] simplifying certificate verification References: Message-ID: <87io7lf0ua.fsf@lifelogs.com> On Mon, 24 Aug 2015 13:58:08 +0200 Nikos Mavrogiannopoulos wrote: NM> One the pains in using gnutls is the fact that there is needed quite NM> some copy-paste code to perform certificate verification. I decided to NM> simplify that from 3.5.0, using a function called NM> gnutls_session_auto_verify_cert(), and the result can be seen on the NM> following example ... NM> I'd appreciate any comments or suggestions for improving that interface [0]. NM> [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/gnutls.h.in#L1296 To me it looks nice and usable. Are there reasons not to use it (other than backwards compatibility)? Any logging gotchas for the users (since the logging will change from their point of view if a GnuTLS upgrade triggers the use of gnutls_session_auto_verify_cert())? Thanks Ted From nmav at gnutls.org Fri Sep 11 15:39:04 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Sep 2015 15:39:04 +0200 Subject: [gnutls-devel] simplifying certificate verification In-Reply-To: <87io7lf0ua.fsf@lifelogs.com> References: <87io7lf0ua.fsf@lifelogs.com> Message-ID: On Tue, Sep 8, 2015 at 4:21 PM, Ted Zlatanov wrote: > NM> One the pains in using gnutls is the fact that there is needed quite > NM> some copy-paste code to perform certificate verification. I decided to > NM> simplify that from 3.5.0, using a function called > NM> gnutls_session_auto_verify_cert(), and the result can be seen on the > NM> following example > ... > NM> I'd appreciate any comments or suggestions for improving that interface [0]. > NM> [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/gnutls.h.in#L1296 > > To me it looks nice and usable. Are there reasons not to use it (other > than backwards compatibility)? None that I can think of, if you use X.509 certificates. > Any logging gotchas for the users (since > the logging will change from their point of view if a GnuTLS upgrade > triggers the use of gnutls_session_auto_verify_cert())? I introduced a new error code to be returned by gnutls_handshake() on failure. From nmav at gnutls.org Sat Sep 12 11:56:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Sep 2015 11:56:47 +0200 Subject: [gnutls-devel] gnutls 3.3.18 Message-ID: <1442051807.11698.0.camel@gnutls.org> Hello, I've just released gnutls 3.3.18. This is a bug-fix release on the current stable branch. * Version 3.3.18 (released 2015-09-12) ** libgnutls: When re-importing CRLs to a trust list ensure that there no duplicate entries. ** certtool: Removed any arbitrary limits imposed on input file sizes and maximum number of certificates imported. ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.18.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.18.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.18.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.18.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sat Sep 12 11:57:37 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Sep 2015 11:57:37 +0200 Subject: [gnutls-devel] gnutls 3.4.5 Message-ID: <1442051857.11698.1.camel@gnutls.org> Hello, I've just released gnutls 3.4.5. This version fixes bugs and adds minor features to the next stable branch. * Version 3.4.5 (released 2015-09-12) ** libgnutls: When re-importing CRLs to a trust list ensure that there no duplicate entries. ** certtool: Removed any arbitrary limits imposed on input file sizes and maximum number of certificates imported. ** certtool: Allow specifying fixed dates on CRL generation. ** gnutls-cli-debug: Added check for inappropriate fallback support (RFC7507). ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.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 a.radke at arcor.de Sat Sep 12 21:34:44 2015 From: a.radke at arcor.de (Andreas Radke) Date: Sat, 12 Sep 2015 21:34:44 +0200 Subject: [gnutls-devel] gnutls 3.4.5 In-Reply-To: <1442051857.11698.1.camel@gnutls.org> References: <1442051857.11698.1.camel@gnutls.org> Message-ID: <20150912213444.66e0eec6@laptop64.home> This one now fails again building without dane support: =================================================== GnuTLS 3.4.5: tests/cert-tests/test-suite.log =================================================== # TOTAL: 13 # PASS: 10 # SKIP: 2 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: certtool ============== ./certtool: line 83: datefudge: command not found You need datefudge to run this test SKIP certtool (exit status: 77) FAIL: pkcs7 =========== import error: ASN1 parser: Error in DER parsing. full.p7b: PKCS7 decoding failed FAIL pkcs7 (exit status: 1) SKIP: template-test =================== ./template-test: line 30: datefudge: command not found You need datefudge to run this test SKIP template-test (exit status: 77) -Andy Arch LInux From nmav at gnutls.org Sun Sep 13 14:11:51 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Sep 2015 14:11:51 +0200 Subject: [gnutls-devel] provable primes in private keys Message-ID: <1442146311.17766.18.camel@gnutls.org> For gnutls 3.5.0 (current master branch) I wanted to expose the API to generate and verify private keys consisting of provable primes as in FIPS 186-4. That API was internally available and enabled by default when gnutls was switch to FIPS-140 mode [0]. While the requirements of FIPS have been controversial, this particular property of generated parameters, seems quite useful for certain scenarios. That's the reason I decided to expose it in non-FIPS compliant systems. It allows to generate RSA or DSA private keys using primes which can be proven to be prime if given the seed used for their generation. That currently be done with the following commands: $ certtool --generate-privkey --provable --outfile key.pem $ certtool --verify-provable-privkey --load-privkey key.pem optionally the seed can be given using --seed and it must comply to FIPS 186-4 requirements (i.e., 2048 and 3072 bit keys and 24 or 32 bytes for RSA seeds). Unfortunately, to store the generated seed and allow future validation I had to extend to private key format for both RSA and DSA keys, in a way that is not compatible with older versions. For that I introduced a new pem header (FIPS186-4 RSA PRIVATE KEY). The API additions can be summarized to these 3 functions: int gnutls_x509_privkey_generate2(gnutls_x509_privkey_t key, gnutls_pk_algorithm_t algo, unsigned int bits, unsigned int flags, const gnutls_keygen_data_st *data, unsigned data_size); int gnutls_x509_privkey_verify_seed(gnutls_x509_privkey_t key, gnutls_digest_algorithm_t, const void *seed, size_t seed_size); int gnutls_x509_privkey_get_seed(gnutls_x509_privkey_t key, gnutls_digest_algorithm_t*, void *seed, size_t *seed_size); Any comments or suggestions for improvement? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/34 From nmav at gnutls.org Mon Sep 14 15:38:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Sep 2015 15:38:39 +0200 Subject: [gnutls-devel] gnutls 3.4.5 In-Reply-To: <20150912213444.66e0eec6@laptop64.home> References: <1442051857.11698.1.camel@gnutls.org> <20150912213444.66e0eec6@laptop64.home> Message-ID: On Sat, Sep 12, 2015 at 9:34 PM, Andreas Radke wrote: > This one now fails again building without dane support: > FAIL: pkcs7 > =========== > import error: ASN1 parser: Error in DER parsing. > full.p7b: PKCS7 decoding failed > FAIL pkcs7 (exit status: 1) Thanks. This is a regression of libtasn1 4.6. I've committed a fix in libtasn1's repository. regards, Nikos From tim.ruehsen at gmx.de Wed Sep 16 16:57:14 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 16 Sep 2015 16:57:14 +0200 Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout() Message-ID: <3828897.2AjAXPMrcH@blitz-lx> Hi, I would like to use gnutls_record_set_timeout() instead of using my own timeout code. I see no way to specify an 'indefinite' timeout, e.g. by using a negative value. Should I set the fd to blocking or what is the best 'gnutls' way ? BTW, looking at the code in system_recv_timeout(), with high timeout values, there might be unexpected CPU usage due to this loop: tv.tv_sec = 0; tv.tv_usec = ms * 1000; while (tv.tv_usec >= 1000000) { tv.tv_usec -= 1000000; tv.tv_sec++; } IMHO, it could be replaced by tv.tv_sec = ms / 1000; tv.tv_usec = (ms % 1000) * 1000; Regards, Tim From tzz at lifelogs.com Wed Sep 16 17:56:44 2015 From: tzz at lifelogs.com (Ted Zlatanov) Date: Wed, 16 Sep 2015 11:56:44 -0400 Subject: [gnutls-devel] simplifying certificate verification References: <87io7lf0ua.fsf@lifelogs.com> Message-ID: <87d1xijr2b.fsf@lifelogs.com> On Fri, 11 Sep 2015 15:39:04 +0200 Nikos Mavrogiannopoulos wrote: NM> On Tue, Sep 8, 2015 at 4:21 PM, Ted Zlatanov wrote: >> Any logging gotchas for the users (since >> the logging will change from their point of view if a GnuTLS upgrade >> triggers the use of gnutls_session_auto_verify_cert())? NM> I introduced a new error code to be returned by gnutls_handshake() on failure. I think that's fine, and the simplification is great. Thanks for working on this. Ted From dkg at fifthhorseman.net Thu Sep 17 01:56:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Sep 2015 19:56:25 -0400 Subject: [gnutls-devel] simplifying certificate verification In-Reply-To: References: Message-ID: <87si6d6hqu.fsf@alice.fifthhorseman.net> On Mon 2015-08-24 07:58:08 -0400, Nikos Mavrogiannopoulos wrote: > One the pains in using gnutls is the fact that there is needed quite > some copy-paste code to perform certificate verification. I decided to > simplify that from 3.5.0, using a function called > gnutls_session_auto_verify_cert(), and the result can be seen on the > following example > > https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-x509.c > > That is about ~60 lines of code less per program using gnutls. > https://gitlab.com/gnutls/gnutls/commit/25f2b0814401d1e9c98f3fdc833e09b3c877fc72 > > I'd appreciate any comments or suggestions for improving that interface [0]. I really like the idea of simplifying this UI to something managable and correct by default for the common use case. In particular, i think the common use case is for TLS clients to verify server certificates. Handling that simply would make the life of many developers much better. :) Is this interface intended to work for servers to verify client certificates as well? I think we should avoid trying to make one configuration that handles them both, and this improvement should focus explicitly on the server certificate use case. But the proposed interface is a bit unclear to me, and i'd be happy to help clarify it. I'm looking at master, at 368018efccee25f82149cba47e05f5af6af28ae9. Looking at NEWS : It says gnutls_session_auto_verify_cert() was added, but gnutls_session_set_verify_cert and gnutls_session_set_verify_cert2() functions are the only ones i see implemented and exposed in the headers. what am i missing? Looking at gnutls.h.in: > /** > * gnutls_vdata_types_t: > * @GNUTLS_DT_UNKNOWN: Unknown data type. > * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname. > * @GNUTLS_DT_RFC822NAME: The data contain a null-terminated email address. > * @GNUTLS_DT_KEY_PURPOSE_OID: The data contain a null-terminated key purpose OID. > * > * Enumeration of different key exchange algorithms. > */ These are not key exchange algorithms. Maybe they're "X.509 certificate data field elements" or something? > typedef enum { > GNUTLS_DT_UNKNOWN = 0, > GNUTLS_DT_DNS_HOSTNAME = 1, > GNUTLS_DT_KEY_PURPOSE_OID = 2, > GNUTLS_DT_RFC822NAME = 3 > } gnutls_vdata_types_t; > > typedef struct { > gnutls_vdata_types_t type; > unsigned char *data; > unsigned int size; > } gnutls_typed_vdata_st; This seems to be a set of fields that the user is asking GnuTLS to look for in the cert, but it's unclear what it means -- for example, with GNUTLS_DT_DNS_HOSTNAME: Would an element of this type be checked only in SubjectAltNames, or would it also checked in the leaf CommonName of the Subject's DistinguishedName? Is it verified case-insensitively? normalized in any way? how is IDN/punycode handled? If multiple GNUTLS_DT_DNS_HOSTNAMEs are listed in an array of gnutls_typed_vdata_st, would any of them acceptable for verification? or do they all have to be present? For GNUTLS_DT_RFC822NAME, are these SubjectAltNames also, or will they be looked for in other fields in the cert? For GNUTLS_DT_KEY_PURPOSE_OID, is that keyUsage or extendedKeyUsage? In practice and in specifications, keyUsage and extendedKeyUsage have unusual combining behavior -- see, for example, the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1049176 about the relationship between kU and eKU. In particular RFC 5280 says: If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose. So what would that requirement look like? What about adding something like a SRVNAME option here as well to handle https://tools.ietf.org/html/rfc6125#section-6.5.1 ? Looking at lib/auto-verify.c: > /** > * gnutls_session_set_verify_cert: > * @session: is a gnutls session > * @hostname: is the expected name of the peer; may be %NULL > * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags > * > * This function instructs GnuTLS to verify the peer's certificate > * using the provided hostname. If the verification fails the handshake > * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that > * case the verification result can be obtained using gnutls_session_get_verify_cert_status(). The same questions about GNUTLS_DT_DNS_HOSTNAME above (canonicalization; SAN vs. Subject leaf CN) apply here. Also, it looks to me like this doesn't verify anything about the server's certificate's eKU or kU flags -- but i think the simple default should at least: (a) if keyUsage extension exists, require the appropriate flags for the type of key exchange mechanism used in the TLS handshake (digitalSignature for (EC)DHE, keyEncipherment for RSA, or keyAgreement for static DH) (b) if extendedKeyUsage extension exists, require the "TLS Server" value set (id-kp-serverAuth) Or are these requirements already present by default? We might also want to review the policies articulated by the CA/B Forum for subscriber certificates: https://cabforum.org/baseline-requirements-certificate-contents/#Subscriber-Certificates I'm no big fan of the CA/B forum, but some of their recommendations may be things we want to expect. At the moment, i'm torn about their requirement for BasicConstraints: CA:False for end-entity certificates. I think that's an excellent requirement for CAs issuing EE certs -- i'm not sure whether we should enforce it as a TLS client as well. I'm sure there are some homebrew CA setups that use CA:True certs for servers. > * The @hostname pointer provided must remain valid for the lifetime > * of the session. More precisely it should be available during any subsequent > * handshakes. This memory management sounds cumbersome to me for what will likely become the default handler for most applications -- though it's similar to gnutls_credentials_set. The difference is that this is likely to be called from code that itself received the hostname from elsewhere. Can we have the session object allocate a copy for the case where this default function is called so that the default caller doesn't have to think about bundling the hostname's memory management with the session object? > If not hostname is provided, no hostname verification > * will be performed. This should be "If no hostname is provided, ..." Perhaps it should also indicate what else happens -- for example, if no hostname verification is performed, is any certificate valid? or does GnuTLS only check that the certificate chains back to a trusted root, which means it can be replaced by any other certificate that chains to a trusted root? We should be clear that leaving hostname blank here represents a security risk. > For a more advanced verification function check > * gnutls_session_set_verify_cert2(). > * > * That function is intended to be used by clients. which function? It's unclear whether this last sentence applies to g_s_set_verify_cert() or g_s_set_verify_cert2(). is "by clients" supposed to mean "only TLS clients"? What happens if a server calls it? > /** > * gnutls_session_set_verify_cert2: > * @session: is a gnutls session > * @data: an array of typed data > * @elements: the number of data elements > * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags > * > * This function instructs GnuTLS to verify the peer's certificate > * using the provided typed data information. If the verification fails the handshake > * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that > * case the verification result can be obtained using gnutls_session_get_verify_cert_status(). > * > * The acceptable typed data are the same as in gnutls_certificate_verify_peers(), > * and once set must remain valid for the lifetime of the session. More precisely > * they should be available during any subsequent handshakes. > * > * Since: 3.5.0 > **/ > void gnutls_session_set_verify_cert2(gnutls_session_t session, > gnutls_typed_vdata_st * data, > unsigned elements, > unsigned flags) > { Would it help to comment here that this is equivalent to calling gnutls_certificate_verify_peers with the same data object? Regards, --dkg From dkg at fifthhorseman.net Thu Sep 17 01:59:12 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 16 Sep 2015 19:59:12 -0400 Subject: [gnutls-devel] [PATCH] improve docs for gnutls_certificate_verify_peers*() Message-ID: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net> The gnutls_certificate_verify_peers{,2,3}() functions all return GNUTLS_E_SUCCESS (0) even in situations when the peer's certificate was not verified. This is explained in the first paragraphs ("i.e. failure to trust a certificate does not imply a negative return value"), but the Returns: line isn't comparably clear. --- lib/cert.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/cert.c b/lib/cert.c index fb01d1b..2d79c96 100644 --- a/lib/cert.c +++ b/lib/cert.c @@ -597,7 +597,9 @@ _gnutls_openpgp_crt_verify_peers(gnutls_session_t session, * the verified certificate belongs to the actual peer, see gnutls_x509_crt_check_hostname(), * or use gnutls_certificate_verify_peers3(). * - * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success. + * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) + * when the peer's certificate was successfully parsed, whether or not + * it was verified. **/ int gnutls_certificate_verify_peers2(gnutls_session_t session, @@ -629,7 +631,9 @@ gnutls_certificate_verify_peers2(gnutls_session_t session, * In order to verify the purpose of the end-certificate (by checking the extended * key usage), use gnutls_certificate_verify_peers(). * - * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success. + * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) + * when the peer's certificate was successfully parsed, whether or not + * it was verified. * * Since: 3.1.4 **/ @@ -673,7 +677,9 @@ gnutls_typed_vdata_st data; * usage PKIX extension, it will be required to be have the provided key purpose * or be marked for any purpose, otherwise verification will fail with %GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE status. * - * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success. + * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) + * when the peer's certificate was successfully parsed, whether or not + * it was verified. * * Since: 3.3.0 **/ -- 2.5.1 From tim.ruehsen at gmx.de Thu Sep 17 16:52:32 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 17 Sep 2015 16:52:32 +0200 Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout() In-Reply-To: References: <3828897.2AjAXPMrcH@blitz-lx> Message-ID: <2758704.d37AHcddQ4@blitz-lx> On Thursday 17 September 2015 14:53:06 Nikos Mavrogiannopoulos wrote: > On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen wrote: > > Hi, > > I would like to use gnutls_record_set_timeout() instead of using my own > > timeout code. > > I see no way to specify an 'indefinite' timeout, e.g. by using a negative > > value. Should I set the fd to blocking or what is the best 'gnutls' way ? > > The timeout for this function only makes sense with blocking fds. For > non-blocking fds you always have the function return as soon as > possible. By not setting a timeout with this function you get the > indefinite timeout. Does this answer your question? Just a slight correction. I use gnutls_record_set_timeout() / gnutls_record_recv() together with non- blocking sockets. And it works flawlessly since the timeout just adds a select() before the read(). If you take a blocking fd, you might experience a select() saying 'yo man, it's readable' and the subsequent read() being stuck. At least I experienced this a long time ago and since than I never used blocking fds any more :-) (but this is beyond discussion here, I guess). So, Yes. So far I can live with a max. timeout of 2^32 / 1000 seconds (that's almost 50 days). I guess no one ever complains... Thanks for your answer and sorry for the noise. Tim From nmav at gnutls.org Thu Sep 17 10:08:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Sep 2015 10:08:47 +0200 Subject: [gnutls-devel] [PATCH] improve docs for gnutls_certificate_verify_peers*() In-Reply-To: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net> References: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net> Message-ID: On Thu, Sep 17, 2015 at 1:59 AM, Daniel Kahn Gillmor wrote: > The gnutls_certificate_verify_peers{,2,3}() functions all return > GNUTLS_E_SUCCESS (0) even in situations when the peer's certificate > was not verified. This is explained in the first paragraphs > ("i.e. failure to trust a certificate does not imply a negative return > value"), but the Returns: line isn't comparably clear. Applied, thanks. From nmav at gnutls.org Thu Sep 17 14:53:06 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Sep 2015 14:53:06 +0200 Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout() In-Reply-To: <3828897.2AjAXPMrcH@blitz-lx> References: <3828897.2AjAXPMrcH@blitz-lx> Message-ID: On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen wrote: > Hi, > I would like to use gnutls_record_set_timeout() instead of using my own > timeout code. > I see no way to specify an 'indefinite' timeout, e.g. by using a negative > value. Should I set the fd to blocking or what is the best 'gnutls' way ? The timeout for this function only makes sense with blocking fds. For non-blocking fds you always have the function return as soon as possible. By not setting a timeout with this function you get the indefinite timeout. Does this answer your question? > BTW, looking at the code in system_recv_timeout(), with high timeout values, > there might be unexpected CPU usage due to this loop: > > tv.tv_sec = 0; > tv.tv_usec = ms * 1000; > > while (tv.tv_usec >= 1000000) { > tv.tv_usec -= 1000000; > tv.tv_sec++; > } > IMHO, it could be replaced by > tv.tv_sec = ms / 1000; > tv.tv_usec = (ms % 1000) * 1000; Indeed, this code was written with small timeout values in mind. I'll update it. regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Sep 17 10:50:50 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 17 Sep 2015 10:50:50 +0200 Subject: [gnutls-devel] simplifying certificate verification In-Reply-To: <87si6d6hqu.fsf@alice.fifthhorseman.net> References: <87si6d6hqu.fsf@alice.fifthhorseman.net> Message-ID: On Thu, Sep 17, 2015 at 1:56 AM, Daniel Kahn Gillmor wrote: > On Mon 2015-08-24 07:58:08 -0400, Nikos Mavrogiannopoulos wrote: >> One the pains in using gnutls is the fact that there is needed quite >> some copy-paste code to perform certificate verification. I decided to >> simplify that from 3.5.0, using a function called >> gnutls_session_auto_verify_cert(), and the result can be seen on the >> following example >> https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-x509.c >> That is about ~60 lines of code less per program using gnutls. >> https://gitlab.com/gnutls/gnutls/commit/25f2b0814401d1e9c98f3fdc833e09b3c877fc72 >> I'd appreciate any comments or suggestions for improving that interface [0]. > I really like the idea of simplifying this UI to something managable and > correct by default for the common use case. In particular, i think the > common use case is for TLS clients to verify server certificates. > Handling that simply would make the life of many developers much > better. :) > Is this interface intended to work for servers to verify client > certificates as well? I think we should avoid trying to make one > configuration that handles them both, and this improvement should focus > explicitly on the server certificate use case. I also considered that, but for the majority of use cases both can be handled in quite manageable way (at the cost of using the gnutls_session_set_verify_cert2()). > But the proposed interface is a bit unclear to me, and i'd be happy to > help clarify it. I'm looking at master, at > 368018efccee25f82149cba47e05f5af6af28ae9. > Looking at NEWS : > It says gnutls_session_auto_verify_cert() was added, but > gnutls_session_set_verify_cert and gnutls_session_set_verify_cert2() > functions are the only ones i see implemented and exposed in the > headers. what am i missing? I've removed the _auto_ from the name and replaced it with _set_. I've updated the NEWS to reflect that. > Looking at gnutls.h.in: >> /** >> * gnutls_vdata_types_t: >> * @GNUTLS_DT_UNKNOWN: Unknown data type. >> * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname. >> * @GNUTLS_DT_RFC822NAME: The data contain a null-terminated email address. >> * @GNUTLS_DT_KEY_PURPOSE_OID: The data contain a null-terminated key purpose OID. >> * >> * Enumeration of different key exchange algorithms. >> */ Corrected. Text updated. > These are not key exchange algorithms. Maybe they're "X.509 certificate > data field elements" or something? > >> typedef enum { >> GNUTLS_DT_UNKNOWN = 0, >> GNUTLS_DT_DNS_HOSTNAME = 1, >> GNUTLS_DT_KEY_PURPOSE_OID = 2, >> GNUTLS_DT_RFC822NAME = 3 >> } gnutls_vdata_types_t; >> >> typedef struct { >> gnutls_vdata_types_t type; >> unsigned char *data; >> unsigned int size; >> } gnutls_typed_vdata_st; > This seems to be a set of fields that the user is asking GnuTLS to look > for in the cert, but it's unclear what it means -- for example, with > GNUTLS_DT_DNS_HOSTNAME: The new text is: * Enumeration of different typed-data options. They are used as input to certificate * verification functions to provide information about the name and purpose of the * certificate. > Would an element of this type be checked only in SubjectAltNames, or > would it also checked in the leaf CommonName of the Subject's > DistinguishedName? Is it verified case-insensitively? normalized in > any way? how is IDN/punycode handled? I've added in the text that RFC6125 comparison is being used. > If multiple GNUTLS_DT_DNS_HOSTNAMEs are listed in an array of > gnutls_typed_vdata_st, would any of them acceptable for verification? > or do they all have to be present? Only a single one is accepted. I've made that clear. > For GNUTLS_DT_RFC822NAME, are these SubjectAltNames also, or will they > be looked for in other fields in the cert? Since there is no specific RFC for that, I've added more text there. "The data contain a null-terminated email address; the email will be matched against the RFC822Name field of the certificate, or the EMAIL DN component if the former isn't available. Prior to matching the email address will be converted to ACE (ASCII-compatible-encoding)" > For GNUTLS_DT_KEY_PURPOSE_OID, is that keyUsage or extendedKeyUsage? In > practice and in specifications, keyUsage and extendedKeyUsage have > unusual combining behavior -- see, for example, the discussion in This is the Extended Key Usage. > https://bugzilla.mozilla.org/show_bug.cgi?id=1049176 about the > relationship between kU and eKU. In particular RFC 5280 says: > If a certificate contains both a key usage extension and an extended > key usage extension, then both extensions MUST be processed > independently and the certificate MUST only be used for a purpose > consistent with both extensions. If there is no purpose consistent > with both extensions, then the certificate MUST NOT be used for any > purpose. That's an interesting case. I'm not sure I agree that when an extended key usage is present the key usage extension should be nullified. That's certainly something to be clarified in PKIX and RFC5280. As it is now, I don't think that gnutls is strict about the extended key usage, unless the verifier explicitly specifies a particular usage. > So what would that requirement look like? > What about adding something like a SRVNAME option here as well to handle > https://tools.ietf.org/html/rfc6125#section-6.5.1 ? That looks interesting. Please open an issue about it in the issue tracker so I don't forget for 3.5.0. > Looking at lib/auto-verify.c: > >> /** >> * gnutls_session_set_verify_cert: >> * @session: is a gnutls session >> * @hostname: is the expected name of the peer; may be %NULL >> * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags >> * >> * This function instructs GnuTLS to verify the peer's certificate >> * using the provided hostname. If the verification fails the handshake >> * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that >> * case the verification result can be obtained using gnutls_session_get_verify_cert_status(). > > The same questions about GNUTLS_DT_DNS_HOSTNAME above (canonicalization; > SAN vs. Subject leaf CN) apply here. > Also, it looks to me like this doesn't verify anything about the > server's certificate's eKU or kU flags -- but i think the simple default should at least: The kU flags don't really need to be specified the verifier. The verification routine has enough information to know when to use them. The eKU cannot be specified indeed. > (a) if keyUsage extension exists, require the appropriate flags for the > type of key exchange mechanism used in the TLS handshake > (digitalSignature for (EC)DHE, keyEncipherment for RSA, or > keyAgreement for static DH) That should be the case already. > (b) if extendedKeyUsage extension exists, require the "TLS Server" > value set (id-kp-serverAuth) I have problem with that because RFC5280 specifies "TLS WWW server authentication". So if for example this is used for IMAP this key purpose is invalid. That's the reason it is not set by default. > Or are these requirements already present by default? > We might also want to review the policies articulated by the CA/B Forum > for subscriber certificates: > https://cabforum.org/baseline-requirements-certificate-contents/#Subscriber-Certificates > I'm no big fan of the CA/B forum, but some of their recommendations may > be things we want to expect. At the moment, i'm torn about their > requirement for BasicConstraints: CA:False for end-entity certificates. > I think that's an excellent requirement for CAs issuing EE certs -- i'm > not sure whether we should enforce it as a TLS client as well. That's too strict to be useful. It is a good practice to be explicit, but in reality there will be many cases with certificates that have some fields implicit. We only need to have good defaults for these cases. >> * The @hostname pointer provided must remain valid for the lifetime >> * of the session. More precisely it should be available during any subsequent >> * handshakes. > This memory management sounds cumbersome to me for what will likely > become the default handler for most applications -- though it's similar > to gnutls_credentials_set. The difference is that this is likely to be > called from code that itself received the hostname from elsewhere. Can > we have the session object allocate a copy for the case where this > default function is called so that the default caller doesn't have to > think about bundling the hostname's memory management with the session > object? Talloc would have been very handy here. I agree, but will have to think how to solve that. Please open a bug, or follow up if that is not solved prior to 3.5.0. >> If not hostname is provided, no hostname verification >> * will be performed. > This should be "If no hostname is provided, ..." Perhaps it should also > indicate what else happens -- for example, if no hostname verification > is performed, is any certificate valid? or does GnuTLS only check that > the certificate chains back to a trusted root, which means it can be > replaced by any other certificate that chains to a trusted root? We > should be clear that leaving hostname blank here represents a security > risk. Any text suggestion? regards, Nikos From nmav at gnutls.org Thu Sep 17 14:53:06 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Sep 2015 14:53:06 +0200 Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout() In-Reply-To: <3828897.2AjAXPMrcH@blitz-lx> References: <3828897.2AjAXPMrcH@blitz-lx> Message-ID: On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen wrote: > Hi, > I would like to use gnutls_record_set_timeout() instead of using my own > timeout code. > I see no way to specify an 'indefinite' timeout, e.g. by using a negative > value. Should I set the fd to blocking or what is the best 'gnutls' way ? The timeout for this function only makes sense with blocking fds. For non-blocking fds you always have the function return as soon as possible. By not setting a timeout with this function you get the indefinite timeout. Does this answer your question? > BTW, looking at the code in system_recv_timeout(), with high timeout values, > there might be unexpected CPU usage due to this loop: > > tv.tv_sec = 0; > tv.tv_usec = ms * 1000; > > while (tv.tv_usec >= 1000000) { > tv.tv_usec -= 1000000; > tv.tv_sec++; > } > IMHO, it could be replaced by > tv.tv_sec = ms / 1000; > tv.tv_usec = (ms % 1000) * 1000; Indeed, this code was written with small timeout values in mind. I'll update it. regards, Nikos From nmav at gnutls.org Fri Sep 18 13:06:49 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 18 Sep 2015 13:06:49 +0200 Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout() In-Reply-To: <2758704.d37AHcddQ4@blitz-lx> References: <3828897.2AjAXPMrcH@blitz-lx> <2758704.d37AHcddQ4@blitz-lx> Message-ID: On Thu, Sep 17, 2015 at 4:52 PM, Tim Ruehsen wrote: > On Thursday 17 September 2015 14:53:06 Nikos Mavrogiannopoulos wrote: >> On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen wrote: >> > Hi, >> > I would like to use gnutls_record_set_timeout() instead of using my own >> > timeout code. >> > I see no way to specify an 'indefinite' timeout, e.g. by using a negative >> > value. Should I set the fd to blocking or what is the best 'gnutls' way ? >> >> The timeout for this function only makes sense with blocking fds. For >> non-blocking fds you always have the function return as soon as >> possible. By not setting a timeout with this function you get the >> indefinite timeout. Does this answer your question? > Just a slight correction. > I use gnutls_record_set_timeout() / gnutls_record_recv() together with non- > blocking sockets. And it works flawlessly since the timeout just adds a > select() before the read(). If you take a blocking fd, you might experience a select() saying 'yo man, > it's readable' and the subsequent read() being stuck. At least I experienced > this a long time ago and since than I never used blocking fds any more :-) > (but this is beyond discussion here, I guess). Ok that's a use case I was not aware of... It would be then useful to have an indicator for indefinite time. Please add an issue on the issue tracker so I don't forget before 3.5.0. regards, Nikos