From rkit at mur.at Fri Jun 3 15:53:03 2005 From: rkit at mur.at (Rupert Kittinger) Date: Fri, 3 Jun 2005 15:53:03 +0200 (CEST) Subject: [gnutls-dev] gnutls_certificate_verify_peers2() does not handle expirations Message-ID: Hi everybody, I think the x509 certificate check performed by gnutls_certificate_verify_peers2() is not sufficient, because it does not validate the various time constraints (activation/expiration of certificates, CAs, CRLs). I propose adding the following function: int gnutls_certificate_verify_peers3 (gnutls_session session, unsigned int * status, time_t then) that has the following semantics: - perform the same checks as gnutls_certificate_verify_peers2() - for every certificate in the chain, check for activation and expiration - if a crl is available for a CA and the nextUpdate field is available, check for expiration. add validation flags for the new error conditions. with the current API, these checks can only be performed by duplicating some of the code to get to the certificates, resp. crls. also, I did not find any checks for unknown critical extensions. As far as I know, these should also cause validation failure. Did I overlook something? cheers, Rupert -- Rupert Kittinger From jas at extundo.com Fri Jun 3 16:41:39 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 03 Jun 2005 16:41:39 +0200 Subject: [gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expirations In-Reply-To: (Rupert Kittinger's message of "Fri, 3 Jun 2005 15:53:03 +0200 (CEST)") References: Message-ID: Rupert Kittinger writes: > Hi everybody, > > I think the x509 certificate check performed by > gnutls_certificate_verify_peers2() is not sufficient, because it does not > validate the various time constraints (activation/expiration of > certificates, CAs, CRLs). Right. That is intentional, even if it is unfortunate. Did you see the example in section 7.3.4 of the manual? It try to do a bit more. Full verification of a certificate is application and purpose dependent, so it is difficult to generalize. > I propose adding the following function: > > int gnutls_certificate_verify_peers3 (gnutls_session session, unsigned int > * status, time_t then) > > that has the following semantics: > - perform the same checks as gnutls_certificate_verify_peers2() > - for every certificate in the chain, check for activation and expiration > - if a crl is available for a CA and the nextUpdate field is available, > check for expiration. > > add validation flags for the new error conditions. > > with the current API, these checks can only be performed by duplicating > some of the code to get to the certificates, resp. crls. In general I think it is a good idea to provide this. I agree duplicating the code from the example is sub-optimal and prone to errors. Checking activation/expiration dates should probably almost always be used. If you want to work on this, that would be good. I do dislike the *2 and *3 names, though, but can't come up with a better name right now. > also, I did not find any checks for unknown critical extensions. As far as > I know, these should also cause validation failure. Did I overlook > something? Probably not. Some of the PKITS self-test certificate chain fail to verify properly in GnuTLS because this is not implemented. Cheers, Simon From rkit at mur.at Fri Jun 3 17:16:16 2005 From: rkit at mur.at (Rupert Kittinger) Date: Fri, 3 Jun 2005 17:16:16 +0200 (CEST) Subject: [gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expirations In-Reply-To: References: Message-ID: On Fri, 3 Jun 2005, Simon Josefsson wrote: > Rupert Kittinger writes: > > > Hi everybody, > > > > I think the x509 certificate check performed by > > gnutls_certificate_verify_peers2() is not sufficient, because it does not > > validate the various time constraints (activation/expiration of > > certificates, CAs, CRLs). > > Right. That is intentional, even if it is unfortunate. > > Did you see the example in section 7.3.4 of the manual? It try to do > a bit more. Full verification of a certificate is application and > purpose dependent, so it is difficult to generalize. > I am quite aware of this. However, a lot of users of a library like this will not have detailed knowledge of X509 (and all its incarnations, sigh) and would profit from a "better safe than sorry" approach. Also, a detailed description of the algorithm used in the manual would be a great, if only for its educational value :-) > > I propose adding the following function: > > > > int gnutls_certificate_verify_peers3 (gnutls_session session, unsigned int > > * status, time_t then) > > > > that has the following semantics: > > - perform the same checks as gnutls_certificate_verify_peers2() > > - for every certificate in the chain, check for activation and expiration > > - if a crl is available for a CA and the nextUpdate field is available, > > check for expiration. > > > > add validation flags for the new error conditions. > > > > with the current API, these checks can only be performed by duplicating > > some of the code to get to the certificates, resp. crls. > > In general I think it is a good idea to provide this. I agree > duplicating the code from the example is sub-optimal and prone to > errors. Checking activation/expiration dates should probably almost > always be used. > > If you want to work on this, that would be good. I do dislike the *2 > and *3 names, though, but can't come up with a better name right now. > I hope I find the time to do this. Maybe some other people reading this list care to provide feedback on an improved certificate validation algorithm? Rupert -- Rupert Kittinger From jas at extundo.com Fri Jun 3 17:33:26 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 03 Jun 2005 17:33:26 +0200 Subject: [gnutls-dev] Re: gnutls_certificate_verify_peers2() does not handle expirations In-Reply-To: (Rupert Kittinger's message of "Fri, 3 Jun 2005 17:16:16 +0200 (CEST)") References: Message-ID: Rupert Kittinger writes: > On Fri, 3 Jun 2005, Simon Josefsson wrote: > >> Rupert Kittinger writes: >> >> > Hi everybody, >> > >> > I think the x509 certificate check performed by >> > gnutls_certificate_verify_peers2() is not sufficient, because it does not >> > validate the various time constraints (activation/expiration of >> > certificates, CAs, CRLs). >> >> Right. That is intentional, even if it is unfortunate. >> >> Did you see the example in section 7.3.4 of the manual? It try to do >> a bit more. Full verification of a certificate is application and >> purpose dependent, so it is difficult to generalize. >> > > I am quite aware of this. However, a lot of users of a library like > this will not have detailed knowledge of X509 (and all its incarnations, > sigh) and would profit from a "better safe than sorry" approach. Also, a > detailed description of the algorithm used in the manual would be a great, > if only for its educational value :-) Right, and I agree. It would be useful to have the algorithm in the gnutls_certificate_verify_peers3 function documentation; then it would end up in the manual, and would be easy to validate against the source code. > I hope I find the time to do this. Maybe some other people reading this > list care to provide feedback on an improved certificate validation > algorithm? I hope so too. As for implementation, taking what's in the 7.3.4 example and making a GnuTLS API function of it should be a good start. The details in the algorithm can be enhanced further on. Cheers, Simon From sergey at optimaltec.com Tue Jun 7 19:54:32 2005 From: sergey at optimaltec.com (Sergey Lipnevich) Date: Tue, 7 Jun 2005 17:54:32 +0000 (UTC) Subject: [gnutls-dev] LZO 2; configure problem; small logic patch Message-ID: Hi GNUTLS developers! I was trying to make GNUTLS work with the latest version of LZO (2.0) for our distro, SourceMage, and came upon the following minor problems, that I believe are not related to packaging: 1. Configure script contains this piece of code, which essentially disables LZO use if either --with-lzo or --without-lzo is given: 12197 # Check whether --with-lzo or --without-lzo was given. 12198 if test "${with_lzo+set}" = set; then 12199 withval="$with_lzo" 12200 use_lzo=no 12201 else 12202 use_lzo=yes 12203 fi; It should probably be: withval="$with_lzo" use_lzo=$withval 2. LZO 2 is using /include/lzo for include files, is it possible to detect this? Also, the file libextra/lzoconfig.h is obsolete and should probably be part of minilzo.h. The following patch will apply uniform logic in regards to using MINILZO in gnutls_extra.c: --- gnutls/libextra/gnutls_extra.c 2005-05-26 11:19:21.000000000 -0400 +++ gnutls/libextra/gnutls_extra.c 2005-06-07 13:12:09.000000000 -0400 @@ -29,7 +29,11 @@ #include #include #ifdef USE_LZO -# include +# ifdef USE_MINILZO +# include "minilzo.h" +# else +# include +# endif #endif 3. In case LZO is not required (USE_LZO undefined in config.h), the following patch corrects a cleanup flow problem in the code: --- gnutls/lib/gnutls_compress_int.c 2005-06-07 11:58:09.595990000 -0400 +++ gnutls/lib/gnutls_compress_int.c 2005-06-07 11:59:11.851880750 -0400 @@ -108,9 +108,7 @@ comp_hd_t _gnutls_comp_init(gnutls_compr if (ret->handle == NULL) { gnutls_assert(); - cleanup_ret: - gnutls_free(ret); - return NULL; + goto cleanup_ret; } } @@ -120,6 +118,10 @@ comp_hd_t _gnutls_comp_init(gnutls_compr break; } return ret; + +cleanup_ret: + gnutls_free(ret); + return NULL; } void _gnutls_comp_deinit(comp_hd_t handle, int d) Please email me directly in case of questions. Thanks! Sergey. From nmav at gnutls.org Wed Jun 8 22:51:01 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 8 Jun 2005 22:51:01 +0200 Subject: [gnutls-dev] LZO 2; configure problem; small logic patch In-Reply-To: References: Message-ID: <200506082251.01479.nmav@gnutls.org> On Tuesday 07 June 2005 19:54, Sergey Lipnevich wrote: > Hi GNUTLS developers! Hello Sergey, > I was trying to make GNUTLS work with the latest version of LZO (2.0) for > our distro, SourceMage, and came upon the following minor problems, that I > believe are not related to packaging: Thank you for reporting it and for the fixes. I've corrected some of the stuff and applied your fixes. > 2. LZO 2 is using /include/lzo for include files, is it possible to > detect this? I don't know.. Is there an easy way to do it? > Also, the file libextra/lzoconfig.h is obsolete and should > probably be part of minilzo.h. It is included in the minilzo distribution. -- Nikos Mavrogiannopoulos From flameeyes at gentoo.org Fri Jun 10 15:26:56 2005 From: flameeyes at gentoo.org (Diego 'Flameeyes' =?iso-8859-1?q?Petten=F2?=) Date: Fri, 10 Jun 2005 15:26:56 +0200 Subject: [gnutls-dev] [opencdk] Compatibility with FreeBSD (malloc.h not usable) Message-ID: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> Hi, currently opencdk-0.5.5 includes without checks, but on FreeBSD (at least on Gentoo/FreeBSD) that file just trown an #error saying to avoid using it. The attached patch applied over the sources checks in ./configure for malloc.h file and then uses it only if needed. HTH, -- Diego "Flameeyes" Petten? Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ -------------- next part -------------- A non-text attachment was scrubbed... Name: opencdk-0.5.5-fbsd.patch Type: text/x-diff Size: 1592 bytes Desc: not available URL: From jas at extundo.com Fri Jun 10 18:02:12 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 10 Jun 2005 18:02:12 +0200 Subject: [gnutls-dev] Re: [opencdk] Compatibility with FreeBSD (malloc.h not usable) In-Reply-To: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> (Diego =?iso-8859-1?Q?Petten=F2's?= message of "Fri, 10 Jun 2005 15:26:56 +0200") References: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> Message-ID: Diego 'Flameeyes' Petten? writes: > Hi, > currently opencdk-0.5.5 includes without checks, but on FreeBSD (at > least on Gentoo/FreeBSD) that file just trown an #error saying to avoid using > it. > The attached patch applied over the sources checks in ./configure for malloc.h > file and then uses it only if needed. I think we should use 'stdlib.h' instead, I see no reason to use 'malloc.h', it is non-standard. I'll sync with opencdk cvs. Thanks, Simon From jas at extundo.com Mon Jun 13 14:55:18 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 13 Jun 2005 14:55:18 +0200 Subject: [gnutls-dev] Re: [opencdk] Compatibility with FreeBSD (malloc.h not usable) In-Reply-To: (Simon Josefsson's message of "Fri, 10 Jun 2005 18:02:12 +0200") References: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> Message-ID: Simon Josefsson writes: > Diego 'Flameeyes' Petten? writes: > >> Hi, >> currently opencdk-0.5.5 includes without checks, but on FreeBSD (at >> least on Gentoo/FreeBSD) that file just trown an #error saying to avoid using >> it. >> The attached patch applied over the sources checks in ./configure for malloc.h >> file and then uses it only if needed. > > I think we should use 'stdlib.h' instead, I see no reason to use > 'malloc.h', it is non-standard. I'll sync with opencdk cvs. I rolled an OpenCDK 0.5.6, available from: ftp://ftp.gnutls.org/pub/gnutls/ http://josefsson.org/gnutls/releases/opencdk/ Let me know if it works or not. Cheers, Simon From flameeyes at gentoo.org Mon Jun 13 15:44:11 2005 From: flameeyes at gentoo.org (Diego 'Flameeyes' =?iso-8859-1?q?Petten=F2?=) Date: Mon, 13 Jun 2005 15:44:11 +0200 Subject: [gnutls-dev] Re: [opencdk] Compatibility with FreeBSD (malloc.h not usable) In-Reply-To: References: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> Message-ID: <200506131544.15819@enterprise.flameeyes.is-a-geek.org> On Monday 13 June 2005 14:55, you wrote: > I rolled an OpenCDK 0.5.6, available from: > Let me know if it works or not. Thanks that works perfectly :) Thanks again, -- Diego "Flameeyes" Petten? Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jas at extundo.com Tue Jun 14 12:25:36 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 14 Jun 2005 12:25:36 +0200 Subject: [gnutls-dev] Re: [opencdk] Compatibility with FreeBSD (malloc.h not usable) In-Reply-To: <200506131544.15819@enterprise.flameeyes.is-a-geek.org> (Diego =?iso-8859-1?Q?Petten=F2's?= message of "Mon, 13 Jun 2005 15:44:11 +0200") References: <200506101526.57043@enterprise.flameeyes.is-a-geek.org> <200506131544.15819@enterprise.flameeyes.is-a-geek.org> Message-ID: Diego 'Flameeyes' Petten? writes: > On Monday 13 June 2005 14:55, you wrote: >> I rolled an OpenCDK 0.5.6, available from: >> Let me know if it works or not. > Thanks that works perfectly :) Although I forgot to update the version info in opencdk.h.... I rolled 0.5.7 which contains a number of autoconf related bug fixes. Please test. Cheers, Simon