From lrn1986 at gmail.com Tue Oct 1 19:07:52 2013 From: lrn1986 at gmail.com (LRN) Date: Tue, 01 Oct 2013 21:07:52 +0400 Subject: [gnutls-devel] GnuTLS requires a C99 compiler on W32 Message-ID: <524B0168.1000705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GnuTLS uses gnulib's time.h, which has the following: _GL_FUNCDECL_RPL (localtime_r, struct tm *, (time_t const *restrict __timer, struct tm *restrict __result) _GL_ARG_NONNULL ((1, 2))); "restrict" is a keyword that requires -std=c99 (using mingw-w64 gcc 4.8.1), otherwise you get: In file included from ./includes/gnutls/gnutls.h:49:0, from ../../gnutls-3.2.4/lib/tpm.c:30: ./../gl/time.h:468:1: error: expected ';', ',' or ')' before '__timer' _GL_FUNCDECL_SYS (localtime_r, struct tm *, (time_t const *restrict __timer, ^ ./../gl/time.h:490:1: error: expected ';', ',' or ')' before '__timer' _GL_FUNCDECL_SYS (gmtime_r, struct tm *, (time_t const *restrict __timer, ^ The "#define restrict __restrict" from config.h doesn't reach gnulib here, because tpm.c doesn't include config.h Adding #ifdef HAVE_CONFIG_H #include #endif to tpm.c fixes this. There is another problem that prevents GnuTLS from building, but it's unrelated to this, so i'll start a new thread for it. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSSwFoAAoJEOs4Jb6SI2CwpdoIAI4omghdCLabBqvDNfI+v+jC OL5va8FXWqnrt0aUwWXbK8OYKHLlV/G092IzKKJwBQSsexRElK4oI+O+U1enuFwn qj/Zq0m6DZc+fDFisulhBBfyD2mxhoL1ig/oxklUvzJwbQ/eEkexLY4jRMArEkK+ gzD3rjr9b+83gm/tCnZiEAKCkyCLPvoAfTIb0ST7uTokDhcWFRA5X0THoxpb9cu2 /mLLe2dTiEN4lqKD9eMYYMoPoW5olr+TnSgo0WBYs0G66zgdZhLueCb/0Zq1ZDaz HXd+kkc+0kQKbrm4FizmP2nNKu9JAYFJdBz7RkY8OWvT+zZZl/GHzGNttzRhyYw= =WqY0 -----END PGP SIGNATURE----- From nmav at gnutls.org Wed Oct 2 00:27:14 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 02 Oct 2013 00:27:14 +0200 Subject: [gnutls-devel] GnuTLS requires a C99 compiler on W32 In-Reply-To: <524B0168.1000705@gmail.com> References: <524B0168.1000705@gmail.com> Message-ID: <524B4C42.4070608@gnutls.org> On 10/01/2013 07:07 PM, LRN wrote: > GnuTLS uses gnulib's time.h, which has the following: > _GL_FUNCDECL_RPL (localtime_r, struct tm *, (time_t const *restrict > __timer, struct tm *restrict __result) _GL_ARG_NONNULL ((1, 2))); [...] > The "#define restrict __restrict" from config.h doesn't reach gnulib > here, because tpm.c doesn't include config.h > Adding > #ifdef HAVE_CONFIG_H > #include > #endif > to tpm.c fixes this. I've committed a fix. Thank you, Nikos From attilamolnar at hush.com Wed Oct 2 17:41:05 2013 From: attilamolnar at hush.com (attilamolnar at hush.com) Date: Wed, 02 Oct 2013 17:41:05 +0200 Subject: [gnutls-devel] gnutls_3_0_x-2 branch Message-ID: <20131002154106.2849A6015D@smtp.hushmail.com> Hello, I noticed that the commits [0] leading to the tag gnutls_3_0_32 are not on any branch; the gnutls_3_0_x-2 branch takes a different direction with [1] being directly on top of the common ancestor, [2]. Is this deliberate? Regards, Attila [0] b69e3bd1..170def8f [1] f3ba8a40 "guile: Make builds parallel-safe." [2] 4b634a3f "removed unused code" From nmav at gnutls.org Thu Oct 3 21:39:35 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 03 Oct 2013 21:39:35 +0200 Subject: [gnutls-devel] gnutls_3_0_x-2 branch In-Reply-To: <20131002154106.2849A6015D@smtp.hushmail.com> References: <20131002154106.2849A6015D@smtp.hushmail.com> Message-ID: <524DC7F7.6050307@gnutls.org> On 10/02/2013 05:41 PM, attilamolnar at hush.com wrote: > Hello, > > I noticed that the commits [0] leading to the tag gnutls_3_0_32 are not on > any branch; the gnutls_3_0_x-2 branch takes a different direction with [1] > being directly on top of the common ancestor, [2]. > > Is this deliberate? No. Thank you for letting me know. It seems I've messed it up. I've tried to merge these two. regards, Nikos From nmav at gnutls.org Fri Oct 4 12:48:08 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Oct 2013 12:48:08 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87ob7tkbv8.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <20130915120625.GA3247@downhill.g.la> <87ob7tkbv8.fsf@gnu.org> Message-ID: <524E9CE8.1090906@gnutls.org> On 09/15/2013 11:34 PM, Ludovic Court?s wrote: > Andreas Metzler skribis: > >> On 2013-09-13 Ludovic Court?s wrote: >> [...] >>> Could you try this: >> [...] >> >> Seems to work for me. Thanks. > > Thanks, pushed as 0d34b03. > > Nikos: could you cherry-pick that patch on the relevant branches? Hello Ludo, I still have issues in master when building with multiple jobs. I get errors like: In file included from core.c:3364:0: core.x:272:323: error: 'scm_gnutls_set_certificate_credentials_x509_keys_x__subr' undeclared (first use in this function) scm_gnutls_set_certificate_credentials_x509_keys_x__raw_objtable[2] = scm_gnutls_set_certificate_credentials_x509_keys_x__subr_foreign; scm_gnutls_set_certificate_credentials_x509_keys_x__raw_objtable[3] = scm_gnutls_set_certificate_credentials_x509_keys_x__name; (((((SCM *)((scm_t_cell *) (((scm_t_bits) (0? (*(SCM*)0=((scm_gnutls_set_certificate_credentials_x509_keys_x__subr))): (scm_gnutls_set_certificate_credentials_x509_keys_x__subr)))))) [(1)]) = ((scm_subr_objcode_trampoline (3, 0, 0))))); scm_define (scm_gnutls_set_certificate_credentials_x509_keys_x__name, scm_gnutls_set_certificate_credentials_x509_keys_x__subr);; repeated few hundred times. regards, Nikos From nmav at gnutls.org Fri Oct 4 12:52:44 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Oct 2013 12:52:44 +0200 Subject: [gnutls-devel] inline command support in gnutls-cli In-Reply-To: References: <523F5D2B.9090408@gnutls.org> <52414E6E.9040802@gnutls.org> Message-ID: <524E9DFC.9070700@gnutls.org> On 10/03/2013 10:09 PM, Raj Raman wrote: > Hi Nikos, > > + Added an additional option, inline-commands-prefix, that can be used > to specify an alternative prefix to inline commands. > > The attached patch contains support for the infrastructure support in > gnutls-cli to support inline commands. The comments in the file > inline_cmds.h (below) describes this facility. We found this especially > useful to test session resumption and session renegotiation with HTTPS > servers (or MITM devices) that support HTTP persistence, since a single > secure connection can support multiple HTTP requests. The implementation > makes no assumptions on contextual boundary of TCP data. The existing > behavior of command line options ?-r? and ?-e? remains unchanged. Applied. Thank you! Nikos From ludo at gnu.org Fri Oct 4 13:44:38 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 04 Oct 2013 13:44:38 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <524E9CE8.1090906@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 04 Oct 2013 12:48:08 +0200") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <20130915120625.GA3247@downhill.g.la> <87ob7tkbv8.fsf@gnu.org> <524E9CE8.1090906@gnutls.org> Message-ID: <87mwmpw995.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On 09/15/2013 11:34 PM, Ludovic Court?s wrote: >> Andreas Metzler skribis: >> >>> On 2013-09-13 Ludovic Court?s wrote: >>> [...] >>>> Could you try this: >>> [...] >>> >>> Seems to work for me. Thanks. >> >> Thanks, pushed as 0d34b03. >> >> Nikos: could you cherry-pick that patch on the relevant branches? > > Hello Ludo, > I still have issues in master when building with multiple jobs. I get > errors like: > > In file included from core.c:3364:0: > core.x:272:323: error: > 'scm_gnutls_set_certificate_credentials_x509_keys_x__subr' undeclared > (first use in this function) > scm_gnutls_set_certificate_credentials_x509_keys_x__raw_objtable[2] = > scm_gnutls_set_certificate_credentials_x509_keys_x__subr_foreign; > scm_gnutls_set_certificate_credentials_x509_keys_x__raw_objtable[3] = > scm_gnutls_set_certificate_credentials_x509_keys_x__name; (((((SCM > *)((scm_t_cell *) (((scm_t_bits) (0? > (*(SCM*)0=((scm_gnutls_set_certificate_credentials_x509_keys_x__subr))): > (scm_gnutls_set_certificate_credentials_x509_keys_x__subr)))))) [(1)]) = > ((scm_subr_objcode_trampoline (3, 0, 0))))); scm_define > (scm_gnutls_set_certificate_credentials_x509_keys_x__name, > scm_gnutls_set_certificate_credentials_x509_keys_x__subr);; Is it reproducible with ?cd guile ; make clean && make -j?? Could you check the contents of core.x: is it incomplete? What?s on line 273? Are you sure all the relevant patches have been applied? What version of GNU Make are you using? Thanks in advance, Ludo?. From attilamolnar at hush.com Fri Oct 4 17:19:34 2013 From: attilamolnar at hush.com (Attila Molnar) Date: Fri, 04 Oct 2013 17:19:34 +0200 Subject: [gnutls-devel] [PATCH 1/2] Fix srptool issues Message-ID: <20131004151934.EF6DF6018E@smtp.hushmail.com> >From 1fac0e5352e88addb8bf57dcac126918f19d7303 Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Tue, 1 Oct 2013 13:40:01 +0200 Subject: [PATCH 1/2] srptool: Fix inability to add users to tpasswd and broken -i switch Signed-off-by: Attila Molnar --- src/srptool-args.def | 2 ++ src/srptool.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/srptool-args.def b/src/srptool-args.def index 5794ff4..cb78e3b 100644 --- a/src/srptool-args.def +++ b/src/srptool-args.def @@ -18,6 +18,8 @@ short-usage = "srptool [options]\nsrptool --help for usage instructions.\n"; flag = { name = index; value = i; + arg-type = number; + arg-default = 1; descrip = "specify the index of the group parameters in tpasswd.conf to use."; doc = ""; }; diff --git a/src/srptool.c b/src/srptool.c index b653034..7955b49 100644 --- a/src/srptool.c +++ b/src/srptool.c @@ -496,7 +496,7 @@ int main (int argc, char **argv) return crypt_int (username, passwd, salt_size, - fpasswd_conf, fpasswd, VALUE_OPT_INDEX); + fpasswd_conf, fpasswd, OPT_VALUE_INDEX); } -- From attilamolnar at hush.com Fri Oct 4 17:21:49 2013 From: attilamolnar at hush.com (Attila Molnar) Date: Fri, 04 Oct 2013 17:21:49 +0200 Subject: [gnutls-devel] [PATCH 2/2] Fix srptool issues Message-ID: <20131004152150.211CC6018E@smtp.hushmail.com> >From dc3a0d6d8d4aa98ccb19641e6668a03d77f381f1 Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Tue, 1 Oct 2013 13:42:10 +0200 Subject: [PATCH 2/2] srptool: Fix segfault when an invalid group parameter index is given If no group with the given index was found in the password conf file srptool crashed instead of reporting the error because the return value of fgets() wasn't validated before it was passed to atoi(). Signed-off-by: Attila Molnar --- src/srptool.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/srptool.c b/src/srptool.c index 7955b49..debc94b 100644 --- a/src/srptool.c +++ b/src/srptool.c @@ -576,9 +576,8 @@ crypt_int (const char *username, const char *passwd, int salt_size, do { /* find the specified uindex in file */ p = fgets (line, sizeof (line) - 1, fd); - iindex = atoi (p); } - while (p != NULL && iindex != uindex); + while (p != NULL && (iindex = atoi (p)) != uindex); if (p == NULL) { -- From attilamolnar at hush.com Fri Oct 4 17:35:40 2013 From: attilamolnar at hush.com (Attila Molnar) Date: Fri, 04 Oct 2013 17:35:40 +0200 Subject: [gnutls-devel] [PATCH 2/2] Fix srptool issues In-Reply-To: <20131004152150.211CC6018E@smtp.hushmail.com> Message-ID: <20131004153540.AE1396018E@smtp.hushmail.com> Hello Nikos, hello everyone Please take a look at the attached patches, these issues prevented the srptool examples in the doc from working. Tested on 3.0 and 3.2, but most likely 3.1 is affected as well. Regenerate srptool-args.{c|h} after applying the first patch. Regards, Attila From nmav at gnutls.org Fri Oct 4 19:19:20 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Oct 2013 19:19:20 +0200 Subject: [gnutls-devel] [PATCH 2/2] Fix srptool issues In-Reply-To: <20131004153540.AE1396018E@smtp.hushmail.com> References: <20131004153540.AE1396018E@smtp.hushmail.com> Message-ID: <524EF898.3060504@gnutls.org> On 10/04/2013 05:35 PM, Attila Molnar wrote: > Hello Nikos, hello everyone > > Please take a look at the attached patches, these issues prevented the > srptool examples in the doc from working. > Tested on 3.0 and 3.2, but most likely 3.1 is affected as well. > > Regenerate srptool-args.{c|h} after applying the first patch. Thank you Attila. I've applied the patches. regards, Nikos From nmav at gnutls.org Fri Oct 4 19:25:38 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Oct 2013 19:25:38 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87mwmpw995.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <20130915120625.GA3247@downhill.g.la> <87ob7tkbv8.fsf@gnu.org> <524E9CE8.1090906@gnutls.org> <87mwmpw995.fsf@gnu.org> Message-ID: <524EFA12.40605@gnutls.org> On 10/04/2013 01:44 PM, Ludovic Court?s wrote: > Is it reproducible with ?cd guile ; make clean && make -j?? > > Could you check the contents of core.x: is it incomplete? What?s on > line 273? > > Are you sure all the relevant patches have been applied? Hello Ludo, It may be a fake alarm. Sorry. I switched PCs and some old files may have been remained. After distclean, I couldn't reproduce the issue. It seems solved. regards, Nikos From rajramanca at gmail.com Fri Oct 4 21:18:41 2013 From: rajramanca at gmail.com (Raj Raman) Date: Fri, 4 Oct 2013 12:18:41 -0700 Subject: [gnutls-devel] inline command support in gnutls-cli Message-ID: 1. By making a contribution to this project, I certify that: 2. 3. (a) The contribution was created in whole or in part by me and I 4. have the right to submit it under the open source license 5. indicated in the file; or 6. 7. (b) The contribution is based upon previous work that, to the best 8. of my knowledge, is covered under an appropriate open source 9. license and I have the right under that license to submit that 10. work with modifications, whether created in whole or in part 11. by me, under the same open source license (unless I am 12. permitted to submit under a different license), as indicated 13. in the file; or 14. 15. (c) The contribution was provided directly to me by some other 16. person who certified (a), (b) or (c) and I have not modified 17. it. 18. 19. (d) I understand and agree that this project and the contribution 20. are public and that a record of the contribution (including all 21. personal information I submit with it, including my sign-off) is 22. maintained indefinitely and may be redistributed consistent with 23. this project or the open source license(s) involved. Signed-off-by: Raj Raman rajramanca at gmail.com On Fri, Oct 4, 2013 at 3:54 AM, Nikos Mavrogiannopoulos wrote: > On 10/03/2013 10:09 PM, Raj Raman wrote: > > Hi Nikos, > > > > + Added an additional option, inline-commands-prefix, that can be used > > to specify an alternative prefix to inline commands. > > btw. I forgot. Could you send the DCO to the list? > > [0]. http://www.gnutls.org/devel.html > > regards, > Nikos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaak.ristioja at cyber.ee Mon Oct 7 13:08:00 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 07 Oct 2013 14:08:00 +0300 Subject: [gnutls-devel] _gnutls_io_check_recv returning GNUTLS_E_PUSH_ERROR Message-ID: <52529610.5020701@cyber.ee> Hello! The _gnutls_io_check_recv functions returns GNUTLS_E_PUSH_ERROR if the session->internals.pull_timeout_func(fd, ms) fails. This is very confusing for developers, since the no push function is actually called. Can this behaviour be fixed? Best regards, Jaak Ristioja From attilamolnar at hush.com Wed Oct 9 20:21:26 2013 From: attilamolnar at hush.com (Attila Molnar) Date: Wed, 09 Oct 2013 20:21:26 +0200 Subject: [gnutls-devel] [PATCH 2/2] Fix srptool issues In-Reply-To: <524EF96A.2000901@gmail.com> References: <20131004153540.AE1396018E@smtp.hushmail.com> <524EF96A.2000901@gmail.com> Message-ID: <20131009182126.82890C04B1@smtp.hushmail.com> Hello, By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Regards, Attila On 2013. October 4. at 7:22 PM, "Nikos Mavrogiannopoulos" wrote: > >On 10/04/2013 05:35 PM, Attila Molnar wrote: >> Hello Nikos, hello everyone >> >> Please take a look at the attached patches, these issues >prevented the >> srptool examples in the doc from working. >> Tested on 3.0 and 3.2, but most likely 3.1 is affected as well. >> >> Regenerate srptool-args.{c|h} after applying the first patch. > >Hello Attila, > >btw. Even though your changes are small and you can avoid it, >would you >like to send the DCO to the list? > >http://www.gnutls.org/devel.html > > >regards, >Nikos From stbuehler at lighttpd.net Sat Oct 12 17:40:11 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Sat, 12 Oct 2013 17:40:11 +0200 Subject: [gnutls-devel] cipher suites Message-ID: <20131012174011.7ab59ef1@chromobil.localdomain> Hi, I'd like to ask whether there are good reasons why many valid combinations of (key exchange, cipher, mac) are not supported, although they theoretically should work. For example CAMELLIA-CBC ciphers should work with EC key exchanges too, and also support other MACs too, for example: TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 regards, Stefan From nmav at gnutls.org Sun Oct 13 12:38:43 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Oct 2013 12:38:43 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131012174011.7ab59ef1@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> Message-ID: On Sat, Oct 12, 2013 at 5:40 PM, Stefan B?hler wrote: > Hi, > I'd like to ask whether there are good reasons why many valid > combinations of (key exchange, cipher, mac) are not supported, although > they theoretically should work. > For example CAMELLIA-CBC ciphers should work with EC key exchanges too, > and also support other MACs too, for example: > TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 Hello Stefan, Do you mean the ciphersuites in rfc6367? There is no particular reason except that they have not been added yet (the problem with several ciphersuites is that they are added in many unrelated documents). It is now in my todo list. regards, Nikos From stbuehler at lighttpd.net Sun Oct 13 15:36:40 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Sun, 13 Oct 2013 15:36:40 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: References: <20131012174011.7ab59ef1@chromobil.localdomain> Message-ID: <20131013153640.5d5a21d8@chromobil.localdomain> Hi again, On Sun, 13 Oct 2013 12:38:43 +0200 Nikos Mavrogiannopoulos wrote: > On Sat, Oct 12, 2013 at 5:40 PM, Stefan B?hler > wrote: > > Hi, > > I'd like to ask whether there are good reasons why many valid > > combinations of (key exchange, cipher, mac) are not supported, > > although they theoretically should work. > > For example CAMELLIA-CBC ciphers should work with EC key exchanges > > too, and also support other MACs too, for example: > > TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 > > Hello Stefan, > Do you mean the ciphersuites in rfc6367? There is no particular > reason except that they have not been added yet (the problem with > several ciphersuites is that they are added in many unrelated > documents). It is now in my todo list. Ok. So I did some research to find all not supported ciphersuites (using the list from debian unstable, gnutls 3.2.4), and grouped them. Supporting ARIA would be nice too I guess :) The CCM ciphers are not even defined for ECDHE, so I guess this means they are not considered good enough. DES, RC4-40 and RC2-40 are defined in ciphers.c, but not used afaics. combinations that should be easy (only need to fill ciphersuites.c): TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DH_anon_WITH_AES_256_GCM_SHA384 TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 TLS_PSK_WITH_AES_256_CBC_SHA384 TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384 TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384 TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384 null cipher: TLS_NULL_WITH_NULL_NULL TLS_PSK_WITH_NULL_SHA TLS_DHE_PSK_WITH_NULL_SHA TLS_RSA_PSK_WITH_NULL_SHA TLS_PSK_WITH_NULL_SHA384 TLS_DHE_PSK_WITH_NULL_SHA384 TLS_RSA_PSK_WITH_NULL_SHA256 TLS_RSA_PSK_WITH_NULL_SHA384 TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDHE_PSK_WITH_NULL_SHA export ciphers (GNUTLS_CIPHER_ARCFOUR_40 and GNUTLS_CIPHER_RC2_40_CBC exist but are unused, DES40 doesn't exist): TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC4_40_SHA TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_MD5 DES cipher (GNUTLS_CIPHER_DES_CBC exists, but isn't used): TLS_RSA_WITH_DES_CBC_SHA TLS_DH_DSS_WITH_DES_CBC_SHA TLS_DH_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_KRB5_WITH_DES_CBC_SHA TLS_KRB5_WITH_DES_CBC_MD5 IDEA cipher: TLS_RSA_WITH_IDEA_CBC_SHA TLS_KRB5_WITH_IDEA_CBC_SHA TLS_KRB5_WITH_IDEA_CBC_MD5 SEED cipher: TLS_RSA_WITH_SEED_CBC_SHA TLS_DHE_DSS_WITH_SEED_CBC_SHA TLS_DHE_RSA_WITH_SEED_CBC_SHA TLS_DH_anon_WITH_SEED_CBC_SHA AES-CCM ciphers: TLS_RSA_WITH_AES_128_CCM TLS_RSA_WITH_AES_256_CCM TLS_DHE_RSA_WITH_AES_128_CCM TLS_DHE_RSA_WITH_AES_256_CCM TLS_RSA_WITH_AES_128_CCM_8 TLS_RSA_WITH_AES_256_CCM_8 TLS_DHE_RSA_WITH_AES_128_CCM_8 TLS_DHE_RSA_WITH_AES_256_CCM_8 TLS_PSK_WITH_AES_128_CCM TLS_PSK_WITH_AES_256_CCM TLS_DHE_PSK_WITH_AES_128_CCM TLS_DHE_PSK_WITH_AES_256_CCM TLS_PSK_WITH_AES_128_CCM_8 TLS_PSK_WITH_AES_256_CCM_8 TLS_PSK_DHE_WITH_AES_128_CCM_8 TLS_PSK_DHE_WITH_AES_256_CCM_8 ARIA cipher: TLS_RSA_WITH_ARIA_128_CBC_SHA256 TLS_RSA_WITH_ARIA_256_CBC_SHA384 TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256 TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384 TLS_DH_anon_WITH_ARIA_128_CBC_SHA256 TLS_DH_anon_WITH_ARIA_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384 TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384 TLS_RSA_WITH_ARIA_128_GCM_SHA256 TLS_RSA_WITH_ARIA_256_GCM_SHA384 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256 TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384 TLS_DH_anon_WITH_ARIA_128_GCM_SHA256 TLS_DH_anon_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384 TLS_PSK_WITH_ARIA_128_CBC_SHA256 TLS_PSK_WITH_ARIA_256_CBC_SHA384 TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256 TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384 TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256 TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384 TLS_PSK_WITH_ARIA_128_GCM_SHA256 TLS_PSK_WITH_ARIA_256_GCM_SHA384 TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256 TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384 TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256 TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384 TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256 TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384 TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256 TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384 TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256 TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384 TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256 TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384 KRB5 key exchange: TLS_KRB5_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_RC4_128_SHA TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_RC4_128_MD5 DH_DSS and DH_RSA key exchange: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA TLS_DH_DSS_WITH_SEED_CBC_SHA TLS_DH_DSS_WITH_AES_128_GCM_SHA256 TLS_DH_DSS_WITH_AES_256_GCM_SHA384 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DH_RSA_WITH_SEED_CBC_SHA TLS_DH_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384 ECDH_ECDSA and ECDH_RSA key exchange: TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384 From n.mavrogiannopoulos at gmail.com Sun Oct 13 17:12:27 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 13 Oct 2013 17:12:27 +0200 Subject: [gnutls-devel] faq Message-ID: Hello, I've added a small faq [0] with two questions that are being asked over the years to client software developers that use gnutls. If you are aware of other common questions or any comments on the answers, let me know. regards, Nikos [0]. http://www.gnutls.org/faq.html From nmav at gnutls.org Sun Oct 13 17:22:26 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Oct 2013 17:22:26 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131013153640.5d5a21d8@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: On Sun, Oct 13, 2013 at 3:36 PM, Stefan B?hler wrote: > Hi again, > Ok. So I did some research to find all not supported ciphersuites > (using the list from debian unstable, gnutls 3.2.4), and grouped them. Thanks, that's a nice list. I'll check more thoroughly the next few days. I'll now only answer for the ones that there is a reason for not being there. > export ciphers (GNUTLS_CIPHER_ARCFOUR_40 and GNUTLS_CIPHER_RC2_40_CBC > exist but are unused, DES40 doesn't exist): I removed them on purpose with gnutls 3.2. There is no longer a reason for the export ciphersuites and if used they are most probably used in a downgrade attack. > DES cipher (GNUTLS_CIPHER_DES_CBC exists, but isn't used): We never added this, as DES was introduced in TLS pretty much the same time the export controls were lifted and 3DES was a better choice. > IDEA cipher: Too old cipher and I don't think there is any reason to use it today. > SEED cipher: We don't have seed in nettle. It could be considered if there is a need for this cipher. > AES-CCM ciphers: AES-CCM is a very inefficient mode of AES. Currently we have AES-GCM which is quite better. We could add it if there is a reason for it. > ARIA cipher: Same as seed. > DH_DSS and DH_RSA key exchange: No-one uses static DH keys. I don't think anyone ever did. The data from the SSL observatory show 0 certificates using static DH keys on the Internet. This is the reason we never supported them. > ECDH_ECDSA and ECDH_RSA key exchange: The same as static DH keys. regards, Nikos From cloos at jhcloos.com Sun Oct 13 19:20:42 2013 From: cloos at jhcloos.com (James Cloos) Date: Sun, 13 Oct 2013 13:20:42 -0400 Subject: [gnutls-devel] cipher suites In-Reply-To: (Nikos Mavrogiannopoulos's message of "Sun, 13 Oct 2013 17:22:26 +0200") References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: >>>>> "SB" == Stefan B?hler writes: >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> No-one uses static DH keys. I don't think anyone ever did. The data NM> from the SSL observatory show 0 certificates using static DH keys on NM> the Internet. This is the reason we never supported them. SB>> ECDH_ECDSA and ECDH_RSA key exchange: NM> The same as static DH keys. The 'net != the web. :) OpenSSL and NSS both support ECDSA pairs. Postfix has included support for ecdsa key/cert pairs for some time now, in parallel with rsa and dsa. I'm sure it is not alone. MTAs and MUAs, at least, would have something with which to communicate. I expect, as DANE takes off, ecc will get more use. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nmav at gnutls.org Sun Oct 13 20:16:11 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Oct 2013 20:16:11 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: On Sun, Oct 13, 2013 at 7:20 PM, James Cloos wrote: > NM> No-one uses static DH keys. I don't think anyone ever did. The data > NM> from the SSL observatory show 0 certificates using static DH keys on > NM> the Internet. This is the reason we never supported them. > SB>> ECDH_ECDSA and ECDH_RSA key exchange: > > NM> The same as static DH keys. > The 'net != the web. :) > OpenSSL and NSS both support ECDSA pairs. GnuTLS supports ECDSA certificates and keys with the ephemeral ECDH (ECDHE) key exchange. What we don't support is the ECDH key exchange that uses static ECDH keys. Static DH or ECDH keys aren't widely used in the web or anywhere else and have no advantage over their ephemeral counter-parts as they fail to provide forward secrecy. regards, Nikos From nmav at gnutls.org Sun Oct 13 20:19:14 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Oct 2013 20:19:14 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: On Sun, Oct 13, 2013 at 8:16 PM, Nikos Mavrogiannopoulos wrote: > Static DH or ECDH keys aren't widely used ^^^^^^^^^^^^^^^^^^ Although I say keys, key exchange is meant here. > in the web or anywhere else and have no advantage over their ephemeral > counter-parts as they fail to provide forward secrecy. regards, Nikos From cloos at jhcloos.com Sun Oct 13 20:35:37 2013 From: cloos at jhcloos.com (James Cloos) Date: Sun, 13 Oct 2013 14:35:37 -0400 Subject: [gnutls-devel] cipher suites In-Reply-To: (Nikos Mavrogiannopoulos's message of "Sun, 13 Oct 2013 20:16:11 +0200") References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> GnuTLS supports ECDSA certificates and keys with the ephemeral ECDH NM> (ECDHE) key exchange. What we don't support is the ECDH key exchange NM> that uses static ECDH keys. It seems that I misunderstood static. I took it to mean no ecc-based auth, as opposed to separate kex when using ecc for auth. (Not quite as bad as ?What does ?is? mean?? ?) (Or so I hope.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From dkg at fifthhorseman.net Thu Oct 17 19:39:57 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Oct 2013 13:39:57 -0400 Subject: [gnutls-devel] [PATCH] Normalize capitalization from "Public Key Id" to "Public Key ID" Message-ID: <1382031597-23124-1-git-send-email-dkg@fifthhorseman.net> The GnuTLS codebase produced the string "Public Key Id" in some places (e.g. in the output of "certtool -i"), and "Public Key ID" in other places (e.g. in the output of "certtool -k"). This changeset standardizes on "Public Key ID", making the output consistent across uses. --- lib/x509/output.c | 4 ++-- po/cs.po.in | 2 +- po/de.po.in | 2 +- po/eo.po.in | 2 +- po/fi.po.in | 2 +- po/fr.po.in | 2 +- po/it.po.in | 2 +- po/ms.po.in | 2 +- po/nl.po.in | 2 +- po/pl.po.in | 2 +- po/sv.po.in | 2 +- po/uk.po.in | 2 +- po/vi.po.in | 2 +- po/zh_CN.po.in | 2 +- tests/cert-tests/aki-cert.pem | 2 +- tests/cert-tests/bmpstring.pem | 2 +- tests/cert-tests/ca-no-pathlen.pem | 2 +- tests/cert-tests/complex-cert.pem | 2 +- tests/cert-tests/no-ca-or-pathlen.pem | 2 +- tests/hostname-check.c | 18 +++++++++--------- 20 files changed, 29 insertions(+), 29 deletions(-) diff --git a/lib/x509/output.c b/lib/x509/output.c index 530984c..22cf6b0 100644 --- a/lib/x509/output.c +++ b/lib/x509/output.c @@ -1608,7 +1608,7 @@ print_keyid (gnutls_buffer_st * str, gnutls_x509_crt_t cert) return; } - adds (str, _("\tPublic Key Id:\n\t\t")); + adds (str, _("\tPublic Key ID:\n\t\t")); _gnutls_buffer_hexprint (str, buffer, size); adds (str, "\n"); @@ -2447,7 +2447,7 @@ print_crq_other (gnutls_buffer_st * str, gnutls_x509_crq_t crq) return; } - adds (str, _("\tPublic Key Id:\n\t\t")); + adds (str, _("\tPublic Key ID:\n\t\t")); _gnutls_buffer_hexprint (str, buffer, size); adds (str, "\n"); diff --git a/po/cs.po.in b/po/cs.po.in index bcf1de4..1337bd5 100644 --- a/po/cs.po.in +++ b/po/cs.po.in @@ -1365,7 +1365,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tID ve?ejn?ho kl??e:\n" diff --git a/po/de.po.in b/po/de.po.in index 7604d95..efdbc9d 100644 --- a/po/de.po.in +++ b/po/de.po.in @@ -1358,7 +1358,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tKennung des ?ffentlichen Schl?ssels:\n" diff --git a/po/eo.po.in b/po/eo.po.in index 5a38df9..7082177 100644 --- a/po/eo.po.in +++ b/po/eo.po.in @@ -1351,7 +1351,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tPublik-?losila Id:\n" diff --git a/po/fi.po.in b/po/fi.po.in index 944a6a4..152391e 100644 --- a/po/fi.po.in +++ b/po/fi.po.in @@ -1352,7 +1352,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tJulkisen avaimen tunniste:\n" diff --git a/po/fr.po.in b/po/fr.po.in index 7fa9cca..7b51f82 100644 --- a/po/fr.po.in +++ b/po/fr.po.in @@ -866,7 +866,7 @@ msgstr "" #: x509/output.c:1188 x509/output.c:1956 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tId de clef publique:\n" diff --git a/po/it.po.in b/po/it.po.in index 4914a44..1091c3d 100644 --- a/po/it.po.in +++ b/po/it.po.in @@ -1354,7 +1354,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tId della chiave pubblica:\n" diff --git a/po/ms.po.in b/po/ms.po.in index 4260eb4..08aea54 100644 --- a/po/ms.po.in +++ b/po/ms.po.in @@ -824,7 +824,7 @@ msgstr "" #: lib/x509/output.c:985 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tId Kekunci Awam:\n" diff --git a/po/nl.po.in b/po/nl.po.in index 5d0d1e1..5ab868d 100644 --- a/po/nl.po.in +++ b/po/nl.po.in @@ -1356,7 +1356,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tID van publieke sleutel:\n" diff --git a/po/pl.po.in b/po/pl.po.in index ec5fb5e..2c3540d 100644 --- a/po/pl.po.in +++ b/po/pl.po.in @@ -1351,7 +1351,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tIdentyfikator klucza publicznego:\n" diff --git a/po/sv.po.in b/po/sv.po.in index 27858f9..767242d 100644 --- a/po/sv.po.in +++ b/po/sv.po.in @@ -1241,7 +1241,7 @@ msgstr "" #: lib/x509/output.c:1385 lib/x509/output.c:2248 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tPublik nyckel-identitet:\n" diff --git a/po/uk.po.in b/po/uk.po.in index 5310bf4..a5e9a66 100644 --- a/po/uk.po.in +++ b/po/uk.po.in @@ -1354,7 +1354,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\t?????. ?????????? ?????:\n" diff --git a/po/vi.po.in b/po/vi.po.in index e368856..2286184 100644 --- a/po/vi.po.in +++ b/po/vi.po.in @@ -1355,7 +1355,7 @@ msgstr "" #: lib/x509/output.c:1611 lib/x509/output.c:2450 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\tM? s? Kho? C?ng:\n" diff --git a/po/zh_CN.po.in b/po/zh_CN.po.in index 6505039..85d54dd 100644 --- a/po/zh_CN.po.in +++ b/po/zh_CN.po.in @@ -857,7 +857,7 @@ msgstr "" #: x509/output.c:1156 x509/output.c:1924 msgid "" -"\tPublic Key Id:\n" +"\tPublic Key ID:\n" "\t\t" msgstr "" "\t?? Id?\n" diff --git a/tests/cert-tests/aki-cert.pem b/tests/cert-tests/aki-cert.pem index c12d0be..69f7c27 100644 --- a/tests/cert-tests/aki-cert.pem +++ b/tests/cert-tests/aki-cert.pem @@ -67,7 +67,7 @@ X.509 Certificate Information: Other Information: SHA-1 fingerprint: 62f3c89771da4ce01a91fc13e02b6057b4547a1d - Public Key Id: + Public Key ID: df622ed0fe6a65a8df5b62840c826ac5b372235f Public key's random art: +--[ RSA 2048]----+ diff --git a/tests/cert-tests/bmpstring.pem b/tests/cert-tests/bmpstring.pem index 0bd2548..e44db84 100644 --- a/tests/cert-tests/bmpstring.pem +++ b/tests/cert-tests/bmpstring.pem @@ -101,7 +101,7 @@ X.509 Certificate Information: Other Information: SHA-1 fingerprint: 8b730ffbd11677aaaf8600b893927d9e402c3f2d - Public Key Id: + Public Key ID: 3c7fd9a47b17ed6f81ce80c326d147fd3b991444 Public key's random art: +--[ RSA 4096]----+ diff --git a/tests/cert-tests/ca-no-pathlen.pem b/tests/cert-tests/ca-no-pathlen.pem index 66b1c4a..e3cfbb3 100644 --- a/tests/cert-tests/ca-no-pathlen.pem +++ b/tests/cert-tests/ca-no-pathlen.pem @@ -30,7 +30,7 @@ X.509 Certificate Information: Other Information: SHA-1 fingerprint: f3ddd5478b80b142200b50c9eb2ee37061b09ed6 - Public Key Id: + Public Key ID: f268df0e814c0302ed338e146f57421dba44f06c Public key's random art: +--[ RSA 512]----+ diff --git a/tests/cert-tests/complex-cert.pem b/tests/cert-tests/complex-cert.pem index abac197..0c537a6 100644 --- a/tests/cert-tests/complex-cert.pem +++ b/tests/cert-tests/complex-cert.pem @@ -62,7 +62,7 @@ X.509 Certificate Information: Other Information: SHA-1 fingerprint: 5bf859ec9395b73f5ed5adfdfaa9c1add2ec23ff - Public Key Id: + Public Key ID: 1f1df37c58ffae0157ffccd8aae234092017a090 Public key's random art: +--[ RSA 2432]----+ diff --git a/tests/cert-tests/no-ca-or-pathlen.pem b/tests/cert-tests/no-ca-or-pathlen.pem index a255e07..312e3d7 100644 --- a/tests/cert-tests/no-ca-or-pathlen.pem +++ b/tests/cert-tests/no-ca-or-pathlen.pem @@ -48,7 +48,7 @@ warning: signed using a broken signature algorithm that can be forged. Other Information: SHA-1 fingerprint: 8f735c5ddefd723f59b6a3bb2ac0522470c0182f - Public Key Id: + Public Key ID: 1e09d707d4e3651b84dcb6c68a828d2affef7ec3 Public key's random art: +--[ RSA 1024]----+ diff --git a/tests/hostname-check.c b/tests/hostname-check.c index a9c421b..2dd31da 100644 --- a/tests/hostname-check.c +++ b/tests/hostname-check.c @@ -81,7 +81,7 @@ char pem1[] = " fd845ded8c28ba5e78d6c1844ceafd24\n" " SHA-1 fingerprint:\n" " 0bae431dda3cae76012b82276e4cd92ad7961798\n" - " Public Key Id:\n" + " Public Key ID:\n" " e93c1cfbad926ee606a4562ca2e1c05327c8f295\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -139,7 +139,7 @@ char pem2[] = " 30cda7de4f0360892547974f45111ac1\n" " SHA-1 fingerprint:\n" " 39e3f8fec6a8d842390b6536998a957c1a6b7322\n" - " Public Key Id:\n" + " Public Key ID:\n" " e93c1cfbad926ee606a4562ca2e1c05327c8f295\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -201,7 +201,7 @@ char pem3[] = " df3f57d00c8149bd826b177d6ea4f369\n" " SHA-1 fingerprint:\n" " e95e56e2acac305f72ea6f698c11624663a595bd\n" - " Public Key Id:\n" + " Public Key ID:\n" " e93c1cfbad926ee606a4562ca2e1c05327c8f295\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -264,7 +264,7 @@ char pem4[] = " a411da7b0fa064d214116d5f94e06c24\n" " SHA-1 fingerprint:\n" " 3596e796c73ed096d762ab3d440a9ab55a386b3b\n" - " Public Key Id:\n" + " Public Key ID:\n" " e93c1cfbad926ee606a4562ca2e1c05327c8f295\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -311,7 +311,7 @@ char pem6[] = " Subject Key Identifier (not critical):\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "Other Information:\n" - " Public Key Id:\n" + " Public Key ID:\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -359,7 +359,7 @@ char pem7[] = " Subject Key Identifier (not critical):\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "Other Information:\n" - " Public Key Id:\n" + " Public Key ID:\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -407,7 +407,7 @@ char pem8[] = " Subject Key Identifier (not critical):\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "Other Information:\n" - " Public Key Id:\n" + " Public Key ID:\n" " 5493e6599b283b4529378818aef9a4abbf4d9918\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -470,7 +470,7 @@ char pem9[] = " f27b18092c7497f206e70f504eee0f8e\n" " SHA-1 fingerprint:\n" " bebdac9d0dd54e8f044642e0f065fae5d75ca6e5\n" - " Public Key Id:\n" + " Public Key ID:\n" " 4cb90a9bfa1d34e37edecbd20715fea1dacb6891\n" "\n" "-----BEGIN CERTIFICATE-----\n" @@ -549,7 +549,7 @@ char pem10[] = " 0b4d6d944200cdd1639008b24dc0fe0a\n" " SHA-1 fingerprint:\n" " ce85660f5451b0cc12f525577f0eb9411a20c76b\n" - " Public Key Id:\n" + " Public Key ID:\n" " a1d18c15e65c7c4935512eeea7ca5d3e6baad4e1\n" "\n" "-----BEGIN CERTIFICATE-----\n" -- 1.8.4.rc3 From stbuehler at lighttpd.net Sun Oct 20 20:15:50 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Sun, 20 Oct 2013 20:15:50 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131013153640.5d5a21d8@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> Message-ID: <20131020201550.198afe4f@chromobil.localdomain> Hi, On Sun, 13 Oct 2013 15:36:40 +0200 Stefan B?hler wrote: > combinations that should be easy (only need to fill ciphersuites.c): > [...] > TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 > TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 > TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 > TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 > TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 > TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 > TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 > TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 > TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 > TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 > TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256 > TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384 > TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 > TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384 > TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256 > TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384 > [...] I was wrong; although nettle supports GCM with all 128-bit block ciphers, the Camellia-{128,256}-GCM ciphers are not listed in the supported cipher list in GnuTLS yet. As I recently learned that GnuTLS (sometimes) does its own AES/GCM stuff due to AES-NI, I'm not sure how hard it would be to combine the AES-NI GCM implementation with the Camellia implementation from nettle. (Also it'd be really nice to have AES-NI accelerated AES/GCM in nettle instead - I think it belongs there :) ) Also I wanted to ask about the state of the (ESTREAM)-Salsa20 ciphersuites. The draft at http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 expired some days ago, and the numbers GnuTLS is using for them (0xE4, 0x10-0x39) are not actually private - they are just unassigned. (According to http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml only (0xFF,0x00-0xFF) is reserved for private use). regards, Stefan From joaotavora at gmail.com Thu Oct 17 17:19:56 2013 From: joaotavora at gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Date: Thu, 17 Oct 2013 16:19:56 +0100 Subject: [gnutls-devel] "Error in the push function" using gnutls >= 3.2.1-w32 Message-ID: Hi, I'm on Microsoft Windows XP. Using gnutls 3.1.8-w32, I get in some servers, but not others: $ ./gnutls-cli -p 443 siscog.campfirenow.com Processed 154 CA certificate(s). Resolving 'siscog.campfirenow.com'... Connecting to '204.62.114.183:443'... *** Fatal error: An illegal TLS extension was received. *** Handshake has failed GnuTLS error: An illegal TLS extension was received. I had to switch to gnutls >= 3.2.1 since it is the first one supporting the ECC cypher, which appears to be TLS extension required by this server (but not by github.com, apparently). However I get an even weirder error: $ ./gnutls-cli -p 443 siscog.campfirenow.com Processed 154 CA certificate(s). Resolving 'siscog.campfirenow.com'... Connecting to '204.62.114.183:443'... *** Fatal error: Error in the push function. *** Handshake has failed GnuTLS error: Error in the push function. This bit of detail might be interesting, I haven't dug into the source: *** Fatal error: Error in the push function. |<4>| REC: Sending Alert[2|80] - Internal error |<7>| WRITE FLUSH: 233 bytes in buffer. |<2>| errno: 5 |<2>| ASSERT: gnutls_buffers.c:171 |<7>| WRITE error: code -53, 233 bytes left. |<2>| ASSERT: gnutls_buffers.c:644 |<2>| ASSERT: gnutls_record.c:573 *** Handshake has failed If you're curious, I originally discovered this using gnutls embedded in Emacs, but apparently it's reproducible using gnutls-cli. Also FWIW, w32 version of curl and openssl work. Thanks, Jo?o From nmav at gnutls.org Mon Oct 21 13:00:00 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Oct 2013 13:00:00 +0200 Subject: [gnutls-devel] [PATCH] Normalize capitalization from "Public Key Id" to "Public Key ID" In-Reply-To: <1382031597-23124-1-git-send-email-dkg@fifthhorseman.net> References: <1382031597-23124-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <52650930.9060408@gnutls.org> On 10/17/2013 07:39 PM, Daniel Kahn Gillmor wrote: > The GnuTLS codebase produced the string "Public Key Id" in some places > (e.g. in the output of "certtool -i"), and "Public Key ID" in other > places (e.g. in the output of "certtool -k"). > > This changeset standardizes on "Public Key ID", making the output > consistent across uses. Applied, thanks. From grothoff at in.tum.de Mon Oct 21 18:24:00 2013 From: grothoff at in.tum.de (Christian Grothoff) Date: Mon, 21 Oct 2013 18:24:00 +0200 Subject: [gnutls-devel] DCO: Christian Grothoff Message-ID: <52655520.6020105@in.tum.de> Hi! Here is my DCO. 1. 2. Developer's Certificate of Origin 1.1 3. 4. By making a contribution to this project, I certify that: 5. 6. (a) The contribution was created in whole or in part by me and I 7. have the right to submit it under the open source license 8. indicated in the file; or 9. 10. (b) The contribution is based upon previous work that, to the best 11. of my knowledge, is covered under an appropriate open source 12. license and I have the right under that license to submit that 13. work with modifications, whether created in whole or in part 14. by me, under the same open source license (unless I am 15. permitted to submit under a different license), as indicated 16. in the file; or 17. 18. (c) The contribution was provided directly to me by some other 19. person who certified (a), (b) or (c) and I have not modified 20. it. 21. 22. (d) I understand and agree that this project and the contribution 23. are public and that a record of the contribution (including all 24. personal information I submit with it, including my sign-off) is 25. maintained indefinitely and may be redistributed consistent with 26. this project or the open source license(s) involved. Best regards, Christian -- http://grothoff.org/christian/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x48426C7E.asc Type: application/pgp-keys Size: 8569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From c.seitz at tu-bs.de Mon Oct 21 18:48:03 2013 From: c.seitz at tu-bs.de (Christoph Seitz) Date: Mon, 21 Oct 2013 18:48:03 +0200 Subject: [gnutls-devel] Wrong parsing of path_len template field in certtool Message-ID: <52655AC3.2070303@tu-bs.de> Hi, I just saw, that the path_len field in a certtool template is parsed as boolean. So the only possibility is no path len constraint or 1. But I guess other (or bigger) values should be also allowed and so the field must be parsed as integer, right? Kind Regards, -- Christoph Seitz ASCII ribbon campaign ( ) against HTML e-mail X / \ From nmav at gnutls.org Mon Oct 21 20:06:24 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Oct 2013 20:06:24 +0200 Subject: [gnutls-devel] Wrong parsing of path_len template field in certtool In-Reply-To: <52655AC3.2070303@tu-bs.de> References: <52655AC3.2070303@tu-bs.de> Message-ID: <52656D20.6070802@gnutls.org> On 10/21/2013 06:48 PM, Christoph Seitz wrote: > Hi, > > I just saw, that the path_len field in a certtool template is parsed as > boolean. So the only possibility is no path len constraint or 1. But I > guess other (or bigger) values should be also allowed and so the field > must be parsed as integer, right? You're correct. I've committed a fix. regards, Nikos From nmav at gnutls.org Tue Oct 22 14:58:32 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Oct 2013 14:58:32 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131020201550.198afe4f@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> Message-ID: <52667678.6050600@gnutls.org> On 10/20/2013 08:15 PM, Stefan B?hler wrote: > Hi, > I was wrong; although nettle supports GCM with all 128-bit block > ciphers, the Camellia-{128,256}-GCM ciphers are not listed in the > supported cipher list in GnuTLS yet. I have added most, if not all of the missing ciphersuites. Unfortunately for several of them there are no test servers I can test against (e.g., camellia-gcm). Hence, I have not enabled them by default. > As I recently learned that GnuTLS (sometimes) does its own AES/GCM stuff > due to AES-NI, I'm not sure how hard it would be to combine the AES-NI > GCM implementation with the Camellia implementation from nettle. > (Also it'd be really nice to have AES-NI accelerated AES/GCM in > nettle instead - I think it belongs there :) ) gnutls overrides the nettle implementation's only if per-cpu optimizations such as aes-ni/padlock are detected. I also think it would be nicer if nettle could accommodate these (in fact this is what I miss most from nettle). > Also I wanted to ask about the state of the (ESTREAM)-Salsa20 > ciphersuites. > The draft at http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 > expired some days ago, and the numbers GnuTLS is using for them (0xE4, > 0x10-0x39) are not actually private - they are just unassigned. > (According to > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > only (0xFF,0x00-0xFF) is reserved for private use). It is high likely that private use would clash with other private extensions in other ciphersuites. I used the "Specification required range" in hope that they will be assigned these numbers soon. If the draft is not approved (or approved with major changes), I may consider moving them to private range or dropping them completely. http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 regards, Nikos From jeff at kosowsky.org Tue Oct 22 22:55:59 2013 From: jeff at kosowsky.org (Jeffrey J. Kosowsky) Date: Tue, 22 Oct 2013 16:55:59 -0400 Subject: [gnutls-devel] Incompatibility between Emacs/gnutls and Emacs/cygwin-mount Message-ID: <21094.58975.303967.74570@consult.pretender> I am running Emacs 24.3.1 under Windows 7 on an Intel core 5 machine. I loaded in the latest gnutls-3.2.4-win32 binaries fron gnutls.org. I then ran: (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps") which leads to a sudden, *fatal* emacs crash. Emacs gives me the following error in the message line before immediately crashing the entire emacs process: GnuTLS error: #, -64 The Windows crash both then gives me the following error: Problem signature: Problem Event Name: APPCRASH Application Name: emacs.exe Application Version: 24.2.50.0 Application Timestamp: 5037d090 Fault Module Name: libgnutls-28.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 501d8392 Exception Code: c0000005 Exception Offset: 0000657e OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 I found that the crash is caused by an incompatibility with the cygwin-mount library and in particular by a call to the cygwin program mount.exe. Indeed, settting /bin/mount.exe to /bin/true.exe eliminates the crash. I presume that the issue is due to an incompatibility (probably with cygwin.dll). Note that I am running Cygwin 1.7.25 x86_64, so perhaps it is either a version incompatibility or an architecture incompatibility. Any thoughts on how to debug and fix? See here for a thread on the Emacs bug report... https://groups.google.com/forum/#!searchin/gnu.emacs.bug/bug$2315648/gnu.emacs.bug/KUGJTx5XpNY/mtSgDn7v-W8J From eliz at gnu.org Wed Oct 23 04:46:44 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 23 Oct 2013 05:46:44 +0300 Subject: [gnutls-devel] Incompatibility between Emacs/gnutls and Emacs/cygwin-mount In-Reply-To: <21094.58975.303967.74570@consult.pretender> References: <21094.58975.303967.74570@consult.pretender> Message-ID: <8338nsk8kr.fsf@gnu.org> > From: "Jeffrey J. Kosowsky" > Date: Tue, 22 Oct 2013 16:55:59 -0400 > > I am running Emacs 24.3.1 under Windows 7 on an Intel core 5 machine. > I loaded in the latest gnutls-3.2.4-win32 binaries fron gnutls.org. > > I then ran: > (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps") > > which leads to a sudden, *fatal* emacs crash. Emacs gives me the > following error in the message line before immediately crashing the > entire emacs process: GnuTLS error: #, -64 > > The Windows crash both then gives me the following error: > Problem signature: > Problem Event Name: APPCRASH > Application Name: emacs.exe > Application Version: 24.2.50.0 > Application Timestamp: 5037d090 > Fault Module Name: libgnutls-28.dll > Fault Module Version: 0.0.0.0 > Fault Module Timestamp: 501d8392 > Exception Code: c0000005 > Exception Offset: 0000657e > OS Version: 6.1.7601.2.1.0.768.3 > Locale ID: 1033 > Additional Information 1: 0a9e > Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 > Additional Information 3: 0a9e > Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 > > I found that the crash is caused by an incompatibility with the > cygwin-mount library and in particular by a call to the cygwin program > mount.exe. Indeed, settting /bin/mount.exe to /bin/true.exe eliminates > the crash. > > I presume that the issue is due to an incompatibility (probably with > cygwin.dll). Where exactly do mount.exe and cygwin-mount come into play here? > Any thoughts on how to debug and fix? Run Emacs under GDB, and provide the backtrace from the crash, that should give some clues regarding the reasons. The information you show above (from the Windows Event Viewer, it seems) is insufficient for that purpose. From jeff at kosowsky.org Wed Oct 23 06:22:58 2013 From: jeff at kosowsky.org (Jeffrey J. Kosowsky) Date: Wed, 23 Oct 2013 00:22:58 -0400 Subject: [gnutls-devel] Incompatibility between Emacs/gnutls and Emacs/cygwin-mount In-Reply-To: References: Message-ID: <21095.20258.539724.105847@consult.pretender> Jeffrey J. Kosowsky wrote at about 16:56:25 -0400 on Tuesday, October 22, 2013: > I am running Emacs 24.3.1 under Windows 7 on an Intel core 5 machine. > I loaded in the latest gnutls-3.2.4-win32 binaries fron gnutls.org. > > I then ran: > (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps") > > which leads to a sudden, *fatal* emacs crash. Emacs gives me the > following error in the message line before immediately crashing the > entire emacs process: GnuTLS error: #, -64 > > The Windows crash both then gives me the following error: > Problem signature: > Problem Event Name: APPCRASH > Application Name: emacs.exe > Application Version: 24.2.50.0 > Application Timestamp: 5037d090 > Fault Module Name: libgnutls-28.dll > Fault Module Version: 0.0.0.0 > Fault Module Timestamp: 501d8392 > Exception Code: c0000005 > Exception Offset: 0000657e > OS Version: 6.1.7601.2.1.0.768.3 > Locale ID: 1033 > Additional Information 1: 0a9e > Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 > Additional Information 3: 0a9e > Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 > > I found that the crash is caused by an incompatibility with the > cygwin-mount library and in particular by a call to the cygwin program > mount.exe. Indeed, settting /bin/mount.exe to /bin/true.exe eliminates > the crash. > > I presume that the issue is due to an incompatibility (probably with > cygwin.dll). Note that I am running Cygwin 1.7.25 x86_64, so perhaps > it is either a version incompatibility or an architecture > incompatibility. > > Any thoughts on how to debug and fix? > > > See here for a thread on the Emacs bug report... > > https://groups.google.com/forum/#!searchin/gnu.emacs.bug/bug$2315648/gnu.emacs.bug/KUGJTx5XpNY/mtSgDn7v-W8J OK... I think I figured out the problem. The problem is that the Emacs Lisp file gnutls.el uses *nix style paths in the definition of the variable gnutls-trustfiles. (defcustom gnutls-trustfiles '( "/etc/ssl/certs/ca-certificates.crt" ; Debian, Ubuntu, Gentoo and Arch Linux "/etc/pki/tls/certs/ca-bundle.crt" ; Fedora and RHEL "/etc/ssl/ca-bundle.pem" ; Suse "/usr/ssl/certs/ca-bundle.crt" ; Cygwin ) When cygwin-mount.el is loaded/activated, the Lisp-code properly parses and recognizes these paths. However, presumably the C-code (which is not affected by cygwin-mount.el) does not know how to handle *nix style paths and crashes Emacs. Indeed, if I set the final element to the Windows style path equivalent: "C:/cygwin/usr/ssl/certs/ca-bundle.crt" then gnutls works fine without crashing. So, the problem clearly is with *nix-style paths Stepping through the *Lisp* code shows that the file paths are all properly parsed when cygwin-mount is loaded/activated. Indeed, file-exists-p properly recognizes the cygwin path "/usr/ssl/certs/ca-bundle.crt" and returns nil on the other paths that don't exist in a standard Cygwin setup. Note that if cygwin-mount is not loaded/activated, then "/usr/ssl/certs/ca-bundle.crt" (along with the other list elements) fails the file-exists-p test in gnutls-negotiate so that 'trustfiles' gets set to nil which explains why it doesn't crash in the case when cygwin-mount is not used since trivially 'trustfiles' has no paths associated with it. So, basically, we have the following Catch-22. If cygwin-mount is not loaded/activated, then the cert location for Cygwin is never found. If cygwin-mount is activated then it causes a crash. The result being that in Windows, no certs are ever loaded when using the default definition of gnutls-trustfiles Presumably the problem is that the C-code doesn't know how to deal with a Cygwin (*nix) style path that has been properly recognized and validated by the Lisp code (via cygwin-mount). It seems like there are two potential solutions: 1. Use Windows-style paths in the definition of gnutls-trustfiles (this should work in Linux too, since Windows-style paths like "C:/usr/ssl/certs/ca-bundle.crt" will generally and appropriately fail the file-exists-p test) 2. Add cygwin-mount functionality to the C-code so that it can parse cygwin (Unix) style paths. In any case, I imagine the C-code crashes because it sees a Unix-style path while expecting a Windows style path... that being said the C-code should be better behaved than that... at a minimum the code should check to make sure the certificate file path is well-formed and exists. From christian at grothoff.org Wed Oct 23 12:09:40 2013 From: christian at grothoff.org (Christian Grothoff) Date: Wed, 23 Oct 2013 12:09:40 +0200 Subject: [gnutls-devel] [patch] DANE_F_IGNORE_DNSSEC Message-ID: <5267A064.7090001@grothoff.org> Hi! With the new dane_raw_tlsa and dane_verify_crt_raw APIs, it is now possible to validate a certificate chain against DANE/TLSA data that was not fetched by libunbound. However, even though DNSSEC might not have been used to obtain the DANE/TLSA data, GnuTLS currently always attempts to load the DNSSEC root key and if that fails the DANE/TLSA validation is not possible --- even though DNSSEC itself is not triggered by dane_raw_tlsa/dane_verify_crt_raw. The attached patch adds an option DANE_F_IGNORE_DNSSEC which can be used to disable loading of the DNSSEC root key. Naturally, if the option is not explicitly set, everything stays as it was (so the change is backwards-compatible). Happy hacking! Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adding-option-DANE_F_IGNORE_DNSSEC-to-disable-loadin.patch Type: text/x-patch Size: 2482 bytes Desc: not available URL: From nmav at gnutls.org Wed Oct 23 13:24:40 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Oct 2013 13:24:40 +0200 Subject: [gnutls-devel] gnutls 3.1.15 Message-ID: <5267B1F8.1070603@gnutls.org> Hello, I've just released gnutls 3.1.15. This is a bug-fix release on the current stable branch. * Version 3.1.15 (released 2013-10-23) ** srptool: Fixed index command line option. Patch by Attila Molnar. ** certtool: pathlen constraint is now read correctly. Reported by Christoph Seitz. ** libdane: Added interfaces to allow initialization of dane_query_t from external DNS resolutions, and to allow direct verification of a certificate chain against a dane_query_t. Contributed by Christian Grothoff. ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could be triggered by a DNS server supplying more than 4 DANE records. Report and fix by Christian Grothoff. ** API and ABI modifications: dane_verify_crt_raw: Added dane_raw_tlsa: Added 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.1/gnutls-3.1.15.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.15.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 Wed Oct 23 13:33:20 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Oct 2013 13:33:20 +0200 Subject: [gnutls-devel] gnutls 3.2.5 Message-ID: <5267B400.2080609@gnutls.org> Hello, I've just released gnutls 3.2.5. This is a bug-fix release on the next stable branch. * Version 3.2.5 (released 2013-10-23) ** libgnutls: Documentation and build-time fixes. ** libgnutls: Allow the generation of DH groups of less than 700 bits. ** libgnutls: Added several combinations of ciphersuites with SHA256 and SHA384 as MAC, as well as Camellia with GCM. ** libdane: Added interfaces to allow initialization of dane_query_t from external DNS resolutions, and to allow direct verification of a certificate chain against a dane_query_t. Contributed by Christian Grothoff. ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could be triggered by a DNS server supplying more than 4 DANE records. Report and fix by Christian Grothoff. ** srptool: Fixed index command line option. Patch by Attila Molnar. ** gnutls-cli: Added support for inline commands, using the --inline-commands-prefix and --inline-commands options. Patch by Raj Raman. ** certtool: pathlen constraint is now read correctly. Reported by Christoph Seitz. ** API and ABI modifications: gnutls_certificate_get_crt_raw: Added dane_verify_crt_raw: Added dane_raw_tlsa: Added 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.2/gnutls-3.2.5.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.5.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.5.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.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 nmav at gnutls.org Wed Oct 23 18:47:49 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Oct 2013 18:47:49 +0200 Subject: [gnutls-devel] [patch] DANE_F_IGNORE_DNSSEC In-Reply-To: <5267A064.7090001@grothoff.org> References: <5267A064.7090001@grothoff.org> Message-ID: <5267FDB5.6030400@gnutls.org> On 10/23/2013 12:09 PM, Christian Grothoff wrote: > Hi! > > With the new dane_raw_tlsa and dane_verify_crt_raw APIs, it is now > possible to > validate a certificate chain against DANE/TLSA data that was not fetched by > libunbound. However, even though DNSSEC might not have been used to > obtain the > DANE/TLSA data, GnuTLS currently always attempts to load the DNSSEC root key > and if that fails the DANE/TLSA validation is not possible --- even though > DNSSEC itself is not triggered by dane_raw_tlsa/dane_verify_crt_raw. > > The attached patch adds an option DANE_F_IGNORE_DNSSEC which can be used to > disable loading of the DNSSEC root key. Naturally, if the option is not > explicitly set, everything stays as it was (so the change is > backwards-compatible). Applied. Thank you. From nmav at gnutls.org Thu Oct 24 09:57:47 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 24 Oct 2013 09:57:47 +0200 Subject: [gnutls-devel] gnutls 3.2.5 In-Reply-To: <20131024092716.6f61bda5@redhat.com> References: <5267B400.2080609@gnutls.org> <20131024092716.6f61bda5@redhat.com> Message-ID: <5268D2FB.3060507@gnutls.org> On 10/24/2013 09:27 AM, Tomas Hoger wrote: >> ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could >> be triggered by a DNS server supplying more than 4 DANE records. >> Report and fix by Christian Grothoff. > This sounds like a security fix rather than just a regular bug fix, but > 3.2.5 and 3.1.15 releases were not announced as security updates. As I > can't say I'm familiar with DANE, I wonder if I may be missing some > good reason why this isn't or should not be considered a security fix. Hello, It is a security fix. There is no different process for them though. I should assign a GNUTLS-SA though. regards, Nikos From thoger at redhat.com Thu Oct 24 10:58:21 2013 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 24 Oct 2013 10:58:21 +0200 Subject: [gnutls-devel] gnutls 3.2.5 In-Reply-To: <5268D2FB.3060507@gnutls.org> References: <5267B400.2080609@gnutls.org> <20131024092716.6f61bda5@redhat.com> <5268D2FB.3060507@gnutls.org> Message-ID: <20131024105821.2c1ff8fb@redhat.com> On Thu, 24 Oct 2013 09:57:47 +0200 Nikos Mavrogiannopoulos wrote: > On 10/24/2013 09:27 AM, Tomas Hoger wrote: > > >> ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This > >> could be triggered by a DNS server supplying more than 4 DANE > >> records. Report and fix by Christian Grothoff. > > > > This sounds like a security fix rather than just a regular bug fix, > > but 3.2.5 and 3.1.15 releases were not announced as security > > updates. As I can't say I'm familiar with DANE, I wonder if I may > > be missing some good reason why this isn't or should not be > > considered a security fix. > > It is a security fix. There is no different process for them though. > I should assign a GNUTLS-SA though. Ok, thank you for quick confirmation. I understand there's no different process to produce such updates, tagging them as security can help downstreams spot such must have fixes. -- Tomas Hoger / Red Hat Security Response Team From thoger at redhat.com Thu Oct 24 09:27:16 2013 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 24 Oct 2013 09:27:16 +0200 Subject: [gnutls-devel] gnutls 3.2.5 In-Reply-To: <5267B400.2080609@gnutls.org> References: <5267B400.2080609@gnutls.org> Message-ID: <20131024092716.6f61bda5@redhat.com> On Wed, 23 Oct 2013 13:33:20 +0200 Nikos Mavrogiannopoulos wrote: > ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could > be triggered by a DNS server supplying more than 4 DANE records. > Report and fix by Christian Grothoff. This sounds like a security fix rather than just a regular bug fix, but 3.2.5 and 3.1.15 releases were not announced as security updates. As I can't say I'm familiar with DANE, I wonder if I may be missing some good reason why this isn't or should not be considered a security fix. -- Tomas Hoger / Red Hat Security Response Team From Christoph_Zettl at web.de Thu Oct 24 12:08:53 2013 From: Christoph_Zettl at web.de (Christoph Zettl) Date: Thu, 24 Oct 2013 12:08:53 +0200 Subject: [gnutls-devel] FTP not available? Message-ID: <5268F1B5.30508@web.de> Hi, i can not access the ftp to download the newest Version of gnutls. I only get the Message 220-Welcome hacker! from the FTP-Server. I do need the newest stable Version (3.1.15) of the w32 build. Can you plz fix that issue or send me the newest build to ChristophZettl at googlemail.com Thanks Christoph From stbuehler at lighttpd.net Thu Oct 24 16:37:58 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Thu, 24 Oct 2013 16:37:58 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <52667678.6050600@gnutls.org> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> Message-ID: <20131024163758.6b651cc5@chromobil.localdomain> Hi, On Tue, 22 Oct 2013 14:58:32 +0200 Nikos Mavrogiannopoulos wrote: > I have added most, if not all of the missing ciphersuites. > Unfortunately for several of them there are no test servers I can > test against (e.g., camellia-gcm). Hence, I have not enabled them by > default. You missed 3 afaics: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 With priority string "SECURE256:+SECURE128:-DHE-DSS:-ECDHE-ECDSA" this should lead to something like this right now: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [...] It would really be nice not to see a SHA1 cipher as first "non-GCM" cipher in that list - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384... Thanks for adding Camellia-GCM and all the others :) regards, Stefan From alon.barlev at gmail.com Thu Oct 24 22:38:16 2013 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 24 Oct 2013 23:38:16 +0300 Subject: [gnutls-devel] [PATCH] cli: add missing stdbool.h Message-ID: <1382647096-28480-1-git-send-email-alon.barlev@gmail.com> Signed-off-by: Alon Bar-Lev --- src/cli.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/cli.c b/src/cli.c index 162fa13..325adaf 100644 --- a/src/cli.c +++ b/src/cli.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include -- 1.8.1.5 From jca at wxcvbn.org Thu Oct 24 17:56:32 2013 From: jca at wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Thu, 24 Oct 2013 17:56:32 +0200 Subject: [gnutls-devel] [PATCH] don't use gnulib error.h in tests/chainverify.c Message-ID: <87d2muvf0v.fsf@shannon.wxcvbn.org> Hi, the subject says it all. Patch against the latest (3.2.5) version. All regress tests succeed on OpenBSD-current/i386, except tests/mini-deflate.c which fails with EAGAIN. Please let me know if you commit this. I'm not suscribed to the list. $OpenBSD: patch-tests_chainverify_c,v 1.1 2013/10/24 15:43:57 jca Exp $ --- tests/chainverify.c.orig Thu Oct 24 16:52:57 2013 +++ tests/chainverify.c Thu Oct 24 17:52:58 2013 @@ -26,7 +26,6 @@ #include #include -#include #include #include @@ -836,8 +835,11 @@ doit (void) ret = gnutls_x509_crt_init (&certs[j]); if (ret < 0) - error (EXIT_FAILURE, 0, "gnutls_x509_crt_init[%d,%d]: %s", - (int) i, (int) j, gnutls_strerror (ret)); + { + fprintf (stderr, "gnutls_x509_crt_init[%d,%d]: %s", + (int) i, (int) j, gnutls_strerror (ret)); + exit (EXIT_FAILURE); + } tmp.data = (unsigned char *) chains[i].chain[j]; tmp.size = strlen (chains[i].chain[j]); @@ -846,8 +848,11 @@ doit (void) if (debug > 2) printf ("done\n"); if (ret < 0) - error (EXIT_FAILURE, 0, "gnutls_x509_crt_import[%d,%d]: %s", - (int) i, (int) j, gnutls_strerror (ret)); + { + fprintf (stderr, "gnutls_x509_crt_import[%d,%d]: %s", + (int) i, (int) j, gnutls_strerror (ret)); + exit (EXIT_FAILURE); + } gnutls_x509_crt_print (certs[j], GNUTLS_CRT_PRINT_ONELINE, &tmp); if (debug) @@ -860,16 +865,22 @@ doit (void) ret = gnutls_x509_crt_init (&ca); if (ret < 0) - error (EXIT_FAILURE, 0, "gnutls_x509_crt_init: %s", - gnutls_strerror (ret)); + { + fprintf (stderr, "gnutls_x509_crt_init: %s", + gnutls_strerror (ret)); + exit (EXIT_FAILURE); + } tmp.data = (unsigned char *) *chains[i].ca; tmp.size = strlen (*chains[i].ca); ret = gnutls_x509_crt_import (ca, &tmp, GNUTLS_X509_FMT_PEM); if (ret < 0) - error (EXIT_FAILURE, 0, "gnutls_x509_crt_import: %s", - gnutls_strerror (ret)); + { + fprintf (stderr, "gnutls_x509_crt_import: %s", + gnutls_strerror (ret)); + exit (EXIT_FAILURE); + } if (debug > 2) printf ("done\n"); @@ -887,8 +898,11 @@ doit (void) chains[i].verify_flags, &verify_status); if (ret < 0) - error (EXIT_FAILURE, 0, "gnutls_x509_crt_list_verify[%d,%d]: %s", - (int) i, (int) j, gnutls_strerror (ret)); + { + fprintf (stderr, "gnutls_x509_crt_list_verify[%d,%d]: %s", + (int) i, (int) j, gnutls_strerror (ret)); + exit (EXIT_FAILURE); + } if (verify_status != chains[i].expected_verify_result) { From citypw at gmail.com Fri Oct 25 04:51:59 2013 From: citypw at gmail.com (Shawn) Date: Fri, 25 Oct 2013 10:51:59 +0800 Subject: [gnutls-devel] gnutls 3.2.5 In-Reply-To: <5268D2FB.3060507@gnutls.org> References: <5267B400.2080609@gnutls.org> <20131024092716.6f61bda5@redhat.com> <5268D2FB.3060507@gnutls.org> Message-ID: hey Nikos, On Thu, Oct 24, 2013 at 3:57 PM, Nikos Mavrogiannopoulos wrote: > On 10/24/2013 09:27 AM, Tomas Hoger wrote: > >>> ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could >>> be triggered by a DNS server supplying more than 4 DANE records. >>> Report and fix by Christian Grothoff. >> This sounds like a security fix rather than just a regular bug fix, but >> 3.2.5 and 3.1.15 releases were not announced as security updates. As I >> can't say I'm familiar with DANE, I wonder if I may be missing some >> good reason why this isn't or should not be considered a security fix. > > Hello, > It is a security fix. There is no different process for them though. I > should assign a GNUTLS-SA though. > This is a buffer overflow issue. I couldn't find CVE number yet. Maybe send a CVE request is not a bad idea. > regards, > Nikos > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel -- GNU powered it... GPL protect it... God blessing it... regards Shawn From citypw at gmail.com Fri Oct 25 05:38:56 2013 From: citypw at gmail.com (Shawn) Date: Fri, 25 Oct 2013 11:38:56 +0800 Subject: [gnutls-devel] gnutls 3.2.5 In-Reply-To: References: <5267B400.2080609@gnutls.org> <20131024092716.6f61bda5@redhat.com> <5268D2FB.3060507@gnutls.org> Message-ID: It already has a CVE-id: CVE-2013-4466 http://www.openwall.com/lists/oss-security/2013/10/25/2 On Fri, Oct 25, 2013 at 10:51 AM, Shawn wrote: > hey Nikos, > > On Thu, Oct 24, 2013 at 3:57 PM, Nikos Mavrogiannopoulos > wrote: >> On 10/24/2013 09:27 AM, Tomas Hoger wrote: >> >>>> ** libdane: Fixed a buffer overflow in dane_query_tlsa(). This could >>>> be triggered by a DNS server supplying more than 4 DANE records. >>>> Report and fix by Christian Grothoff. >>> This sounds like a security fix rather than just a regular bug fix, but >>> 3.2.5 and 3.1.15 releases were not announced as security updates. As I >>> can't say I'm familiar with DANE, I wonder if I may be missing some >>> good reason why this isn't or should not be considered a security fix. >> >> Hello, >> It is a security fix. There is no different process for them though. I >> should assign a GNUTLS-SA though. >> > This is a buffer overflow issue. I couldn't find CVE number yet. Maybe > send a CVE request is not a bad idea. > >> regards, >> Nikos >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at lists.gnutls.org >> http://lists.gnupg.org/mailman/listinfo/gnutls-devel > > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn -- GNU powered it... GPL protect it... God blessing it... regards Shawn From nmav at gnutls.org Fri Oct 25 09:32:15 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 09:32:15 +0200 Subject: [gnutls-devel] [PATCH] cli: add missing stdbool.h In-Reply-To: <1382647096-28480-1-git-send-email-alon.barlev@gmail.com> References: <1382647096-28480-1-git-send-email-alon.barlev@gmail.com> Message-ID: <526A1E7F.90701@gnutls.org> On 10/24/2013 10:38 PM, Alon Bar-Lev wrote: > Signed-off-by: Alon Bar-Lev > --- > src/cli.c | 1 + > 1 file changed, 1 insertion(+) Applied. Thanks. From nmav at gnutls.org Fri Oct 25 09:34:06 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 09:34:06 +0200 Subject: [gnutls-devel] [PATCH] don't use gnulib error.h in tests/chainverify.c In-Reply-To: <87d2muvf0v.fsf@shannon.wxcvbn.org> References: <87d2muvf0v.fsf@shannon.wxcvbn.org> Message-ID: <526A1EEE.8050809@gnutls.org> On 10/24/2013 05:56 PM, J?r?mie Courr?ges-Anglas wrote: > Hi, > the subject says it all. Patch against the latest (3.2.5) version. > All regress tests succeed on OpenBSD-current/i386, except > tests/mini-deflate.c which fails with EAGAIN. Applied thanks. What is the issue with mini-deflate? Could you run it with -v? Also what is the version of zlib present? regards, Nikos From nmav at gnutls.org Fri Oct 25 09:34:58 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 09:34:58 +0200 Subject: [gnutls-devel] FTP not available? In-Reply-To: <5268F1B5.30508@web.de> References: <5268F1B5.30508@web.de> Message-ID: <526A1F22.9070406@gnutls.org> On 10/24/2013 12:08 PM, Christoph Zettl wrote: > Hi, > > i can not access the ftp to download the newest Version of gnutls. > I only get the Message 220-Welcome hacker! from the FTP-Server. > I do need the newest stable Version (3.1.15) of the w32 build. > > Can you plz fix that issue or send me the newest build to > ChristophZettl at googlemail.com Hello the ftp seems to work properly. Are you sure it is not a network issue on your part? regards, Nikos From nmav at gnutls.org Fri Oct 25 09:53:02 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 09:53:02 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131024163758.6b651cc5@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> <20131024163758.6b651cc5@chromobil.localdomain> Message-ID: <526A235E.9090606@gnutls.org> On 10/24/2013 04:37 PM, Stefan B?hler wrote: > Hi, > > On Tue, 22 Oct 2013 14:58:32 +0200 > Nikos Mavrogiannopoulos wrote: > >> I have added most, if not all of the missing ciphersuites. >> Unfortunately for several of them there are no test servers I can >> test against (e.g., camellia-gcm). Hence, I have not enabled them by >> default. > > You missed 3 afaics: > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Indeed. > TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 These two exist though. > With priority string "SECURE256:+SECURE128:-DHE-DSS:-ECDHE-ECDSA" this > should lead to something like this right now: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > [...] > > It would really be nice not to see a SHA1 cipher as first "non-GCM" > cipher in that list - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384... In the normal priority string HMAC-SHA1 is still preferred. SHA256 and SHA384 add significant overhead per packet without really adding much into security. regards, Nikos From dam at opencsw.org Fri Oct 25 10:31:31 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Oct 2013 10:31:31 +0200 Subject: [gnutls-devel] FTP not available? In-Reply-To: <526A1F22.9070406@gnutls.org> References: <5268F1B5.30508@web.de> <526A1F22.9070406@gnutls.org> Message-ID: <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> Hi, Am 25.10.2013 um 09:34 schrieb Nikos Mavrogiannopoulos : > On 10/24/2013 12:08 PM, Christoph Zettl wrote: >> i can not access the ftp to download the newest Version of gnutls. >> I only get the Message 220-Welcome hacker! from the FTP-Server. >> I do need the newest stable Version (3.1.15) of the w32 build. >> >> Can you plz fix that issue or send me the newest build to >> ChristophZettl at googlemail.com > > Hello the ftp seems to work properly. Are you sure it is not a network > issue on your part? I think Christoph is referring to the absence of 3.1.15 in ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ @Christoph: Is there any reason why you just don't use the latest version available? (3.2.4) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From w.bergsten at sirrix.com Fri Oct 25 11:29:23 2013 From: w.bergsten at sirrix.com (Wolfgang Meyer zu Bergsten) Date: Fri, 25 Oct 2013 11:29:23 +0200 Subject: [gnutls-devel] PKCS#11 generate random functionality Message-ID: <526A39F3.3080405@sirrix.com> Hello, is there interest in including the random generator functionality of PKCS#11 tokens in GnuTLS? I would be happy to contribute the attached implementation. I tried my best to follow the GnuTLS coding standards and other conventions in the existing code. The patch implements a new public function: int gnutls_pkcs11_token_get_random (const char *token_url, size_t len, gnutls_datum_t *rnddata) If you are interested in the functionality, but are unhappy with the proposed implementation, I will be ready to change the code accordingly. best regards, Wolfgang Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -- Sirrix AG security technologies http://www.sirrix.com Dipl.-Ing. Wolfgang Meyer zu Bergsten eMail: w.bergsten at sirrix.com Vorstand: Ammar Alkassar (Vors.), Christian St?ble, Markus Bernhammer Vorsitzender des Aufsichtsrates: Dipl.-Ing. Harald St?ber Sitz der Gesellschaft: Homburg/Saar, HRB 3857 Amtsgericht Saarbr?cken This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-implementation-of-generate-random-for-pkcs11.patch Type: text/x-patch Size: 4475 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Oct 25 12:13:30 2013 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 25 Oct 2013 12:13:30 +0200 Subject: [gnutls-devel] FTP not available? In-Reply-To: <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> References: <5268F1B5.30508@web.de> <526A1F22.9070406@gnutls.org> <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> Message-ID: <526A444A.5080901@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/25/2013 10:31 AM, Dagobert Michelsen wrote: > Hi, > > Am 25.10.2013 um 09:34 schrieb Nikos Mavrogiannopoulos > : >> On 10/24/2013 12:08 PM, Christoph Zettl wrote: >>> i can not access the ftp to download the newest Version of >>> gnutls. I only get the Message 220-Welcome hacker! from the >>> FTP-Server. I do need the newest stable Version (3.1.15) of the >>> w32 build. >>> >>> Can you plz fix that issue or send me the newest build to >>> ChristophZettl at googlemail.com >> >> Hello the ftp seems to work properly. Are you sure it is not a >> network issue on your part? FWIW I notice the same behavior from my network point in Norway. kristianf at kflaptop ~ $ ftp ftp.gnutls.org Connected to ftp.gnutls.org (217.69.76.55). 220-Welcome hacker! 421 Service not available, remote server has closed connection - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Timendi causa est nescire The cause of fear is ignorance -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta255 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSakRGAAoJEAt/i2Dj7frjtXkQAK7KOa9nJ/o3vtPywxGFy0N9 xTILnjxzpWT+d8dHNOCGGagPbGjiVAp71vRjLCgdW00OigZ+UCuB6VXhwm4ghITC e7BV1CM/Q2Rolc3F1GdM5X3XyE9qoR6kn+gl39XL3ljQv2cpy7mbKw+HNJvkaM0B VHdeFuVliKmNBL5IG63tBPsWxkwm2pLCZoJ7s3fdS0IZ84UR2f3Y1PcL2Y7oDmpN wlP+9xXDgixOU2dg4s8/Whrhf0rlcNmhtlj7VpskOX6iVz9obILdFEWJS+J4kCkp Rgo0VB7cShqXfbwP6+cUkZXwz0ZNOr9vIqCx19Hsvj/3qNIJUuv3JHh/umAmIzf3 YwUhNPjigaqQPYiXoqd+QkjJmGZaNDyVTxhIqGEsUoM2c9k1Om9y+E1ThbQ7oklg lT/0JtfYzwygC06JG7WEFUflzqMpLcqvFIDzQGooGmb5jReEOLshrnOw5NfFBppW YHjMBWEjee6lbidVfoMOsm9W5lDQQEhPRRBftyfP3M0dNghlxK+3WF+y4f92tY11 fz/arIexIg1uVLAQms401tzLQWMhim6bUx++6wVz9DTewp3HzTRcE+FEopduJvKx u37St8fwK30V53EP3mHx+f7ttDMi2n0FZUkTFxuBZarihgxLfZOtnvsNoT97GzVo 71adjeaXvrhl5qDYgR3F =z6ex -----END PGP SIGNATURE----- From stbuehler at lighttpd.net Fri Oct 25 12:56:25 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Fri, 25 Oct 2013 12:56:25 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <526A235E.9090606@gnutls.org> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> <20131024163758.6b651cc5@chromobil.localdomain> <526A235E.9090606@gnutls.org> Message-ID: <20131025125625.430c35fb@chromobil.localdomain> Hi, On Fri, 25 Oct 2013 09:53:02 +0200 Nikos Mavrogiannopoulos wrote: > > TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 > > TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 > > These two exist though. Ah. I used the kx, cipher and mac (prf for AEAD mac) algorithm names to generate the "official" TLS names. You configured these two to have mac=SHA256 - which is why i couldn't find them. I guess they should use mac=SHA384, right? From some naming inconsistencies aside I think all other names match the specified algorithms, although I didn't check whether the 16-bit id matches the official listing. The inconsistencies are: * ARCFOUR is ARCFOUR_128 in ECDH* ciphers * if the mac is SHA1 and the cipher not a SALSA20 one, PSK, DHE-PSK and RSA-PSK become *PSK-SHA From nmav at gnutls.org Fri Oct 25 14:22:27 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 14:22:27 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131025125625.430c35fb@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> <20131024163758.6b651cc5@chromobil.localdomain> <526A235E.9090606@gnutls.org> <20131025125625.430c35fb@chromobil.localdomain> Message-ID: <526A6283.3050106@gnutls.org> On 10/25/2013 12:56 PM, Stefan B?hler wrote: >>> TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 >>> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 >> These two exist though. > Ah. I used the kx, cipher and mac (prf for AEAD mac) algorithm names to > generate the "official" TLS names. You configured these two to have > mac=SHA256 - which is why i couldn't find them. I guess they should use > mac=SHA384, right? Ouch. I tried to verify each and every one but it seems I missed those. I've now fixed them. > From some naming inconsistencies aside I think all other names match the > specified algorithms, although I didn't check whether the 16-bit id > matches the official listing. > The inconsistencies are: > * ARCFOUR is ARCFOUR_128 in ECDH* ciphers > * if the mac is SHA1 and the cipher not a SALSA20 one, PSK, DHE-PSK and > RSA-PSK become *PSK-SHA This should be fixed by now. regards, Nikos From n.mavrogiannopoulos at gmail.com Fri Oct 25 14:30:48 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 14:30:48 +0200 Subject: [gnutls-devel] PKCS#11 generate random functionality In-Reply-To: <526A39F3.3080405@sirrix.com> References: <526A39F3.3080405@sirrix.com> Message-ID: <526A6478.7080307@gmail.com> On 10/25/2013 11:29 AM, Wolfgang Meyer zu Bergsten wrote: > Hello, > is there interest in including the random generator functionality of > PKCS#11 tokens in GnuTLS? I would be happy to contribute the attached > implementation. I tried my best to follow the GnuTLS coding standards > and other conventions in the existing code. > > The patch implements a new public function: > int > gnutls_pkcs11_token_get_random (const char *token_url, > size_t len, > gnutls_datum_t *rnddata) Hello Wolfgang, It looks like a nice addition. However why not follow gnutls_rnd() and just return the random data in a caller-provided buffer rather than an allocated string? I think this would make things simpler. Also adding the function into the GNUTLS_3_1_0 would be fine (instead of defining a new GNUTLS_3_2_6). regards, Nikos From w.bergsten at sirrix.com Fri Oct 25 15:23:43 2013 From: w.bergsten at sirrix.com (Wolfgang Meyer zu Bergsten) Date: Fri, 25 Oct 2013 15:23:43 +0200 Subject: [gnutls-devel] PKCS#11 generate random functionality In-Reply-To: <526A6478.7080307@gmail.com> References: <526A39F3.3080405@sirrix.com> <526A6478.7080307@gmail.com> Message-ID: <526A70DF.1050203@sirrix.com> Hello Nikos, thank you for the review! On 10/25/2013 02:30 PM, Nikos Mavrogiannopoulos wrote: > On 10/25/2013 11:29 AM, Wolfgang Meyer zu Bergsten wrote: >> The patch implements a new public function: >> int >> gnutls_pkcs11_token_get_random (const char *token_url, >> size_t len, >> gnutls_datum_t *rnddata) > > Hello Wolfgang, > It looks like a nice addition. However why not follow gnutls_rnd() and > just return the random data in a caller-provided buffer rather than an > allocated string? I think this would make things simpler. That was actually my first implementation. Then I looked at the other PKCS#11 functions, and there the returned data was allocated in gnutls, so I thought I should be doing this as well. Changed in the appended patch to the proposed interface. New Interface: int gnutls_pkcs11_token_get_random (const char* token_url, void* data, size_t len); > Also adding > the function into the GNUTLS_3_1_0 would be fine (instead of defining a > new GNUTLS_3_2_6). Changed. regards, Wolfgang -- Sirrix AG security technologies http://www.sirrix.com Dipl.-Ing. Wolfgang Meyer zu Bergsten eMail: w.bergsten at sirrix.com Tel: +49 (234) 610071-131 Fax: +49 (234) 610071-531 Vorstand: Ammar Alkassar (Vors.), Christian St?ble, Markus Bernhammer Vorsitzender des Aufsichtsrates: Dipl.-Ing. Harald St?ber Sitz der Gesellschaft: Homburg/Saar, HRB 3857 Amtsgericht Saarbr?cken This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-get-random-data-from-pkcs-11-tokens.patch Type: text/x-patch Size: 4253 bytes Desc: not available URL: From Christoph_Zettl at web.de Fri Oct 25 15:34:43 2013 From: Christoph_Zettl at web.de (Christoph Zettl) Date: Fri, 25 Oct 2013 15:34:43 +0200 Subject: [gnutls-devel] FTP not available? In-Reply-To: <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> References: <5268F1B5.30508@web.de> <526A1F22.9070406@gnutls.org> <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> Message-ID: <526A7373.1080205@web.de> 25.10.2013 10:31, Dagobert Michelsen wrote: > Hi, > > Am 25.10.2013 um 09:34 schrieb Nikos Mavrogiannopoulos : >> On 10/24/2013 12:08 PM, Christoph Zettl wrote: >>> i can not access the ftp to download the newest Version of gnutls. >>> I only get the Message 220-Welcome hacker! from the FTP-Server. >>> I do need the newest stable Version (3.1.15) of the w32 build. >>> >>> Can you plz fix that issue or send me the newest build to >>> ChristophZettl at googlemail.com >> Hello the ftp seems to work properly. Are you sure it is not a network >> issue on your part? > > I think Christoph is referring to the absence of 3.1.15 in > ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ > > @Christoph: Is there any reason why you just don't use the latest version > available? (3.2.4) > > > Best regards > > -- Dago > @Niko: I now figured out, that my router-firewall interrupts the connection after the first line received. Sorry for that. I was able to download a win32(3.1.10) version now, but it took some time to get rid of that problem. @Dago: No i really had network problems, and yes I haven't tested the 3.2 yet, but will do soon. thanks for the quick answers regards Christoph From jca at wxcvbn.org Fri Oct 25 15:49:15 2013 From: jca at wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Fri, 25 Oct 2013 15:49:15 +0200 Subject: [gnutls-devel] 3.2.5 test reports on OpenBSD/i386 -current (was: Re: [PATCH] don't use gnulib error.h in tests/chainverify.c) References: <87d2muvf0v.fsf@shannon.wxcvbn.org> <526A1EEE.8050809@gnutls.org> Message-ID: <87wql15ulg.fsf@shannon.wxcvbn.org> Nikos Mavrogiannopoulos writes: > On 10/24/2013 05:56 PM, J?r?mie Courr?ges-Anglas wrote: > >> Hi, >> the subject says it all. Patch against the latest (3.2.5) version. >> All regress tests succeed on OpenBSD-current/i386, except >> tests/mini-deflate.c which fails with EAGAIN. > Applied thanks. What is the issue with mini-deflate? Could you run it > with -v? I'm confused, I've fired another build and can't reproduce this error (more than 30 ./mini-deflate runs). IIRC the "server" part in mini-deflate was failing with EAGAIN on some system call, thus the client couldn't connect, making the the whole test fail. The only thing different from yesterday is that I have upgraded to a newer version of my kernel and system. > Also what is the version of zlib present? An oldish one 1.2.3 Anyway, more reports... now that mini-deflate doesn't error out, make check goes into subdirectories. tests/: - mini-handshake-timeout seems to fail intermittently See the log at the end of the mail. tests/cert-tests/: - pem-decoding fails here because our diff executable doesn't support --strip-trailing-cr; removing the option seems to do it, but depending on GNU diff to run tests is not a problem, if you find it convenient. If so, please let us specify the diff executable with something like : ${DIFF=diff}, this lets us override with DIFF=gdiff in the environment. - aki, pathlen and pem-decoding fail with my locale (fr_FR.UTF-8). Unsetting is enough for those tests to pass. Maybe do you want to force it to C? tests/dtls/: - dtls-stress calls exit(77) if timer_create and friends aren't available (as on OpenBSD), but the Makefile.am specifies a link against librt (unavailable on said OS), which prevents the executable to be called and the test result to be skipped. ./mini-handshake-timeout -v client|<4>| REC[0x7f5da2a0]: Allocating epoch #0 client|<2>| ASSERT: gnutls_constate.c:581 client|<4>| REC[0x7f5da2a0]: Allocating epoch #1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_ECDSA_ARCFOUR_128_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_ARCFOUR_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: RSA_ARCFOUR_MD5 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 client|<3>| HSK[0x7f5da2a0]: Keeping ciphersuite: ECDH_ANON_AES_128_CBC_SHA1 (C0.18) client|<3>| HSK[0x7f5da2a0]: Keeping ciphersuite: ECDH_ANON_AES_256_CBC_SHA1 (C0.19) client|<3>| HSK[0x7f5da2a0]: Keeping ciphersuite: ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17) client|<3>| HSK[0x7f5da2a0]: Keeping ciphersuite: ECDH_ANON_ARCFOUR_128_SHA1 (C0.16) client|<3>| EXT[0x7f5da2a0]: Sending extension STATUS REQUEST (5 bytes) client|<3>| EXT[0x7f5da2a0]: Sending extension SAFE RENEGOTIATION (1 bytes) client|<3>| EXT[0x7f5da2a0]: Sending extension SESSION TICKET (0 bytes) client|<3>| EXT[0x7f5da2a0]: Sending extension SUPPORTED ECC (12 bytes) client|<3>| EXT[0x7f5da2a0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) client|<3>| EXT[0x7f5da2a0]: sent signature algo (4.1) RSA-SHA256 client|<3>| EXT[0x7f5da2a0]: sent signature algo (4.2) DSA-SHA256 client|<3>| EXT[0x7f5da2a0]: sent signature algo (4.3) ECDSA-SHA256 client|<3>| EXT[0x7f5da2a0]: sent signature algo (5.1) RSA-SHA384 client|<3>| EXT[0x7f5da2a0]: sent signature algo (5.3) ECDSA-SHA384 client|<3>| EXT[0x7f5da2a0]: sent signature algo (6.1) RSA-SHA512 client|<3>| EXT[0x7f5da2a0]: sent signature algo (6.3) ECDSA-SHA512 client|<3>| EXT[0x7f5da2a0]: sent signature algo (3.1) RSA-SHA224 client|<3>| EXT[0x7f5da2a0]: sent signature algo (3.2) DSA-SHA224 client|<3>| EXT[0x7f5da2a0]: sent signature algo (3.3) ECDSA-SHA224 client|<3>| EXT[0x7f5da2a0]: sent signature algo (2.1) RSA-SHA1 client|<3>| EXT[0x7f5da2a0]: sent signature algo (2.2) DSA-SHA1 client|<3>| EXT[0x7f5da2a0]: sent signature algo (2.3) ECDSA-SHA1 client|<3>| EXT[0x7f5da2a0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) client|<3>| HSK[0x7f5da2a0]: CLIENT HELLO was queued [125 bytes] client|<7>| HWRITE: enqueued [CLIENT HELLO] 125. Total 125 bytes. client|<7>| HWRITE FLUSH: 125 bytes in buffer. client|<4>| REC[0x7f5da2a0]: Preparing Packet Handshake(22) with length: 125 and target length: 125 client|<9>| ENC[0x7f5da2a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 client|<7>| WRITE: enqueued 130 bytes for 0x4. Total 130 bytes. client|<4>| REC[0x7f5da2a0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 130 client|<7>| HWRITE: wrote 1 bytes, 0 bytes left. client|<7>| WRITE FLUSH: 130 bytes in buffer. client|<7>| WRITE: wrote 130 bytes, 0 bytes left. client|<2>| ASSERT: gnutls_buffers.c:1018 server|<4>| REC[0x891c92a0]: Allocating epoch #0 server|<2>| ASSERT: gnutls_constate.c:581 server|<4>| REC[0x891c92a0]: Allocating epoch #1 server|<2>| ASSERT: gnutls_buffers.c:1018 server|<7>| READ: Got 5 bytes from 0x3 server|<7>| READ: read 5 bytes from 0x3 server|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. server|<7>| RB: Requested 5 bytes server|<4>| REC[0x891c92a0]: SSL 3.0 Handshake packet received. Epoch 0, length: 125 server|<4>| REC[0x891c92a0]: Expected Packet Handshake(22) server|<4>| REC[0x891c92a0]: Received Packet Handshake(22) with length: 125 server|<7>| READ: Got 125 bytes from 0x3 server|<7>| READ: read 125 bytes from 0x3 server|<7>| RB: Have 5 bytes into buffer. Adding 125 bytes. server|<7>| RB: Requested 130 bytes server|<4>| REC[0x891c92a0]: Decrypted Packet[0] Handshake(22) with length: 125 server|<6>| BUF[REC]: Inserted 125 bytes of Data(22) server|<3>| HSK[0x891c92a0]: CLIENT HELLO (1) was received. Length 121[121], frag offset 0, frag length: 121, sequence: 0 server|<3>| HSK[0x891c92a0]: Client's version: 3.3 server|<2>| ASSERT: gnutls_db.c:266 server|<3>| EXT[0x891c92a0]: Found extension 'STATUS REQUEST/5' server|<3>| EXT[0x891c92a0]: Found extension 'SAFE RENEGOTIATION/65281' server|<3>| EXT[0x891c92a0]: Found extension 'SESSION TICKET/35' server|<3>| EXT[0x891c92a0]: Found extension 'SUPPORTED ECC/10' server|<3>| EXT[0x891c92a0]: Found extension 'SUPPORTED ECC POINT FORMATS/11' server|<3>| EXT[0x891c92a0]: Found extension 'SIGNATURE ALGORITHMS/13' server|<3>| EXT[0x891c92a0]: Found extension 'STATUS REQUEST/5' server|<3>| EXT[0x891c92a0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) server|<3>| EXT[0x891c92a0]: Parsing extension 'SESSION TICKET/35' (0 bytes) server|<3>| EXT[0x891c92a0]: Found extension 'SUPPORTED ECC/10' server|<3>| EXT[0x891c92a0]: Found extension 'SUPPORTED ECC POINT FORMATS/11' server|<3>| EXT[0x891c92a0]: Found extension 'SIGNATURE ALGORITHMS/13' server|<3>| EXT[0x891c92a0]: Parsing extension 'STATUS REQUEST/5' (5 bytes) server|<3>| EXT[0x891c92a0]: Found extension 'SAFE RENEGOTIATION/65281' server|<3>| EXT[0x891c92a0]: Found extension 'SESSION TICKET/35' server|<3>| EXT[0x891c92a0]: Parsing extension 'SUPPORTED ECC/10' (12 bytes) server|<3>| HSK[0x891c92a0]: Selected ECC curve SECP192R1 (5) server|<3>| EXT[0x891c92a0]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes) server|<3>| EXT[0x891c92a0]: Parsing extension 'SIGNATURE ALGORITHMS/13' (28 bytes) server|<3>| EXT[0x891c92a0]: rcvd signature algo (4.1) RSA-SHA256 server|<3>| EXT[0x891c92a0]: rcvd signature algo (4.2) DSA-SHA256 server|<3>| EXT[0x891c92a0]: rcvd signature algo (4.3) ECDSA-SHA256 server|<3>| EXT[0x891c92a0]: rcvd signature algo (5.1) RSA-SHA384 server|<3>| EXT[0x891c92a0]: rcvd signature algo (5.3) ECDSA-SHA384 server|<3>| EXT[0x891c92a0]: rcvd signature algo (6.1) RSA-SHA512 server|<3>| EXT[0x891c92a0]: rcvd signature algo (6.3) ECDSA-SHA512 server|<3>| EXT[0x891c92a0]: rcvd signature algo (3.1) RSA-SHA224 server|<3>| EXT[0x891c92a0]: rcvd signature algo (3.2) DSA-SHA224 server|<3>| EXT[0x891c92a0]: rcvd signature algo (3.3) ECDSA-SHA224 server|<3>| EXT[0x891c92a0]: rcvd signature algo (2.1) RSA-SHA1 server|<3>| EXT[0x891c92a0]: rcvd signature algo (2.2) DSA-SHA1 server|<3>| EXT[0x891c92a0]: rcvd signature algo (2.3) ECDSA-SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_ECDSA_ARCFOUR_128_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_AES_128_GCM_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_ARCFOUR_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: RSA_ARCFOUR_MD5 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 server|<3>| HSK[0x891c92a0]: Keeping ciphersuite: ECDH_ANON_AES_128_CBC_SHA1 (C0.18) server|<3>| HSK[0x891c92a0]: Keeping ciphersuite: ECDH_ANON_AES_256_CBC_SHA1 (C0.19) server|<3>| HSK[0x891c92a0]: Keeping ciphersuite: ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17) server|<3>| HSK[0x891c92a0]: Keeping ciphersuite: ECDH_ANON_ARCFOUR_128_SHA1 (C0.16) server|<3>| HSK[0x891c92a0]: Requested cipher suites[size: 8]: server|<3>| 0xc0, 0x18 ECDH_ANON_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Selected cipher suite: ECDH_ANON_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Selected Compression Method: NULL server|<3>| HSK[0x891c92a0]: Safe renegotiation succeeded server|<2>| ASSERT: status_request.c:194 server|<3>| EXT[0x891c92a0]: Sending extension SAFE RENEGOTIATION (1 bytes) server|<3>| EXT[0x891c92a0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) server|<3>| HSK[0x891c92a0]: SessionID: 1ce0e8c52c9b92c22f8832cde7df3d3053ca2da776b86fb7a5ab8921f056ad24 server|<3>| HSK[0x891c92a0]: SERVER HELLO was queued [87 bytes] server|<7>| HWRITE: enqueued [SERVER HELLO] 87. Total 87 bytes. server|<3>| HSK[0x891c92a0]: SERVER KEY EXCHANGE was queued [57 bytes] server|<7>| HWRITE: enqueued [SERVER KEY EXCHANGE] 57. Total 144 bytes. server|<3>| HSK[0x891c92a0]: SERVER HELLO DONE was queued [4 bytes] server|<7>| HWRITE: enqueued [SERVER HELLO DONE] 4. Total 148 bytes. server|<7>| HWRITE FLUSH: 148 bytes in buffer. server|<4>| REC[0x891c92a0]: Preparing Packet Handshake(22) with length: 87 and target length: 87 server|<9>| ENC[0x891c92a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 server|<7>| WRITE: enqueued 92 bytes for 0x3. Total 92 bytes. server|<4>| REC[0x891c92a0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92 server|<7>| HWRITE: wrote 1 bytes, 61 bytes left. server|<4>| REC[0x891c92a0]: Preparing Packet Handshake(22) with length: 57 and target length: 57 server|<9>| ENC[0x891c92a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 server|<7>| WRITE: enqueued 62 bytes for 0x3. Total 154 bytes. server|<4>| REC[0x891c92a0]: Sent Packet[2] Handshake(22) in epoch 0 and length: 62 server|<7>| HWRITE: wrote 1 bytes, 4 bytes left. server|<4>| REC[0x891c92a0]: Preparing Packet Handshake(22) with length: 4 and target length: 4 server|<9>| ENC[0x891c92a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 server|<7>| WRITE: enqueued 9 bytes for 0x3. Total 163 bytes. server|<4>| REC[0x891c92a0]: Sent Packet[3] Handshake(22) in epoch 0 and length: 9 server|<7>| HWRITE: wrote 1 bytes, 0 bytes left. server|<7>| WRITE FLUSH: 163 bytes in buffer. client|<7>| READ: Got 5 bytes from 0x4 client|<7>| READ: read 5 bytes from 0x4 client|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. client|<7>| RB: Requested 5 bytes client|<4>| REC[0x7f5da2a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 87 client|<4>| REC[0x7f5da2a0]: Expected Packet Handshake(22) client|<4>| REC[0x7f5da2a0]: Received Packet Handshake(22) with length: 87 client|<7>| READ: Got 87 bytes from 0x4 client|<7>| READ: read 87 bytes from 0x4 client|<7>| RB: Have 5 bytes into buffer. Adding 87 bytes. client|<7>| RB: Requested 92 bytes client|<4>| REC[0x7f5da2a0]: Decrypted Packet[0] Handshake(22) with length: 87 server|<7>| WRITE: wrote 163 bytes, 0 bytes left. server|<2>| ASSERT: gnutls_buffers.c:1018 client|<6>| BUF[REC]: Inserted 87 bytes of Data(22) client|<3>| HSK[0x7f5da2a0]: SERVER HELLO (2) was received. Length 83[83], frag offset 0, frag length: 83, sequence: 0 client|<3>| HSK[0x7f5da2a0]: Server's version: 3.3 client|<3>| HSK[0x7f5da2a0]: SessionID length: 32 client|<3>| HSK[0x7f5da2a0]: SessionID: 1ce0e8c52c9b92c22f8832cde7df3d3053ca2da776b86fb7a5ab8921f056ad24 client|<3>| HSK[0x7f5da2a0]: Selected cipher suite: ECDH_ANON_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Selected compression method: NULL (0) client|<3>| EXT[0x7f5da2a0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) client|<3>| EXT[0x7f5da2a0]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes) client|<3>| HSK[0x7f5da2a0]: Safe renegotiation succeeded client|<2>| ASSERT: gnutls_buffers.c:1018 client|<7>| READ: Got 5 bytes from 0x4 client|<7>| READ: read 5 bytes from 0x4 client|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. client|<7>| RB: Requested 5 bytes client|<4>| REC[0x7f5da2a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 57 client|<4>| REC[0x7f5da2a0]: Expected Packet Handshake(22) client|<4>| REC[0x7f5da2a0]: Received Packet Handshake(22) with length: 57 client|<7>| READ: Got 57 bytes from 0x4 client|<7>| READ: read 57 bytes from 0x4 client|<7>| RB: Have 5 bytes into buffer. Adding 57 bytes. client|<7>| RB: Requested 62 bytes client|<4>| REC[0x7f5da2a0]: Decrypted Packet[1] Handshake(22) with length: 57 client|<6>| BUF[REC]: Inserted 57 bytes of Data(22) client|<3>| HSK[0x7f5da2a0]: SERVER KEY EXCHANGE (12) was received. Length 53[53], frag offset 0, frag length: 53, sequence: 0 client|<3>| HSK[0x7f5da2a0]: Selected ECC curve SECP192R1 (5) client|<2>| ASSERT: gnutls_buffers.c:1018 client|<7>| READ: Got 5 bytes from 0x4 client|<7>| READ: read 5 bytes from 0x4 client|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. client|<7>| RB: Requested 5 bytes client|<4>| REC[0x7f5da2a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 4 client|<4>| REC[0x7f5da2a0]: Expected Packet Handshake(22) client|<4>| REC[0x7f5da2a0]: Received Packet Handshake(22) with length: 4 client|<7>| READ: Got 4 bytes from 0x4 client|<7>| READ: read 4 bytes from 0x4 client|<7>| RB: Have 5 bytes into buffer. Adding 4 bytes. client|<7>| RB: Requested 9 bytes client|<4>| REC[0x7f5da2a0]: Decrypted Packet[2] Handshake(22) with length: 4 client|<6>| BUF[REC]: Inserted 4 bytes of Data(22) client|<3>| HSK[0x7f5da2a0]: SERVER HELLO DONE (14) was received. Length 0[0], frag offset 0, frag length: 1, sequence: 0 client|<3>| HSK[0x7f5da2a0]: CLIENT KEY EXCHANGE was queued [54 bytes] client|<7>| HWRITE: enqueued [CLIENT KEY EXCHANGE] 54. Total 54 bytes. client|<7>| HWRITE: enqueued [CHANGE CIPHER SPEC] 1. Total 55 bytes. client|<3>| REC[0x7f5da2a0]: Sent ChangeCipherSpec client|<9>| INT: PREMASTER SECRET[24]: c074142daf27c20cf9fd4cc0c7e18ed8dd9d598499e8a764 client|<9>| INT: CLIENT RANDOM[32]: 526a5eac72e7fb872d74cda11fdf5d9beaa9f49ef550ac8feb710e4c2a84dff9 client|<9>| INT: SERVER RANDOM[32]: 526a5eacafd9ff307e5190a7d3f2bac8e5fd339b30b22089184f093e7f811f9c client|<9>| INT: MASTER SECRET: df8165b85223e014a6dc9f4498afb1bdb61a48209557cc4c3c39930ac7107d5a480bde0bfac31d05ccb179df5e9b5455 client|<4>| REC[0x7f5da2a0]: Initializing epoch #1 client|<9>| INT: KEY BLOCK[104]: 25896e250eecd040502e1ef96b9124cfd1e9a439174eb217f9544ff43bcdeb70 client|<9>| INT: CLIENT WRITE KEY [16]: a580ea25c9d9b761ccc6f537fb105d38 client|<9>| INT: SERVER WRITE KEY [16]: 7bcd3962f5490bac3bf358c6281bffce client|<4>| REC[0x7f5da2a0]: Epoch #1 ready client|<3>| HSK[0x7f5da2a0]: Cipher Suite: ECDH_ANON_AES_128_CBC_SHA1 client|<3>| HSK[0x7f5da2a0]: Initializing internal [write] cipher sessions client|<3>| HSK[0x7f5da2a0]: recording tls-unique CB (send) client|<3>| HSK[0x7f5da2a0]: FINISHED was queued [16 bytes] client|<7>| HWRITE: enqueued [FINISHED] 16. Total 71 bytes. client|<7>| HWRITE FLUSH: 71 bytes in buffer. client|<4>| REC[0x7f5da2a0]: Preparing Packet Handshake(22) with length: 54 and target length: 54 client|<9>| ENC[0x7f5da2a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 client|<7>| WRITE: enqueued 59 bytes for 0x4. Total 59 bytes. client|<4>| REC[0x7f5da2a0]: Sent Packet[2] Handshake(22) in epoch 0 and length: 59 client|<7>| HWRITE: wrote 1 bytes, 17 bytes left. client|<4>| REC[0x7f5da2a0]: Preparing Packet ChangeCipherSpec(20) with length: 1 and target length: 1 client|<9>| ENC[0x7f5da2a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 client|<7>| WRITE: enqueued 6 bytes for 0x4. Total 65 bytes. client|<4>| REC[0x7f5da2a0]: Sent Packet[3] ChangeCipherSpec(20) in epoch 0 and length: 6 client|<7>| HWRITE: wrote 1 bytes, 16 bytes left. client|<4>| REC[0x7f5da2a0]: Preparing Packet Handshake(22) with length: 16 and target length: 16 client|<9>| ENC[0x7f5da2a0]: cipher: AES-128-CBC, MAC: SHA1, Epoch: 1 client|<2>| ASSERT: mac.c:253 client|<7>| WRITE: enqueued 69 bytes for 0x4. Total 134 bytes. client|<4>| REC[0x7f5da2a0]: Sent Packet[1] Handshake(22) in epoch 1 and length: 69 client|<7>| HWRITE: wrote 1 bytes, 0 bytes left. client|<7>| WRITE FLUSH: 134 bytes in buffer. server|<7>| READ: Got 5 bytes from 0x3 server|<7>| READ: read 5 bytes from 0x3 server|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. server|<7>| RB: Requested 5 bytes server|<4>| REC[0x891c92a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 54 server|<4>| REC[0x891c92a0]: Expected Packet Handshake(22) server|<4>| REC[0x891c92a0]: Received Packet Handshake(22) with length: 54 server|<7>| READ: Got 54 bytes from 0x3 server|<7>| READ: read 54 bytes from 0x3 server|<7>| RB: Have 5 bytes into buffer. Adding 54 bytes. server|<7>| RB: Requested 59 bytes server|<4>| REC[0x891c92a0]: Decrypted Packet[1] Handshake(22) with length: 54 server|<6>| BUF[REC]: Inserted 54 bytes of Data(22) server|<3>| HSK[0x891c92a0]: CLIENT KEY EXCHANGE (16) was received. Length 50[50], frag offset 0, frag length: 50, sequence: 0 server|<7>| READ: Got 5 bytes from 0x3 server|<7>| READ: read 5 bytes from 0x3 server|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. server|<7>| RB: Requested 5 bytes server|<4>| REC[0x891c92a0]: SSL 3.3 ChangeCipherSpec packet received. Epoch 0, length: 1 server|<4>| REC[0x891c92a0]: Expected Packet ChangeCipherSpec(20) server|<4>| REC[0x891c92a0]: Received Packet ChangeCipherSpec(20) with length: 1 server|<7>| READ: Got 1 bytes from 0x3 server|<7>| READ: read 1 bytes from 0x3 server|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. server|<7>| RB: Requested 6 bytes server|<4>| REC[0x891c92a0]: Decrypted Packet[2] ChangeCipherSpec(20) with length: 1 server|<6>| BUF[REC]: Inserted 1 bytes of Data(20) server|<9>| INT: PREMASTER SECRET[24]: c074142daf27c20cf9fd4cc0c7e18ed8dd9d598499e8a764 server|<9>| INT: CLIENT RANDOM[32]: 526a5eac72e7fb872d74cda11fdf5d9beaa9f49ef550ac8feb710e4c2a84dff9 server|<9>| INT: SERVER RANDOM[32]: 526a5eacafd9ff307e5190a7d3f2bac8e5fd339b30b22089184f093e7f811f9c server|<9>| INT: MASTER SECRET: df8165b85223e014a6dc9f4498afb1bdb61a48209557cc4c3c39930ac7107d5a480bde0bfac31d05ccb179df5e9b5455 server|<4>| REC[0x891c92a0]: Initializing epoch #1 server|<9>| INT: KEY BLOCK[104]: 25896e250eecd040502e1ef96b9124cfd1e9a439174eb217f9544ff43bcdeb70 server|<9>| INT: CLIENT WRITE KEY [16]: a580ea25c9d9b761ccc6f537fb105d38 server|<9>| INT: SERVER WRITE KEY [16]: 7bcd3962f5490bac3bf358c6281bffce server|<4>| REC[0x891c92a0]: Epoch #1 ready server|<3>| HSK[0x891c92a0]: Cipher Suite: ECDH_ANON_AES_128_CBC_SHA1 server|<2>| ASSERT: gnutls_buffers.c:1018 server|<7>| READ: Got 5 bytes from 0x3 server|<7>| READ: read 5 bytes from 0x3 server|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. server|<7>| RB: Requested 5 bytes server|<4>| REC[0x891c92a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 64 server|<4>| REC[0x891c92a0]: Expected Packet Handshake(22) server|<4>| REC[0x891c92a0]: Received Packet Handshake(22) with length: 64 server|<7>| READ: Got 64 bytes from 0x3 server|<7>| READ: read 64 bytes from 0x3 server|<7>| RB: Have 5 bytes into buffer. Adding 64 bytes. server|<7>| RB: Requested 69 bytes server|<2>| ASSERT: mac.c:253 server|<4>| REC[0x891c92a0]: Decrypted Packet[0] Handshake(22) with length: 16 server|<6>| BUF[REC]: Inserted 16 bytes of Data(22) server|<3>| HSK[0x891c92a0]: FINISHED (20) was received. Length 12[12], frag offset 0, frag length: 12, sequence: 0 server|<3>| HSK[0x891c92a0]: recording tls-unique CB (recv) server|<7>| HWRITE: enqueued [CHANGE CIPHER SPEC] 1. Total 1 bytes. server|<3>| REC[0x891c92a0]: Sent ChangeCipherSpec server|<3>| HSK[0x891c92a0]: Cipher Suite: ECDH_ANON_AES_128_CBC_SHA1 server|<3>| HSK[0x891c92a0]: Initializing internal [write] cipher sessions server|<3>| HSK[0x891c92a0]: FINISHED was queued [16 bytes] server|<7>| HWRITE: enqueued [FINISHED] 16. Total 17 bytes. server|<7>| HWRITE FLUSH: 17 bytes in buffer. server|<4>| REC[0x891c92a0]: Preparing Packet ChangeCipherSpec(20) with length: 1 and target length: 1 server|<9>| ENC[0x891c92a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 server|<7>| WRITE: enqueued 6 bytes for 0x3. Total 6 bytes. server|<4>| REC[0x891c92a0]: Sent Packet[4] ChangeCipherSpec(20) in epoch 0 and length: 6 server|<7>| HWRITE: wrote 1 bytes, 16 bytes left. server|<4>| REC[0x891c92a0]: Preparing Packet Handshake(22) with length: 16 and target length: 16 server|<9>| ENC[0x891c92a0]: cipher: AES-128-CBC, MAC: SHA1, Epoch: 1 server|<2>| ASSERT: mac.c:253 server|<7>| WRITE: enqueued 69 bytes for 0x3. Total 75 bytes. server|<4>| REC[0x891c92a0]: Sent Packet[1] Handshake(22) in epoch 1 and length: 69 server|<7>| HWRITE: wrote 1 bytes, 0 bytes left. server|<7>| WRITE FLUSH: 75 bytes in buffer. server|<7>| WRITE: wrote 75 bytes, 0 bytes left. server|<4>| REC[0x891c92a0]: Start of epoch cleanup server|<4>| REC[0x891c92a0]: Epoch #0 freed server|<4>| REC[0x891c92a0]: End of epoch cleanup server|<4>| REC[0x891c92a0]: Start of epoch cleanup server|<4>| REC[0x891c92a0]: End of epoch cleanup server|<4>| REC[0x891c92a0]: Epoch #1 freed Will test timeout server|<4>| REC[0x89f1a2a0]: Allocating epoch #0 client|<4>| REC[0x811d02a0]: Allocating epoch #0 client|<2>| ASSERT: gnutls_constate.c:581 client|<4>| REC[0x811d02a0]: Allocating epoch #1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_ECDSA_ARCFOUR_128_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_ARCFOUR_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: RSA_ARCFOUR_MD5 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 client|<3>| HSK[0x811d02a0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 client|<3>| HSK[0x811d02a0]: Keeping ciphersuite: ECDH_ANON_AES_128_CBC_SHA1 (C0.18) client|<3>| HSK[0x811d02a0]: Keeping ciphersuite: ECDH_ANON_AES_256_CBC_SHA1 (C0.19) client|<3>| HSK[0x811d02a0]: Keeping ciphersuite: ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17) client|<3>| HSK[0x811d02a0]: Keeping ciphersuite: ECDH_ANON_ARCFOUR_128_SHA1 (C0.16) client|<3>| EXT[0x811d02a0]: Sending extension STATUS REQUEST (5 bytes) client|<3>| EXT[0x811d02a0]: Sending extension SAFE RENEGOTIATION (1 bytes) client|<3>| EXT[0x811d02a0]: Sending extension SESSION TICKET (0 bytes) client|<3>| EXT[0x811d02a0]: Sending extension SUPPORTED ECC (12 bytes) client|<3>| EXT[0x811d02a0]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) client|<3>| EXT[0x811d02a0]: sent signature algo (4.1) RSA-SHA256 client|<3>| EXT[0x811d02a0]: sent signature algo (4.2) DSA-SHA256 client|<3>| EXT[0x811d02a0]: sent signature algo (4.3) ECDSA-SHA256 client|<3>| EXT[0x811d02a0]: sent signature algo (5.1) RSA-SHA384 client|<3>| EXT[0x811d02a0]: sent signature algo (5.3) ECDSA-SHA384 client|<3>| EXT[0x811d02a0]: sent signature algo (6.1) RSA-SHA512 client|<3>| EXT[0x811d02a0]: sent signature algo (6.3) ECDSA-SHA512 client|<3>| EXT[0x811d02a0]: sent signature algo (3.1) RSA-SHA224 client|<3>| EXT[0x811d02a0]: sent signature algo (3.2) DSA-SHA224 client|<3>| EXT[0x811d02a0]: sent signature algo (3.3) ECDSA-SHA224 client|<3>| EXT[0x811d02a0]: sent signature algo (2.1) RSA-SHA1 client|<3>| EXT[0x811d02a0]: sent signature algo (2.2) DSA-SHA1 client|<3>| EXT[0x811d02a0]: sent signature algo (2.3) ECDSA-SHA1 client|<3>| EXT[0x811d02a0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) client|<3>| HSK[0x811d02a0]: CLIENT HELLO was queued [125 bytes] client|<7>| HWRITE: enqueued [CLIENT HELLO] 125. Total 125 bytes. client|<7>| HWRITE FLUSH: 125 bytes in buffer. client|<4>| REC[0x811d02a0]: Preparing Packet Handshake(22) with length: 125 and target length: 125 client|<9>| ENC[0x811d02a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 client|<7>| WRITE: enqueued 130 bytes for 0x4. Total 130 bytes. client|<4>| REC[0x811d02a0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 130 client|<7>| HWRITE: wrote 1 bytes, 0 bytes left. client|<7>| WRITE FLUSH: 130 bytes in buffer. client|<7>| WRITE: wrote 130 bytes, 0 bytes left. client|<2>| ASSERT: gnutls_buffers.c:1018 client|<7>| WRITE: wrote 134 bytes, 0 bytes left. client|<7>| READ: Got 5 bytes from 0x4 client|<7>| READ: read 5 bytes from 0x4 client|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. client|<7>| RB: Requested 5 bytes client|<4>| REC[0x7f5da2a0]: SSL 3.3 ChangeCipherSpec packet received. Epoch 0, length: 1 client|<4>| REC[0x7f5da2a0]: Expected Packet ChangeCipherSpec(20) client|<4>| REC[0x7f5da2a0]: Received Packet ChangeCipherSpec(20) with length: 1 client|<7>| READ: Got 1 bytes from 0x4 client|<7>| READ: read 1 bytes from 0x4 client|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. client|<7>| RB: Requested 6 bytes client|<4>| REC[0x7f5da2a0]: Decrypted Packet[3] ChangeCipherSpec(20) with length: 1 client|<6>| BUF[REC]: Inserted 1 bytes of Data(20) client|<3>| HSK[0x7f5da2a0]: Cipher Suite: ECDH_ANON_AES_128_CBC_SHA1 client|<2>| ASSERT: gnutls_buffers.c:1018 client|<7>| READ: Got 5 bytes from 0x4 client|<7>| READ: read 5 bytes from 0x4 client|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. client|<7>| RB: Requested 5 bytes client|<4>| REC[0x7f5da2a0]: SSL 3.3 Handshake packet received. Epoch 0, length: 64 client|<4>| REC[0x7f5da2a0]: Expected Packet Handshake(22) client|<4>| REC[0x7f5da2a0]: Received Packet Handshake(22) with length: 64 client|<7>| READ: Got 64 bytes from 0x4 client|<7>| READ: read 64 bytes from 0x4 client|<7>| RB: Have 5 bytes into buffer. Adding 64 bytes. client|<7>| RB: Requested 69 bytes client|<2>| ASSERT: mac.c:253 client|<4>| REC[0x7f5da2a0]: Decrypted Packet[0] Handshake(22) with length: 16 client|<6>| BUF[REC]: Inserted 16 bytes of Data(22) client|<3>| HSK[0x7f5da2a0]: FINISHED (20) was received. Length 12[12], frag offset 0, frag length: 12, sequence: 0 client|<4>| REC[0x7f5da2a0]: Start of epoch cleanup client|<4>| REC[0x7f5da2a0]: Epoch #0 freed client|<4>| REC[0x7f5da2a0]: End of epoch cleanup client|<4>| REC[0x7f5da2a0]: Start of epoch cleanup client|<4>| REC[0x7f5da2a0]: End of epoch cleanup client|<4>| REC[0x7f5da2a0]: Epoch #1 freed server|<4>| REC[0x89f1a2a0]: Start of epoch cleanup server|<4>| REC[0x89f1a2a0]: End of epoch cleanup server|<4>| REC[0x89f1a2a0]: Epoch #0 freed client|<7>| READ: Got 0 bytes from 0x4 client|<7>| READ: read 0 bytes from 0x4 client|<2>| ASSERT: gnutls_buffers.c:515 client|<2>| ASSERT: gnutls_record.c:1046 client|<2>| ASSERT: gnutls_record.c:1158 client|<2>| ASSERT: gnutls_buffers.c:1228 client|<2>| ASSERT: gnutls_handshake.c:1409 client|<2>| ASSERT: gnutls_handshake.c:2701 client|<4>| REC[0x811d02a0]: Start of epoch cleanup client|<4>| REC[0x811d02a0]: End of epoch cleanup client|<4>| REC[0x811d02a0]: Epoch #0 freed client|<4>| REC[0x811d02a0]: Epoch #1 freed client: unexpected error: The TLS connection was non-properly terminated. Child died with status 1 Self test `./mini-handshake-timeout' finished with 1 errors From nmav at gnutls.org Fri Oct 25 20:10:59 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Oct 2013 20:10:59 +0200 Subject: [gnutls-devel] PKCS#11 generate random functionality In-Reply-To: <526A70DF.1050203@sirrix.com> References: <526A39F3.3080405@sirrix.com> <526A6478.7080307@gmail.com> <526A70DF.1050203@sirrix.com> Message-ID: <526AB433.8040809@gnutls.org> On 10/25/2013 03:23 PM, Wolfgang Meyer zu Bergsten wrote: > Hello Nikos, > thank you for the review! > > On 10/25/2013 02:30 PM, Nikos Mavrogiannopoulos wrote: >> On 10/25/2013 11:29 AM, Wolfgang Meyer zu Bergsten wrote: >>> The patch implements a new public function: >>> int >>> gnutls_pkcs11_token_get_random (const char *token_url, >>> size_t len, >>> gnutls_datum_t *rnddata) >> >> Hello Wolfgang, >> It looks like a nice addition. However why not follow gnutls_rnd() and >> just return the random data in a caller-provided buffer rather than an >> allocated string? I think this would make things simpler. > > That was actually my first implementation. Then I looked at the other > PKCS#11 functions, and there the returned data was allocated in gnutls, > so I thought I should be doing this as well. > > Changed in the appended patch to the proposed interface. New Interface: > > int > gnutls_pkcs11_token_get_random (const char* token_url, > void* data, > size_t len); Applied. Thank you! From nmav at gnutls.org Sat Oct 26 11:25:42 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 26 Oct 2013 11:25:42 +0200 Subject: [gnutls-devel] FTP not available? In-Reply-To: <526A444A.5080901@sumptuouscapital.com> References: <5268F1B5.30508@web.de> <526A1F22.9070406@gnutls.org> <7616A104-0204-4EFD-871A-8E2E59B212F5@opencsw.org> <526A444A.5080901@sumptuouscapital.com> Message-ID: <526B8A96.1090105@gnutls.org> On 10/25/2013 12:13 PM, Kristian Fiskerstrand wrote: >>>> Can you plz fix that issue or send me the newest build to >>>> ChristophZettl at googlemail.com >>> >>> Hello the ftp seems to work properly. Are you sure it is not a >>> network issue on your part? > > FWIW I notice the same behavior from my network point in Norway. > > kristianf at kflaptop ~ $ ftp ftp.gnutls.org > Connected to ftp.gnutls.org (217.69.76.55). > 220-Welcome hacker! > 421 Service not available, remote server has closed connection I was told by Werner that sometimes the FTP server overloads and stops accepting connections. However one can use the FTP mirror list of gnupg to obtain gnutls as well: http://www.gnupg.org/download/mirrors.en.html regards, Nikos From stbuehler at lighttpd.net Sat Oct 26 12:15:28 2013 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Sat, 26 Oct 2013 12:15:28 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <526AB145.2010404@gnutls.org> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> <20131024163758.6b651cc5@chromobil.localdomain> <526A235E.9090606@gnutls.org> <20131025125625.430c35fb@chromobil.localdomain> <526A6283.3050106@gnutls.org> <20131025152927.304014c4@chromobil.localdomain> <526AB145.2010404@gnutls.org> Message-ID: <20131026121528.68cb9ca8@chromobil.localdomain> Hi, sry, looks like my previous mail accidentally went off list. On Fri, 25 Oct 2013 19:58:29 +0200 Nikos Mavrogiannopoulos wrote: > > Nice. > > I just went for it and tried to verify the ids (involving piping > > your ciphersuites.c through the preprocessor, some iterations of > > (g)awk, sed, sort, cut, column and using saxonsb on the > > tls-parameters.xml to get javascript tables I could compare with > > the help of nodejs...): > > Hello, > Could this be automated somehow so it could be added in the > testsuite? I extracted the code and put it into a gist: https://gist.github.com/stbuehler/7167426 Depending on saxonb and nodejs for (default) tests seems wrong though. Replacing javascript with something else (perl, perhaps even bash) should be "easy", but getting rid of saxonb is probably hard; parsing xml is no fun :) Also the test should use the current http://www.iana.org/assignments/tls-parameters/tls-parameters.xml, but in automated build environments you often have no internet connection available. I used the same/similar code to generate (parts of) these files: http://blog.lighttpd.net/javascripts/gnutls-data/registry-ciphers.js http://blog.lighttpd.net/javascripts/gnutls-data/ciphers.js regards, Stefan From ametzler at bebt.de Sat Oct 26 14:25:21 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 26 Oct 2013 14:25:21 +0200 Subject: [gnutls-devel] trousers license changed to BSD Message-ID: <20131026122521.GB3271@downhill.g.la> Hello, trousers licenses seems to have been changed from COMMON PUBLIC LICENSE to BSD (3-clause) in 0.3.11. Therefore no warning against linking GnutLS with it seems to be necessary. I am not sure whether tpm should be enabled by default nevertheless. http://sourceforge.net/p/trousers/trousers/ci/0160d229f8fbab7c6900662155f42050e3d563a0/ cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: trousers-license.diff Type: text/x-diff Size: 1422 bytes Desc: not available URL: From nmav at gnutls.org Sat Oct 26 18:39:35 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 26 Oct 2013 18:39:35 +0200 Subject: [gnutls-devel] 3.2.5 test reports on OpenBSD/i386 -current In-Reply-To: <87wql15ulg.fsf@shannon.wxcvbn.org> References: <87d2muvf0v.fsf@shannon.wxcvbn.org> <526A1EEE.8050809@gnutls.org> <87wql15ulg.fsf@shannon.wxcvbn.org> Message-ID: <526BF047.60709@gnutls.org> On 10/25/2013 03:49 PM, J?r?mie Courr?ges-Anglas wrote: > Anyway, more reports... now that mini-deflate doesn't error out, make > check goes into subdirectories. > tests/: > - mini-handshake-timeout seems to fail intermittently > See the log at the end of the mail. Hello, There is something fishy there. Could it be that in openbsd a close() will terminate a TCP session prior to all data being sent? If yes, then the issue should now be solved in the repository. > tests/cert-tests/: > - pem-decoding fails here because our diff executable doesn't > support --strip-trailing-cr; removing the option seems to do it, but > depending on GNU diff to run tests is not a problem, if you find it > convenient. If so, please let us specify the diff executable with > something like : ${DIFF=diff}, this lets us override with DIFF=gdiff > in the environment. I've now set the diff as a parameter and I've also removed --strip-trailing-cr. I don't know why it was there, but there isn't a trailing-cr in these files. > - aki, pathlen and pem-decoding fail with my locale (fr_FR.UTF-8). > Unsetting is enough for those tests to pass. Maybe do you want to > force it to C? I've set LC_ALL=C in the tests environment. That should do. > tests/dtls/: > - dtls-stress calls exit(77) if timer_create and friends aren't > available (as on OpenBSD), but the Makefile.am specifies a link > against librt (unavailable on said OS), which prevents the executable > to be called and the test result to be skipped. I've now added a configure time check for librt. best regards, Nikos From nmav at gnutls.org Sat Oct 26 18:40:51 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 26 Oct 2013 18:40:51 +0200 Subject: [gnutls-devel] trousers license changed to BSD In-Reply-To: <20131026122521.GB3271@downhill.g.la> References: <20131026122521.GB3271@downhill.g.la> Message-ID: <526BF093.3010404@gnutls.org> On 10/26/2013 02:25 PM, Andreas Metzler wrote: > Hello, > > trousers licenses seems to have been changed from COMMON PUBLIC > LICENSE to BSD (3-clause) in 0.3.11. Therefore no warning against > linking GnutLS with it seems to be necessary. I am not sure whether > tpm should be enabled by default nevertheless. > > http://sourceforge.net/p/trousers/trousers/ci/0160d229f8fbab7c6900662155f42050e3d563a0/ That's very nice. I've applied a patch that also enabled TPM support by default. regards, Nikos From nmav at gnutls.org Sat Oct 26 19:02:50 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 26 Oct 2013 19:02:50 +0200 Subject: [gnutls-devel] cipher suites In-Reply-To: <20131026121528.68cb9ca8@chromobil.localdomain> References: <20131012174011.7ab59ef1@chromobil.localdomain> <20131013153640.5d5a21d8@chromobil.localdomain> <20131020201550.198afe4f@chromobil.localdomain> <52667678.6050600@gnutls.org> <20131024163758.6b651cc5@chromobil.localdomain> <526A235E.9090606@gnutls.org> <20131025125625.430c35fb@chromobil.localdomain> <526A6283.3050106@gnutls.org> <20131025152927.304014c4@chromobil.localdomain> <526AB145.2010404@gnutls.org> <20131026121528.68cb9ca8@chromobil.localdomain> Message-ID: <526BF5BA.50706@gnutls.org> On 10/26/2013 12:15 PM, Stefan B?hler wrote: > Hi, > > sry, looks like my previous mail accidentally went off list. > > On Fri, 25 Oct 2013 19:58:29 +0200 > Nikos Mavrogiannopoulos wrote: >>> Nice. >>> I just went for it and tried to verify the ids (involving piping >>> your ciphersuites.c through the preprocessor, some iterations of >>> (g)awk, sed, sort, cut, column and using saxonsb on the >>> tls-parameters.xml to get javascript tables I could compare with >>> the help of nodejs...): >> >> Hello, >> Could this be automated somehow so it could be added in the >> testsuite? > > I extracted the code and put it into a gist: > https://gist.github.com/stbuehler/7167426 > Depending on saxonb and nodejs for (default) tests seems wrong though. > Replacing javascript with something else (perl, perhaps even bash) > should be "easy", but getting rid of saxonb is probably hard; parsing > xml is no fun :) Thank you that's very useful. I've added it to the tests that are run only in the git repository (i.e., by me prior to release) so the dependencies are fine. Is there a way for nodejs to return a different error code than zero on error (e.g. a mismatch)? > Also the test should use the current > http://www.iana.org/assignments/tls-parameters/tls-parameters.xml, but > in automated build environments you often have no internet connection > available. This can be updated periodically when new ciphersuites are added so it's not a big issue. > I used the same/similar code to generate (parts of) these files: > http://blog.lighttpd.net/javascripts/gnutls-data/registry-ciphers.js > http://blog.lighttpd.net/javascripts/gnutls-data/ciphers.js That would be also useful to add in case tls-parameters.xml changes. regards, Nikos From nmav at gnutls.org Thu Oct 31 13:28:34 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 31 Oct 2013 13:28:34 +0100 Subject: [gnutls-devel] gnutls 3.2.6 Message-ID: <52724CF2.8020609@gnutls.org> Hello, I've just released gnutls 3.2.6. This release adds new features and fixes bugs on the next stable branch. The most important changes are the prioritization of the GCM mode over CBC in all priority strings, and the enabling of TPM support by default. * Version 3.2.6 (released 2013-10-31) ** libgnutls: Support for TPM via trousers is now enabled by default. ** libgnutls: Camellia in GCM mode has been added in default priorities, and GCM mode is prioritized over CBC in all of the default priority strings. ** libgnutls: Added ciphersuite GNUTLS_ECDHE_RSA_AES_256_CBC_SHA384. ** libgnutls: Fixed ciphersuites GNUTLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384, GNUTLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384 and GNUTLS_PSK_CAMELLIA_128_GCM_SHA256. Reported by Stefan Buehler. ** libgnutls: Added support for ISO OID for RSA-SHA1 signatures. ** libgnutls: Minimum acceptable DH group parameters were increased to 767 bits from 727. ** libgnutls: Added function to obtain random data from PKCS #11 tokens. Contributed by Wolfgang Meyer zu Bergsten. ** gnulib: updated. ** libdane: Fixed a one-off bug in dane_query_tlsa() introduced by the previous fix. Reported by Tomas Mraz. ** p11tool: Added option generate-random. ** API and ABI modifications: gnutls_pkcs11_token_get_random: Added 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.2/gnutls-3.2.6.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.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 Thu Oct 31 13:28:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 31 Oct 2013 13:28:48 +0100 Subject: [gnutls-devel] gnutls 3.1.16 Message-ID: <52724D00.30201@gnutls.org> Hello, I've just released gnutls 3.1.16. This is a bug-fix release on the current stable branch. * Version 3.1.16 (released 2013-10-31) ** gnulib: updated. ** libdane: Fixed a one-off bug in dane_query_tlsa() introduced by the previous fix. Reported by Tomas Mraz. ** 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.1/gnutls-3.1.16.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.16.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 jaak.ristioja at cyber.ee Thu Oct 31 16:38:15 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Thu, 31 Oct 2013 17:38:15 +0200 Subject: [gnutls-devel] GnuTLS 3.2.6 fails to build with --disable-dtls-alpn-support Message-ID: <52727967.9050409@cyber.ee> Hi! It appears there are some #ifdef ENABLE_ALPN missing from common.c around this piece of code (error on line 580): rc = gnutls_alpn_get_selected_protocol (session, &p); if (rc == 0) printf ("- Application protocol: %.*s\n", p.size, p.data); Best regards, Jaak Ristioja Cybernetica AS