http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3309 [...] FWIW adding or dropping http://svn.debian.org/wsvn/pkg-gnutls/packages/gnutls26/trunk/debian/patches/20_GNUTLS-SA-2008-3.patch?op=file&rev=0&sc=0 indeed makes gnutls-cli -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \ /etc/ssl/certs/ca-certificates.crt succeed or not succeed in verifying the server certificate. openssl s_client -connect hbci-pintan-rp.s-hbci.de:443 -CApath \ /etc/ssl/certs also reports "Verify return code: 0 (ok)" cu andreas Andreas Metzler 2008-12-03T18:19:56 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3308 GnuTLS 1.6 is rather old, and we recommend to upgrade to the latest stable branch 2.6.x. Please check if you can reproduce the problem with 2.6.x, I suspect it has been fixed already. /Simon Simon Josefsson 2008-12-03T12:04:19 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3307 Doing a rebuild on CentOS 5, of gnutls-1.6.3-1.fc8.src.rpm (from Red Hat's Raw Hide archive) yields an error which asks that I report it: =================================== 1 of 10 tests failed Please report to bug-gnutls< at >gnu.org =================================== ==9666== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from 1) ==9666== malloc/free: in use at exit: 0 bytes in 0 blocks. ==9666== malloc/free: 2 allocs, 2 frees, 157 bytes allocated. ==9666== For counts of detected errors, rerun with: -v ==9666== All heap blocks were freed -- no leaks are possible. /bin/sh: line 4: 9666 Segmentation fault PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar valgrind ${dir}$tst FAIL: openssl ==9671== Memcheck, a memory error detector. ==9671== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. This source RPM is in my directory: /home/herrold/build/libiphone/libiphone-0.1.0 and I have 'snapshotted' versions on all packages, if you need further information on the build R P Herrold 2008-12-01T23:09:19 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3306 _______________________________________________ Gnutls-devel mailing list Gnutls-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gnutls-devel ravi sharma 2008-12-01T15:35:10 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3305 No. If the connection fails for some reason you should not try to reuse it. regards, Nikos Nikos Mavrogiannopoulos 2008-11-29T08:22:17 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3304 Hello Joe, I the test case was not correct. The call (from server) to gnutls_rehandshake will only notify the client about a rehandshake. After that a call to gnutls_handshake is required. Once I do this the test case works correctly (i've also committed it). To debug (1 - gnutls-cli log output from testing using httpd/mod_ssl) you might need some output from mod_ssl as well. There the server notifies the client about a rehandshake, the client starts the handshake by sending client hello and the server replies with an alert. regards, Nikos Nikos Mavrogiannopoulos 2008-11-29T08:02:35 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3303 I've tried this using a git build of GnuTLS, gnutls-cli and a test httpd/mod_ssl server configured for per-location client cert auth (i.e. it requests a second handshake after the GET request is recevied), and it does fail, so I think this is indeed a GnuTLS bug in the handling of rehandshakes. Attached: 1) gnutls-cli log output from testing using httpd/mod_ssl 2) patch to tests/x509self.c which attempts to replicate this test case 3) stdout and stderr output from running (2) |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_AES_ Joe Orton 2008-11-28T14:47:22 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3302 Hello, This is not an answer to your TLS problem, but I'd like to highlight that in Diameter if the TLS handshake fails you don't have to send a DPR. Here is an extract from draft-ietf-dime-rfc3588bis-14 section 5.6: " If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state." I believe this provides you a workaround for your problem, since if the connection is simply closed, your client will exit the handshake routine. Best regards, Sebastien. Metzler, Richard a écrit : Sebastien Decugis 2008-11-28T01:23:55 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3301 _______________________________________________ Gnutls-devel mailing list Gnutls-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gnutls-devel Metzler, Richard 2008-11-27T08:21:25 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3300 I don't know. Maybe ask on the libgcrypt list? Btw, one idea is to make sure that your call above is invoked before libgcrypt is initialized. Maybe your gcry_control call is too late. /Simon Simon Josefsson 2008-11-26T11:55:33 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3299 Hi, Looking more closely at it, I noticed /* The order matters. */ I've fixed the order, we'll see what happens next :-) Thanks, Colin Leroy 2008-11-26T11:55:08 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3298 Looks like a libgcrypt and thread related crash to me. Is your application multi-threaded? Maybe this helps: http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applicati ons.html /Simon Simon Josefsson 2008-11-26T11:46:56 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3297 Hi, Btw, in my application I do have the threads setup with: gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); But this application also uses a Glib main loop. Should I use gcry_threads_other instead? Thanks, Colin Leroy 2008-11-26T11:33:47 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3296 Hi, Does such a backtrace ring a bell for someone? #0 0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6 #1 0x00007f9a9a0e9b43 in abort () from /lib/libc.so.6 #2 0x00007f9a9a0e0d49 in __assert_fail () from /lib/libc.so.6 #3 0x00007f9a9afd191b in _gcry_ath_mutex_lock (lock=0x7f9a9b22ad30) at ath.c:186 #4 0x00007f9a9afdf660 in lock_pool () at random.c:299 #5 0x00007f9a9afe003e in _gcry_fast_random_poll () at random.c:1304 #6 0x00007f9a9afd3686 in _gcry_cipher_open (handle=0x3ecc, algo=16247, mode=6, flags=4294967295) at cipher.c:641 #7 0x00007f9a9b6a3ce9 in gc_cipher_open (alg=<value optimized out>, mode=<value optimized out>, outhandle=0x3) at gc-libgcrypt.c:180 #8 0x00007f9a9b682b78 in _gnutls_cipher_init (handle=0x26c1ac8, cipher=<value optimized out>, key=0x26c1a88, iv=0x26c1a68) at gnutls_cipher_int.c:64 #9 0x00007f9a9b68d829 in _gnutls_read_connection_state_init (session=0x26c16e0) at gnutls_constate.c:621 #10 0x0 Colin Leroy 2008-11-26T11:23:01 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3295 Thanks, should be fixed by: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=490aa118b953284c19f908c5fb8f7b19a37989f3 /Simon Simon Josefsson 2008-11-23T15:52:21 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3294 The git version of gnutls-cli (both in main and 2.6 branches) support this behavior. regards, Nikos Nikos Mavrogiannopoulos 2008-11-23T08:02:10 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3293 _______________________________________________ Gnutls-devel mailing list Gnutls-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gnutls-devel Arfrever Frehtes Taifersar Arahesis 2008-11-22T23:18:43 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3292 Interesting, thanks for trying that out. I'm not sure what else neon could do to make this work correctly so I think further diagnosis based on packet traces will be needed. I can try to work on that sometime in the coming week, with luck. It might be useful to modify gnutls-cli to call gnutls_rehandshake() in the same fashion as my patch to neon, to get some debugging traces from GnuTLS, if you wanted to try that. Regards, Joe Joe Orton 2008-11-22T22:13:00 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3291 _______________________________________________ Gnutls-devel mailing list Gnutls-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gnutls-devel Daniel Kahn Gillmor 2008-11-22T18:54:43 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3290 I guess that's a problem with the Debian package build process? Err, reading that patch again, it's complete rubbish. Could you try the one below which is hopefully less rubbish? Thanks a lot for working on this! Index: src/ne_socket.c =================================================================== --- src/ne_socket.c(revision 1607) +++ src/ne_socket.c(working copy) < at >< at > -750,13 +750,18 < at >< at > static ssize_t read_gnutls(ne_socket *sock, char *buffer, size_t len) { ssize_t ret; + unsigned reneg = 1; /* number of allowed rehandshakes */ ret = readable_gnutls(sock, sock->rdtimeout); if (ret) return ret; do { - ret = gnutls_record_recv(sock->ssl, buffer, len); - } while (RETRY_GNUTLS(sock, ret)); + do { + ret = gnutls_record_recv(sock->ssl, buffer, len); + } while (RETRY_GNUTLS(sock, ret)); + + } while (ret == GNUTLS_E_REHANDSHAKE && reneg-- + && (ret = gnutls_handshake(sock->ssl)) == GNUTLS_E_SUCCESS); if ( Joe Orton 2008-11-22T08:05:03 http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3289 _______________________________________________ Gnutls-devel mailing list Gnutls-devel< at >gnu.org http://lists.gnu.org/mailman/listinfo/gnutls-devel Daniel Kahn Gillmor 2008-11-22T05:51:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.encryption.gpg.gnutls.devel