From daniel at haxx.se Fri Apr 8 00:02:06 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 8 Apr 2005 00:02:06 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle Message-ID: Hi I've made an obervation that looks like a bug to me: I have a test case that sets a ca cert bundle like this: /* set the trusted CA cert bundle file */ rc = gnutls_certificate_set_x509_trust_file(cred, cafile, GNUTLS_X509_FMT_PEM); The cafile points to a file name of a file that doesn't exist. This then returns -64 properly indicating a file error. If I then proceed (ignoring the error) and later make a gnutls_handshake(), it will never succeed. It seems to only return GNUTLS_E_AGAIN for a very long time. (I'm using non-blocking sockets). It doesn't seem like the right behaviour. I think it would either return an error more or less right away, or it would do the handshake properly... Or am I just not understanding things? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Fri Apr 8 02:09:28 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 8 Apr 2005 02:09:28 +0200 Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: References: Message-ID: <200504080209.29132.nmav@gnutls.org> On Friday 08 April 2005 00:02, Daniel Stenberg wrote: > Hi > > I've made an obervation that looks like a bug to me: > > I have a test case that sets a ca cert bundle like this: > > /* set the trusted CA cert bundle file */ > rc = gnutls_certificate_set_x509_trust_file(cred, > cafile, > GNUTLS_X509_FMT_PEM); > > The cafile points to a file name of a file that doesn't exist. > This then returns -64 properly indicating a file error. > If I then proceed (ignoring the error) and later make a gnutls_handshake(), > it will never succeed. It seems to only return GNUTLS_E_AGAIN for a very > long time. (I'm using non-blocking sockets). This looks strange.. Could you use something like: static void tls_log_func(int level, const char *str) { fprintf(stderr, "|<%d>| %s", level, str); } and after global_init() gnutls_global_set_log_function(tls_log_func); gnutls_global_set_log_level(2); and send the output? -- Nikos Mavrogiannopoulos From daniel at haxx.se Fri Apr 8 10:26:34 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 8 Apr 2005 10:26:34 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: <200504080209.29132.nmav@gnutls.org> References: <200504080209.29132.nmav@gnutls.org> Message-ID: On Fri, 8 Apr 2005, Nikos Mavrogiannopoulos wrote: > This looks strange.. Could you use something like: ... > and send the output? Certainly. I should also add that this is GnuTLS 1.2.0 on Linux 2.6. When setting the CA file it reports: |<2>| ASSERT: gnutls_x509.c:742 |<2>| ASSERT: gnutls_x509.c:1381 And then when I proceed anyway, it continues: |<2>| ASSERT: gnutls_buffers.c:255 |<2>| ASSERT: gnutls_buffers.c:974 |<2>| ASSERT: gnutls_handshake.c:883 |<2>| ASSERT: gnutls_buffers.c:255 |<2>| ASSERT: gnutls_buffers.c:974 |<2>| ASSERT: gnutls_handshake.c:883 |<2>| ASSERT: gnutls_buffers.c:255 |<2>| ASSERT: gnutls_buffers.c:974 ... These last three lines are then repeated in what seems like forever. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Fri Apr 8 16:40:52 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 8 Apr 2005 16:40:52 +0200 Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: References: <200504080209.29132.nmav@gnutls.org> Message-ID: <200504081640.53245.nmav@gnutls.org> On Friday 08 April 2005 10:26, Daniel Stenberg wrote: > > and send the output? > Certainly. I should also add that this is GnuTLS 1.2.0 on Linux 2.6. > When setting the CA file it reports: > |<2>| ASSERT: gnutls_x509.c:742 > |<2>| ASSERT: gnutls_x509.c:1381 > > And then when I proceed anyway, it continues: > |<2>| ASSERT: gnutls_buffers.c:255 > |<2>| ASSERT: gnutls_buffers.c:974 > |<2>| ASSERT: gnutls_handshake.c:883 > |<2>| ASSERT: gnutls_buffers.c:255 > |<2>| ASSERT: gnutls_buffers.c:974 > |<2>| ASSERT: gnutls_handshake.c:883 > |<2>| ASSERT: gnutls_buffers.c:255 > |<2>| ASSERT: gnutls_buffers.c:974 > ... These last three lines are then repeated in what seems like forever. It seems that the recv() function returns -1 with errno EAGAIN or EINTERRUPTED. Are you sure that the only difference is that the set_trust_file() function failed? I tried to reproduce it with gnutls-serv and I couldn't. -- Nikos Mavrogiannopoulos From daniel at haxx.se Fri Apr 8 19:05:25 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 8 Apr 2005 19:05:25 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: <200504081640.53245.nmav@gnutls.org> References: <200504080209.29132.nmav@gnutls.org> <200504081640.53245.nmav@gnutls.org> Message-ID: On Fri, 8 Apr 2005, Nikos Mavrogiannopoulos wrote: > Are you sure that the only difference is that the set_trust_file() function > failed? I tried to reproduce it with gnutls-serv and I couldn't. I am quite sure. All other test cases run fine, and only the one that points out a missing file fails. Here's the full code: http://cool.haxx.se/cvs.cgi/curl/lib/gtls.c?annotate=1.2 At line 155, if I remove the return when the error occurs, the handshake loop at line 200 - 248 never ends. Perhaps I've done something else wrong that makes this happen? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Sat Apr 9 19:43:31 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 9 Apr 2005 19:43:31 +0200 Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: References: <200504081640.53245.nmav@gnutls.org> Message-ID: <200504091943.32049.nmav@gnutls.org> On Friday 08 April 2005 19:05, Daniel Stenberg wrote: > On Fri, 8 Apr 2005, Nikos Mavrogiannopoulos wrote: > > Are you sure that the only difference is that the set_trust_file() > > function failed? I tried to reproduce it with gnutls-serv and I couldn't. > > I am quite sure. All other test cases run fine, and only the one that > points out a missing file fails. > Here's the full code: > http://cool.haxx.se/cvs.cgi/curl/lib/gtls.c?annotate=1.2 > At line 155, if I remove the return when the error occurs, the handshake > loop at line 200 - 248 never ends. Could you send me a small program that can reproduce this problem? -- Nikos Mavrogiannopoulos From daniel at haxx.se Sat Apr 9 23:36:48 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Sat, 9 Apr 2005 23:36:48 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: <200504091943.32049.nmav@gnutls.org> References: <200504081640.53245.nmav@gnutls.org> <200504091943.32049.nmav@gnutls.org> Message-ID: On Sat, 9 Apr 2005, Nikos Mavrogiannopoulos wrote: > Could you send me a small program that can reproduce this problem? A fair request indeed. I wrote up a little app that should be doing the same sequence as my larger one. But I fail to repeat it (surprise suprise). Then, I went back to my original test case that failed and... now that works too. I'm terribly sorry for having wasted your time on some weird thing I seem to have just dreamt or at least now have researched properly myself. Thanks a lot for your swift and helpful responses anyway! -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Sat Apr 9 23:55:57 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Sat, 9 Apr 2005 23:55:57 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: References: <200504081640.53245.nmav@gnutls.org> <200504091943.32049.nmav@gnutls.org> Message-ID: On Sat, 9 Apr 2005, Daniel Stenberg wrote: > Then, I went back to my original test case that failed and... now that works > too. Couldn't even do that right. No, it still loops in what seems forever. But no, I can't make a stand-alone app that repeats it. The stand-alone reports totally different line numbers and then succeeds with the handshake. Any advice on how I persue this? Do those assert lines tell you anything at all? I'm prepared to slap on a -g on the build and re-install debug built libs and dig into this with a debugger, but some guidance could help me get a jumpstart. (My failing code is part of the current curl CVS repository in case anyone would want to try the actual failing code.) -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Sun Apr 10 00:15:48 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Sun, 10 Apr 2005 00:15:48 +0200 (CEST) Subject: [Help-gnutls] non-existing CA bundle In-Reply-To: <200504091943.32049.nmav@gnutls.org> References: <200504081640.53245.nmav@gnutls.org> <200504091943.32049.nmav@gnutls.org> Message-ID: On Sat, 9 Apr 2005, Nikos Mavrogiannopoulos wrote: > Could you send me a small program that can reproduce this problem? Sorry for all the noise tonight, but I truly expect this to be my last mail for a few hours! ;-) Here's how to repeat a problem that seems to be the same one I get. At least it loops in the the handshake loop "forever". (The assert line numbers are slightly different though.) Attached to this mail is a test application source code. I built it on Linux and linked with GnuTLS 1.2.0. In my earlier post, I tried the app against the sourceforge HTTPS server and it worked fine. Now I tried it against my test server (for the curl test suite) and I get the problem. The test server in question is simply stunnel running with my dumb HTTP test server behind it. The 'httpssserver.pl' I use is a script that just starts stunnel with the proper options. See here: http://cool.haxx.se/cvs.cgi/curl/tests/httpsserver.pl?rev=HEAD&content-type=text/vnd.viewcvs-markup I figure you could get away with using _anything_ to stunnel to in order to get this test setup working since the handshake never completes and thus stunnel never passes anything through to the other program. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol -------------- next part -------------- #include #include #include #include #include #include #include #include #include #include void nonblock(int sockfd) { /* most recent unix versions */ int flags; flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); } #define MAX_BUF 1024 #define SA struct sockaddr #define MSG "GET / HTTP/1.0\r\n\r\n" /* Connects to the peer and returns a socket * descriptor. */ int tcp_connect(void) { #if 0 const char *PORT = "443"; const char *SERVER = "66.35.250.203"; /* www.sourceforge.net */ #else const char *PORT = "8999"; const char *SERVER = "127.0.0.1"; #endif int err, sd; struct sockaddr_in sa; /* connects to server */ sd = socket(AF_INET, SOCK_STREAM, 0); memset(&sa, '\0', sizeof(sa)); sa.sin_family = AF_INET; sa.sin_port = htons(atoi(PORT)); inet_pton(AF_INET, SERVER, &sa.sin_addr); err = connect(sd, (SA *) & sa, sizeof(sa)); if (err < 0) { fprintf(stderr, "Connect error\n"); exit(1); } nonblock(sd); return sd; } static void tls_log_func(int level, const char *str) { fprintf(stderr, "|<%d>| %s", level, str); } /* closes the given socket descriptor. */ void tcp_close(int sd) { shutdown(sd, SHUT_RDWR); /* no more receptions */ close(sd); } int main() { int ret, sd, ii; gnutls_session session; gnutls_anon_client_credentials cred; char buffer[MAX_BUF + 1]; char *cafile="doesntexist"; const int cert_type_priority[3] = { GNUTLS_CRT_X509, 0 }; int rc; /* connect to the peer */ sd = tcp_connect(); fprintf(stderr, "gnutls: %s\n", gnutls_check_version(NULL)); gnutls_global_init(); gnutls_global_set_log_function(tls_log_func); gnutls_global_set_log_level(2); rc = gnutls_certificate_allocate_credentials(&cred); fprintf(stderr, "==> Before SET CA\n"); rc = gnutls_certificate_set_x509_trust_file(cred, cafile, GNUTLS_X509_FMT_PEM); fprintf(stderr, "==> After SET CA\n"); /* Initialize TLS session */ gnutls_init(&session, GNUTLS_CLIENT); /* Use default priorities */ gnutls_set_default_priority(session); rc = gnutls_certificate_type_set_priority(session, cert_type_priority); rc = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cred); gnutls_transport_set_ptr(session, (gnutls_transport_ptr) sd); fprintf(stderr, "==> Before Handshake\n"); /* Perform the TLS handshake */ while(1) { fd_set fds_read; fd_set fds_write; struct timeval timeout={1,0}; ret = gnutls_handshake(session); if((ret != GNUTLS_E_AGAIN) && (ret != GNUTLS_E_INTERRUPTED)) break; FD_ZERO(&fds_read); FD_ZERO(&fds_write); FD_SET(sd, &fds_read); FD_SET(sd, &fds_write); select(sd+1, &fds_read, &fds_write, NULL, &timeout); } if (ret < 0) { fprintf(stderr, "*** Handshake failed\n"); gnutls_perror(ret); } else { printf("- Handshake was completed\n"); } tcp_close(sd); gnutls_deinit(session); gnutls_global_deinit(); return 0; } From regit at inl.fr Mon Apr 11 11:11:16 2005 From: regit at inl.fr (Eric Leblond) Date: Mon, 11 Apr 2005 11:11:16 +0200 Subject: [Help-gnutls] segfault in internal function Message-ID: <425A3F34.1050803@inl.fr> Hi, I'm using gnutls 1.0.16 in an application. Under certain circonstances (lot of opening and closing of session) the application crashes. Under gdb I've got the following message [Switching to Thread 1476393328 (LWP 21249)] 0x00002aaaab32aff4 in _gnutls_ciphertext2compressed () from /usr/lib/libgnutls.so.11 Is this a know problem or does it come from gnutls or from elsewhere ? Any tips welcome BR, -- Eric Leblond From nmav at gnutls.org Tue Apr 12 18:21:33 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 12 Apr 2005 18:21:33 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <425A3F34.1050803@inl.fr> References: <425A3F34.1050803@inl.fr> Message-ID: <200504121821.34179.nmav@gnutls.org> On Monday 11 April 2005 11:11, Eric Leblond wrote: > Hi, > I'm using gnutls 1.0.16 in an application. Under certain circonstances > (lot of opening and closing of session) > the application crashes. > Under gdb I've got the following message > [Switching to Thread 1476393328 (LWP 21249)] > 0x00002aaaab32aff4 in _gnutls_ciphertext2compressed () from > /usr/lib/libgnutls.so.11 > Is this a know problem or does it come from gnutls or from elsewhere ? Hello Eric, It's quite unlikely that this comes from gnutls. If you use threads in your program, did you register the locking callbacks for libgcrypt? -- Nikos Mavrogiannopoulos From regit at inl.fr Wed Apr 13 11:17:45 2005 From: regit at inl.fr (Eric Leblond) Date: Wed, 13 Apr 2005 11:17:45 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <200504121821.34179.nmav@gnutls.org> References: <425A3F34.1050803@inl.fr> <200504121821.34179.nmav@gnutls.org> Message-ID: <1113383865.8102.2.camel@localhost.localdomain> Le mardi 12 avril 2005 ? 18:21 +0200, Nikos Mavrogiannopoulos a ?crit : > On Monday 11 April 2005 11:11, Eric Leblond wrote: > Hello Eric, > It's quite unlikely that this comes from gnutls. If you use threads in your > program, did you register the locking callbacks for libgcrypt? Thanks for your answer, I omit to declare it in a thread using it (was done in other thread). I hope it comes from this. I previously found that this seems occur during gnutls handshake. Sadly, I launch a test with a global declaration of gcrypt lock callback but it fails too. So I've got two questions relative to callback : * callback need to be declare everywhere or just before gnutls_global_init ? * I use glib in the program. It hides pthread functions behind his own function. Is it sufficient to declare : GCRY_THREAD_OPTION_PTHREAD_IMPL; ? BR, PS : for your information, I use gnutls for NuFW (http://www.nufw.org) an authenticating firewall. -- Eric Leblond INL From daniel at haxx.se Wed Apr 13 11:06:12 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Wed, 13 Apr 2005 11:06:12 +0200 (CEST) Subject: [Help-gnutls] gnutls multi-threaded Message-ID: Hi (CC'ed to the libcurl mailing list for info) Reading another thread in the gnutls list, it came to my attention that using GnuTLS in a multi-threaded environment requires some locking functions to be set for the underlying crypto lib (libgcrypt). Is there a descriptive web page anywhere that explains this that I can point libcurl users to? Many libcurl users run multi-threaded programs and this is bound to hit the fan as soon as people start trying the GnuTLS-version of libcurl more. (Which I expect will happen once we release a version with this ability included.) I'm considering providing this locking/mutex ability in an API to libcurl, so that libcurl-using apps can be agnostic to which secure layer libcurl has been built to use. But I don't know yet if that is feasable. Is there a good reason why GnuTLS doesn't export such methods by itself? I mean, isn't it rather ugly to force lib-users to have to assume that GnuTLS uses libgcrypt? Or have I misunderstood things? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From regit at inl.fr Wed Apr 13 11:23:57 2005 From: regit at inl.fr (Eric Leblond) Date: Wed, 13 Apr 2005 11:23:57 +0200 Subject: [Help-gnutls] gnutls multi-threaded In-Reply-To: References: Message-ID: <425CE52D.1020604@inl.fr> Hi dear friend in multithreaded gnutls, Daniel Stenberg wrote: > Hi > > (CC'ed to the libcurl mailing list for info) > > Reading another thread in the gnutls list, it came to my attention > that using GnuTLS in a multi-threaded environment requires some > locking functions to be set for the underlying crypto lib (libgcrypt). The gnutls manual contains a brief description of how to set up the lock : http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications BR, -- Eric Leblond From jas at extundo.com Wed Apr 13 16:35:08 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 13 Apr 2005 16:35:08 +0200 Subject: [Help-gnutls] Re: gnutls multi-threaded In-Reply-To: (Daniel Stenberg's message of "Wed, 13 Apr 2005 11:06:12 +0200 (CEST)") References: Message-ID: Daniel Stenberg writes: > Reading another thread in the gnutls list, it came to my attention that using > GnuTLS in a multi-threaded environment requires some locking functions to be > set for the underlying crypto lib (libgcrypt). Hi! Yes, this is sadly the situation right now. I don't particularly fancy libgcrypt's design choice when it comes to threading. That has been one of the reasons to work on modularizing the crypto stuff in GnuTLS. Alas, I haven't had time to finish it yet. The goal is to be able to replace libgcrypt with something else, and also include a minimalistic and portable crypto library (e.g., Nettle). Then GnuTLS will be able to build as a standalone package, which is better for testing. I have started on a backend agnostic crypto API, called "Generic Crypto", it is in gnutls/crypto/ right now. This is (or will be) used by GnuTLS, Shishi, GNU SASL, and possible other projects, and support libgcrypt and Nettle as crypto-backends. It does hashing, randomness, and symmetric ciphers now. Adding multiple-precision computations, public-key operations, s-exp and possibly more is an area which could use some help. Any comments on the interfaces are appreciated. > Is there a descriptive web page anywhere that explains this that I can point > libcurl users to? Eric Leblond answered this, I think. > Many libcurl users run multi-threaded programs and this is > bound to hit the fan as soon as people start trying the GnuTLS-version of > libcurl more. Right. > I'm considering providing this locking/mutex ability in an API to libcurl, so > that libcurl-using apps can be agnostic to which secure layer libcurl has been > built to use. But I don't know yet if that is feasable. > > Is there a good reason why GnuTLS doesn't export such methods by itself? I > mean, isn't it rather ugly to force lib-users to have to assume that GnuTLS > uses libgcrypt? > > Or have I misunderstood things? No, and I agree with you, it is not elegant now. One problem with adding these methods is that it suggest to people that they should always use them, and that it is a good thing to use them, which I think sends the wrong signals. But as you say, it may be even more inelegant to force GnuTLS users to use libgcrypt directly. I think these locking/mutex hooks should be added to the GnuTLS API. Patches welcome.. Regards, Simon From daniel at haxx.se Wed Apr 13 23:18:10 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Wed, 13 Apr 2005 23:18:10 +0200 (CEST) Subject: [Help-gnutls] no 1.2.1 mentioned on the site! Message-ID: Hi I learned that GnuTLS 1.2.1 has been released. I find no mentioning of this at all on the gnu.org web site. Even the news page only says 1.2.0 on the top... -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Thu Apr 14 11:19:08 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 14 Apr 2005 11:19:08 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <1113383865.8102.2.camel@localhost.localdomain> References: <425A3F34.1050803@inl.fr> <200504121821.34179.nmav@gnutls.org> <1113383865.8102.2.camel@localhost.localdomain> Message-ID: <200504141119.09044.nmav@gnutls.org> On Wednesday 13 April 2005 11:17, Eric Leblond wrote: Hello Eric, > * callback need to be declare everywhere or just before > gnutls_global_init ? Yes, only before this function. > * I use glib in the program. It hides pthread functions behind his own > function. Is it sufficient to declare : > GCRY_THREAD_OPTION_PTHREAD_IMPL; I'm not really sure that this is sufficient. It depends on the internals of glib, that I don't know. So you need to make your own locking callbacks and register them as shown in the documentation. -- Nikos Mavrogiannopoulos From jas at extundo.com Thu Apr 14 13:04:42 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 14 Apr 2005 13:04:42 +0200 Subject: [Help-gnutls] Re: no 1.2.1 mentioned on the site! In-Reply-To: (Daniel Stenberg's message of "Wed, 13 Apr 2005 23:18:10 +0200 (CEST)") References: Message-ID: Daniel Stenberg writes: > Hi > > I learned that GnuTLS 1.2.1 has been released. I find no mentioning of this at > all on the gnu.org web site. Even the news page only says 1.2.0 on the top... Hi! Thanks for noticing. It appears as if the 1.2.1 announcement didn't make it to the gnutls-dev list, where it is usually announced. The post is available via gmane.org, where I read this list, but I suppose that's because of their cross-posting automagic. (It was posted to info-gnu at gnu.org and to gnutls-dev.) I have re-sent the announcement, and updated the web page. I suppose I'll post release announcements to this list as well in the future. Thanks, Simon From jas at extundo.com Fri Apr 22 01:11:50 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 22 Apr 2005 01:11:50 +0200 Subject: [Help-gnutls] Please test GnuTLS 1.2.2rc! (was: Re: gnutls_free_dh_info) In-Reply-To: <4267CD72.8070206@outoforder.cc> (Paul Querna's message of "Thu, 21 Apr 2005 08:57:38 -0700") References: <42670025.5090100@outoforder.cc> <200504210903.56415.nmav@gnutls.org> <4267CD72.8070206@outoforder.cc> Message-ID: Paul Querna writes: > Yup, The patch stops the crashing. Thanks. Thank for testing! This appears to be a serious bug, so we will release 1.2.2 on Sunday. However, I have installed some major internal changes wrt how #include's are handled to CVS. (More cleanups are planned.) I have built this version on many platforms, but there could be serious issues left. Hence: Please download, build and test http://josefsson.org/daily/gnutls/gnutls-20050422.tar.gz as if it were the final 1.2.2 release. If there are non-trivial problems with it, we will make 1.2.2 be the same as 1.2.1 plus the patch to fix the crash, instead. The NEWS entries read: * Version 1.2.2 - gnutls_error_to_alert() now considers GNUTLS_E_UNEXPECTED_HANDSHAKE_PACKET. - Fixed error in session resuming that could cause a crash in a session. - Fixed pkcs12 friendly name and local key identifier decoding. - Internal cleanups, removed duplicate typedef/struct definitions, and made source code include external include file, to check function prototypes during compile time. - API and ABI modifications: No changes since last version. Thanks, Simon From chip at outoforder.cc Fri Apr 22 02:54:00 2005 From: chip at outoforder.cc (Paul Querna) Date: Thu, 21 Apr 2005 17:54:00 -0700 Subject: [Help-gnutls] Byte order in the Session Cache? Message-ID: <42684B28.40404@outoforder.cc> Hello, In mod_gnutls, I have support for a distributed session cache via memcached. This means I could have mod_gnutls running on a PPC, sharing the SSL Session cache with an x86 machine. Is the session data stored in a format that can be shared between different architectures safely? (eg Big and Little Endian) Thanks, -Paul From nmav at gnutls.org Fri Apr 22 06:52:52 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Apr 2005 06:52:52 +0200 Subject: [Help-gnutls] Byte order in the Session Cache? In-Reply-To: <42684B28.40404@outoforder.cc> References: <42684B28.40404@outoforder.cc> Message-ID: <200504220652.53101.nmav@gnutls.org> On Friday 22 April 2005 02:54, Paul Querna wrote: > Hello, > > In mod_gnutls, I have support for a distributed session cache via > memcached. This means I could have mod_gnutls running on a PPC, sharing > the SSL Session cache with an x86 machine. > Is the session data stored in a format that can be shared between > different architectures safely? (eg Big and Little Endian) Not really. That is because whole structures are copied with memcpy. This means that even the same architecture but different gnutls version may also be incompatible. It is not difficult for this to be implemented though (all the code is in gnutls_session_pack.c), but currently there is no such work planned. > Thanks, > -Paul -- Nikos Mavrogiannopoulos From chip at outoforder.cc Fri Apr 22 07:01:25 2005 From: chip at outoforder.cc (Paul Querna) Date: Thu, 21 Apr 2005 22:01:25 -0700 Subject: [Help-gnutls] Byte order in the Session Cache? In-Reply-To: <200504220652.53101.nmav@gnutls.org> References: <42684B28.40404@outoforder.cc> <200504220652.53101.nmav@gnutls.org> Message-ID: <42688525.7060104@outoforder.cc> Nikos Mavrogiannopoulos wrote: >On Friday 22 April 2005 02:54, Paul Querna wrote: > > >>Hello, >> >>In mod_gnutls, I have support for a distributed session cache via >>memcached. This means I could have mod_gnutls running on a PPC, sharing >>the SSL Session cache with an x86 machine. >>Is the session data stored in a format that can be shared between >>different architectures safely? (eg Big and Little Endian) >> >> > >Not really. That is because whole structures are copied with memcpy. >This means that even the same architecture but different gnutls >version may also be incompatible. > > > Ah. Thats too bad. >It is not difficult for this to be implemented though (all the code is in >gnutls_session_pack.c), but currently there is no such work planned. > > Cool. Maybe in the next couple weeks I will take a swing at a patch. -Paul From daniel at haxx.se Fri Apr 22 14:22:51 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 22 Apr 2005 14:22:51 +0200 (CEST) Subject: [Help-gnutls] gnutls_x509_crq_get_dn_by_oid Message-ID: Hello! Can you please clarify what gnutls_x509_crq_get_dn_by_oid() stores in the area I point out to it with the 'buf' argument? The docs says it should be "a pointer to a structure to hold the name", but doesn't mention what structure or how such a struct should look like. I currently use it like this: size=sizeof(certbuf); rc = gnutls_x509_crt_get_dn_by_oid(x509_cert, GNUTLS_OID_X520_COMMON_NAME, 0, /* the first and only one */ TRUE, /* give to me raw please */ certbuf, &size); ... but I can't make sense from what it provides. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Fri Apr 22 17:28:20 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Apr 2005 17:28:20 +0200 Subject: [Help-gnutls] gnutls_x509_crq_get_dn_by_oid In-Reply-To: References: Message-ID: <200504221728.20527.nmav@gnutls.org> On Friday 22 April 2005 14:22, Daniel Stenberg wrote: > Hello! > > Can you please clarify what gnutls_x509_crq_get_dn_by_oid() stores in the > area I point out to it with the 'buf' argument? > > The docs says it should be "a pointer to a structure to hold the name", but > doesn't mention what structure or how such a struct should look like. I changed it to: a pointer where the DN part will be copied (may be null). > I currently use it like this: > > size=sizeof(certbuf); > rc = gnutls_x509_crt_get_dn_by_oid(x509_cert, > GNUTLS_OID_X520_COMMON_NAME, 0, /* the first and only one */ TRUE, /* give > to me raw please */ certbuf, > &size); Why do you want the DER data and not a printable string? A common use would be: string[128]; size_t size=sizeof(string); rc = gnutls_x509_crt_get_dn_by_oid(x509_cert, GNUTLS_OID_X520_COMMON_NAME, 0, 0, string, &size); -- Nikos Mavrogiannopoulos From daniel at haxx.se Fri Apr 22 22:55:37 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 22 Apr 2005 22:55:37 +0200 (CEST) Subject: [Help-gnutls] gnutls_x509_crq_get_dn_by_oid In-Reply-To: <200504221728.20527.nmav@gnutls.org> References: <200504221728.20527.nmav@gnutls.org> Message-ID: On Fri, 22 Apr 2005, Nikos Mavrogiannopoulos wrote: >> rc = gnutls_x509_crt_get_dn_by_oid(x509_cert, >> GNUTLS_OID_X520_COMMON_NAME, 0, /* the first and only one */ TRUE, /* give >> to me raw please */ certbuf, >> &size); > Why do you want the DER data and not a printable string? I don't. I thought I asked for a printable one. Did I mention that I found the documentation for the function cryptic? ;-) Thanks! -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From chip at outoforder.cc Mon Apr 25 09:30:55 2005 From: chip at outoforder.cc (Paul Querna) Date: Mon, 25 Apr 2005 00:30:55 -0700 Subject: [Help-gnutls] Re: Please test GnuTLS 1.2.2rc! In-Reply-To: References: <42670025.5090100@outoforder.cc> <200504210903.56415.nmav@gnutls.org> <4267CD72.8070206@outoforder.cc> Message-ID: <426C9CAF.3080505@outoforder.cc> Simon Josefsson wrote: >Paul Querna writes: > > > >>Yup, The patch stops the crashing. Thanks. >> >> > >Thank for testing! > >This appears to be a serious bug, so we will release 1.2.2 on Sunday. > >However, I have installed some major internal changes wrt how >#include's are handled to CVS. (More cleanups are planned.) I have >built this version on many platforms, but there could be serious >issues left. Hence: > >Please download, build and test > >http://josefsson.org/daily/gnutls/gnutls-20050422.tar.gz > >as if it were the final 1.2.2 release. > >If there are non-trivial problems with it, we will make 1.2.2 be the >same as 1.2.1 plus the patch to fix the crash, instead. > >The NEWS entries read: > >* Version 1.2.2 >- gnutls_error_to_alert() now considers > GNUTLS_E_UNEXPECTED_HANDSHAKE_PACKET. >- Fixed error in session resuming that could cause a crash in a session. >- Fixed pkcs12 friendly name and local key identifier decoding. >- Internal cleanups, removed duplicate typedef/struct definitions, > and made source code include external include file, to check > function prototypes during compile time. >- API and ABI modifications: > No changes since last version. > > FYI, this nightly has been working great for me. Running on FreeBSD and Linux. -Paul From jas at extundo.com Mon Apr 25 12:19:33 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 25 Apr 2005 12:19:33 +0200 Subject: [Help-gnutls] GnuTLS 1.2.2 Message-ID: We are pleased to announce the availability of GnuTLS 1.2.2! This is a bugfix release on the 1.2.x branch. Among other things, this release fixes a serious double memory de-allocation problem. Also included are my initial work on cleaning up the #include file situation. The source code files now include the public header file for most data types, instead of duplicating possibly stale prototypes. Note that this has not been tested extensively, although I have had some positive reports. Your feedback is needed for deciding whether to possibly back this change out. Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a privately owned company located in Stockholm, is currently funding GnuTLS maintenance, and is always looking for interesting development projects. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.2.tar.bz2 (2.4MB) http://josefsson.org/gnutls/releases/gnutls-1.2.2.tar.bz2 (2.4MB) Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.2.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.2.2.tar.bz2.sig Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the MD5/SHA1 checksums: 2f7e1343fa1565a1cf5ebb2a02d63abc8f036b2a gnutls-1.2.2.tar.bz2 633a89a8a751d35a49dffe8007203b06b1ebe65b gnutls-1.2.2.tar.bz2.sig 63e618657561a1a185b31ea8f4da895b gnutls-1.2.2.tar.bz2 c7e82a42c43a878d68f920dfc7a66980 gnutls-1.2.2.tar.bz2.sig Noteworthy changes since version 1.2.1: - gnutls_error_to_alert() now considers GNUTLS_E_UNEXPECTED_HANDSHAKE_PACKET. - Fixed error in session resuming that could cause a crash in a session. - Fixed pkcs12 friendly name and local key identifier decoding. - Internal cleanups, removed duplicate typedef/struct definitions, and made source code include external include file, to check function prototypes during compile time. - API and ABI modifications: No changes since last version. At least not intentional, but due to the include header changes, there may be inadvertant changes, please let us know if you find any. Enjoy, Nikos and Simon From asuffield at suffields.me.uk Mon Apr 25 20:24:49 2005 From: asuffield at suffields.me.uk (Andrew Suffield) Date: Mon, 25 Apr 2005 19:24:49 +0100 Subject: [Help-gnutls] certtool and win2k Message-ID: <20050425182449.GA7181@suffields.me.uk> Has anybody managed to get certtool/gnutls-generated keys to work with win2k? I started out with a weird problem, and eventually tracked it down to something that makes no sense to me at all: An RSA private key generated with certtool cannot be handled by win2k. And yes, I do mean *private key*, not certificate. This doesn't work: certtool -p --outfile key.pem certtool -s --load-privkey key.pem --outfile cert.pem certtool --load-privkey key.pem --load-certificate cert.pem --to-p12 --outder --outfile cert.p12 This does: openssl genrsa -out key.pem 1024 certtool -s --load-privkey key.pem --outfile cert.pem certtool --load-privkey key.pem --load-certificate cert.pem --to-p12 --outder --outfile cert.p12 Trying to import a key generated with certtool gives an error about the algorithm not being supported; if the key is generated by openssl, it works just fine. I can't see any appreciable difference in the keys generated, and they all work fine with both openssl and gnutls. I haven't tried it with winxp; it behaves the same way on several win2k boxes, so if the problem is on that end, there's a need for a compatibility feature. So, um, WTF? [Note that win2k does not handle RSA keys at all until the high encryption pack is installed] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Mon Apr 25 21:29:04 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 25 Apr 2005 21:29:04 +0200 Subject: [Help-gnutls] certtool and win2k In-Reply-To: <20050425182449.GA7181@suffields.me.uk> References: <20050425182449.GA7181@suffields.me.uk> Message-ID: <200504252129.04759.nmav@gnutls.org> On Monday 25 April 2005 20:24, Andrew Suffield wrote: > Has anybody managed to get certtool/gnutls-generated keys to work with > win2k? I started out with a weird problem, and eventually tracked it > down to something that makes no sense to me at all: Hello Andrew, can win2k import the attached key? -- Nikos Mavrogiannopoulos -------------- next part -------------- A non-text attachment was scrubbed... Name: key.pem Type: application/x-x509-ca-cert Size: 887 bytes Desc: not available URL: From asuffield at suffields.me.uk Tue Apr 26 02:05:13 2005 From: asuffield at suffields.me.uk (Andrew Suffield) Date: Tue, 26 Apr 2005 01:05:13 +0100 Subject: [Help-gnutls] certtool and win2k In-Reply-To: <200504252129.04759.nmav@gnutls.org> References: <20050425182449.GA7181@suffields.me.uk> <200504252129.04759.nmav@gnutls.org> Message-ID: <20050426000513.GA4784@suffields.me.uk> On Mon, Apr 25, 2005 at 09:29:04PM +0200, Nikos Mavrogiannopoulos wrote: > On Monday 25 April 2005 20:24, Andrew Suffield wrote: > > Has anybody managed to get certtool/gnutls-generated keys to work with > > win2k? I started out with a weird problem, and eventually tracked it > > down to something that makes no sense to me at all: > Hello Andrew, > can win2k import the attached key? Nope. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Wed Apr 27 10:47:19 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Apr 2005 10:47:19 +0200 Subject: [Help-gnutls] certtool and win2k In-Reply-To: <20050426000513.GA4784@suffields.me.uk> References: <20050425182449.GA7181@suffields.me.uk> <200504252129.04759.nmav@gnutls.org> <20050426000513.GA4784@suffields.me.uk> Message-ID: <200504271047.19722.nmav@gnutls.org> On Tuesday 26 April 2005 02:05, Andrew Suffield wrote: > > > Has anybody managed to get certtool/gnutls-generated keys to work with > > > win2k? I started out with a weird problem, and eventually tracked it > > > down to something that makes no sense to me at all: Yes, it seems that the keys generated by gnutls set the coefficient, wrong. gnutls regenerate this parameter each time, that's why it wasn't noticed before. I'll try to have a fix in this week. -- Nikos Mavrogiannopoulos From regit at inl.fr Wed Apr 27 15:29:28 2005 From: regit at inl.fr (Regit) Date: Wed, 27 Apr 2005 15:29:28 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <200504141119.09044.nmav@gnutls.org> References: <425A3F34.1050803@inl.fr> <200504121821.34179.nmav@gnutls.org> <1113383865.8102.2.camel@localhost.localdomain> <200504141119.09044.nmav@gnutls.org> Message-ID: <1114608568.4613.45.camel@localhost.localdomain> Hi, I'm writing back on this thread because my investigations bring me to a point where I found the point where the crash occurs (using gnutls-1.0.24). In a gdb session I've got : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1384118640 (LWP 22734)] 0x00002aaaab1f8bf8 in _gnutls_ciphertext2compressed (session=0x5efea0, compress_data=0x60f210 "\001", compress_size=16384, ciphertext= {data = 0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", size = 48}, type=22 '\026') at gnutls_cipher.c:453 453 if (ciphertext.data[ciphertext.size-i] != ciphertext.data[ciphertext.size - 1]) backtrace gives me : #0 0x00002aaaab1f8bf8 in _gnutls_ciphertext2compressed (session=0x5efea0, compress_data=0x60f210 "\001", compress_size=16384, ciphertext= {data = 0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", size = 48}, type=22 '\026') at gnutls_cipher.c:453 #1 0x00002aaaab1f8330 in _gnutls_decrypt (session=0x5efea0, ciphertext=0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", ciphertext_size=48, data=0x60f210 "\001", data_size=16384, type=GNUTLS_HANDSHAKE) at gnutls_cipher.c:124 #2 0x00002aaaab1f769e in _gnutls_recv_int (session=0x5efea0, type=GNUTLS_HANDSHAKE, htype=GNUTLS_FINISHED, data=0x5f0890 "\017", sizeofdata=1) at gnutls_record.c:759 #3 0x00002aaaab1faf26 in _gnutls_handshake_io_recv_int (session=0x5efea0, type=GNUTLS_HANDSHAKE, htype=GNUTLS_FINISHED, iptr=0x5f0890, sizeOfPtr=1) at gnutls_buffers.c:866 #4 0x00002aaaab1fcec9 in _gnutls_recv_handshake_header (session=0x5efea0, type=GNUTLS_FINISHED, recv_type=0x527ff63c) at gnutls_handshake.c:845 #5 0x00002aaaab1fd3d8 in _gnutls_recv_handshake (session=0x5efea0, data=0x527ff698, datalen=0x527ff68c, type=GNUTLS_FINISHED, optional=MANDATORY_PACKET) at gnutls_handshake.c:995 #6 0x00002aaaab1fc264 in _gnutls_recv_finished (session=0x5efea0) at gnutls_handshake.c:460 #7 0x00002aaaab1fff9d in _gnutls_recv_handshake_final (session=0x5efea0, init=1) at gnutls_handshake.c:2165 #8 0x00002aaaab200900 in _gnutls_handshake_common (session=0x5efea0) at gnutls_handshake.c:2293 #9 0x00002aaaab1ff2e8 in gnutls_handshake (session=0x5efea0) at gnutls_handshake.c:1920 #10 0x000000000040b287 in tls_connect (c=39, session_ptr=0x527ff798) at tls.c:916 #11 0x000000000040b46b in tls_sasl_connect (userdata=0x5dc500, data=0x5f25f5) at tls.c:984 #12 0x00002aaaaaf08676 in g_static_rw_lock_free () from /usr/lib/libglib-2.0.so.0 #13 0x00002aaaaaf07442 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 #14 0x00002aaaab481b55 in start_thread () from /lib/libpthread.so.0 #15 0x00002aaaab662630 in clone () from /lib/libc.so.6 Could someone point me to what's going on ? I try as said in previous mail to declare thread but it does not change anything (But it still use this declaration). Any tips really welcome ! BR, Le jeudi 14 avril 2005 ? 11:19 +0200, Nikos Mavrogiannopoulos a ?crit : > On Wednesday 13 April 2005 11:17, Eric Leblond wrote: > > Hello Eric, > > > * callback need to be declare everywhere or just before > > gnutls_global_init ? > Yes, only before this function. > > > * I use glib in the program. It hides pthread functions behind his own > > function. Is it sufficient to declare : > > GCRY_THREAD_OPTION_PTHREAD_IMPL; > I'm not really sure that this is sufficient. It depends on the internals > of glib, that I don't know. So you need to make your own locking callbacks and > register them as shown in the documentation. -- ?ric Leblond, eleblond at inl.fr T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr From regit at inl.fr Wed Apr 27 17:46:32 2005 From: regit at inl.fr (Regit) Date: Wed, 27 Apr 2005 17:46:32 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <1114612343.4613.61.camel@localhost.localdomain> References: <425A3F34.1050803@inl.fr> <200504121821.34179.nmav@gnutls.org> <1113383865.8102.2.camel@localhost.localdomain> <200504141119.09044.nmav@gnutls.org> <1114608568.4613.45.camel@localhost.localdomain> <1114612343.4613.61.camel@localhost.localdomain> Message-ID: <1114616792.4613.84.camel@localhost.localdomain> Hi, Sorry to be so noisy today but it seems that gnutls_assert is not a quit function. Thus we really do ciphertext.data[-1] in file gnutls_cipher.c:453 under the bad condition detailled below. BR, Le mercredi 27 avril 2005 ? 16:32 +0200, Eric Leblond a ?crit : > Hi, > > The problem is here but it is quite weird : > > for (i=2;i if (ciphertext.data[ciphertext.size-i] != ciphertext.data[ciphertext.size - 1]) > } > > But at crash time I've got (taken from gdb): > pad = 148 '\224' > i = 129 > ciphertext.size = 128 > > so it try to do : > ciphertext.data[-1] > > It crashes there but the problem is that previous to this there is : > > if (pad > ciphertext.size - hash_size) { > gnutls_assert(); > /* We do not fail here. We check below for the > * the pad_failed. If zero means success. > */ > pad_failed = GNUTLS_E_DECRYPTION_FAILED; > } > > So we could not be here. > > It seems we've got some concurrent accesses or modifications of data in > ciphertext. > > What do you think of this ? Could this come from my code ? > > > > Hi, > > > > I'm writing back on this thread because my investigations bring me to a > > point where I found the point where the crash occurs (using > > gnutls-1.0.24). > > > > In a gdb session I've got : > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1384118640 (LWP 22734)] > > 0x00002aaaab1f8bf8 in _gnutls_ciphertext2compressed (session=0x5efea0, compress_data=0x60f210 "\001", compress_size=16384, ciphertext= > > {data = 0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", size = 48}, type=22 '\026') > > at gnutls_cipher.c:453 > > 453 if (ciphertext.data[ciphertext.size-i] != ciphertext.data[ciphertext.size - 1]) > > > > backtrace gives me : > > > > #0 0x00002aaaab1f8bf8 in _gnutls_ciphertext2compressed (session=0x5efea0, compress_data=0x60f210 "\001", compress_size=16384, ciphertext= > > {data = 0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", size = 48}, type=22 '\026') > > at gnutls_cipher.c:453 > > #1 0x00002aaaab1f8330 in _gnutls_decrypt (session=0x5efea0, > > ciphertext=0x5f25f5 "g\233?\vq\022@??\037\027?\001??us\t???\233\2106???H\203\020\206?\203\213????\005?????'?V?\205??1", ciphertext_size=48, > > data=0x60f210 "\001", data_size=16384, type=GNUTLS_HANDSHAKE) at gnutls_cipher.c:124 > > #2 0x00002aaaab1f769e in _gnutls_recv_int (session=0x5efea0, type=GNUTLS_HANDSHAKE, htype=GNUTLS_FINISHED, data=0x5f0890 "\017", sizeofdata=1) > > at gnutls_record.c:759 > > #3 0x00002aaaab1faf26 in _gnutls_handshake_io_recv_int (session=0x5efea0, type=GNUTLS_HANDSHAKE, htype=GNUTLS_FINISHED, iptr=0x5f0890, sizeOfPtr=1) > > at gnutls_buffers.c:866 > > #4 0x00002aaaab1fcec9 in _gnutls_recv_handshake_header (session=0x5efea0, type=GNUTLS_FINISHED, recv_type=0x527ff63c) at gnutls_handshake.c:845 > > #5 0x00002aaaab1fd3d8 in _gnutls_recv_handshake (session=0x5efea0, data=0x527ff698, datalen=0x527ff68c, type=GNUTLS_FINISHED, optional=MANDATORY_PACKET) > > at gnutls_handshake.c:995 > > #6 0x00002aaaab1fc264 in _gnutls_recv_finished (session=0x5efea0) at gnutls_handshake.c:460 > > #7 0x00002aaaab1fff9d in _gnutls_recv_handshake_final (session=0x5efea0, init=1) at gnutls_handshake.c:2165 > > #8 0x00002aaaab200900 in _gnutls_handshake_common (session=0x5efea0) at gnutls_handshake.c:2293 > > #9 0x00002aaaab1ff2e8 in gnutls_handshake (session=0x5efea0) at gnutls_handshake.c:1920 > > #10 0x000000000040b287 in tls_connect (c=39, session_ptr=0x527ff798) at tls.c:916 > > #11 0x000000000040b46b in tls_sasl_connect (userdata=0x5dc500, data=0x5f25f5) at tls.c:984 > > #12 0x00002aaaaaf08676 in g_static_rw_lock_free () from /usr/lib/libglib-2.0.so.0 > > #13 0x00002aaaaaf07442 in g_static_private_free () from /usr/lib/libglib-2.0.so.0 > > #14 0x00002aaaab481b55 in start_thread () from /lib/libpthread.so.0 > > #15 0x00002aaaab662630 in clone () from /lib/libc.so.6 > > > > Could someone point me to what's going on ? > > > > I try as said in previous mail to declare thread but it does not change > > anything (But it still use this declaration). > > > > Any tips really welcome ! > > > > BR, > > > > > > Le jeudi 14 avril 2005 ? 11:19 +0200, Nikos Mavrogiannopoulos a ?crit : > > > On Wednesday 13 April 2005 11:17, Eric Leblond wrote: > > > > > > Hello Eric, > > > > > > > * callback need to be declare everywhere or just before > > > > gnutls_global_init ? > > > Yes, only before this function. > > > > > > > * I use glib in the program. It hides pthread functions behind his own > > > > function. Is it sufficient to declare : > > > > GCRY_THREAD_OPTION_PTHREAD_IMPL; > > > I'm not really sure that this is sufficient. It depends on the internals > > > of glib, that I don't know. So you need to make your own locking callbacks and > > > register them as shown in the documentation. > > > > -- > > ?ric Leblond, eleblond at inl.fr > > T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 > > INL, http://www.inl.fr > > > > > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls From nmav at gnutls.org Wed Apr 27 17:55:55 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Apr 2005 17:55:55 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <1114608568.4613.45.camel@localhost.localdomain> References: <425A3F34.1050803@inl.fr> <200504141119.09044.nmav@gnutls.org> <1114608568.4613.45.camel@localhost.localdomain> Message-ID: <200504271755.55753.nmav@gnutls.org> On Wednesday 27 April 2005 15:29, Regit wrote: > Hi, > I'm writing back on this thread because my investigations bring me to a > point where I found the point where the crash occurs (using > gnutls-1.0.24). > In a gdb session I've got : > #0 0x00002aaaab1f8bf8 in _gnutls_ciphertext2compressed (session=0x5efea0, > compress_data=0x60f210 "\001", compress_size=16384, ciphertext= {data = > 0x5f25f5 It is very unlikely that an error occurs there. Most probably there memory is corrupted somewhere else and the error triggers here. Do you use compression btw? Does your server work perfectly without gnutls? Is your locking code for libgcrypt ok? Since, I've gnutls works perfectly in other multi-threaded servers, I'd say that most likely the problem isn't in gnutls. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Wed Apr 27 18:04:28 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Apr 2005 18:04:28 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <1114616792.4613.84.camel@localhost.localdomain> References: <425A3F34.1050803@inl.fr> <1114612343.4613.61.camel@localhost.localdomain> <1114616792.4613.84.camel@localhost.localdomain> Message-ID: <200504271804.28606.nmav@gnutls.org> On Wednesday 27 April 2005 17:46, Regit wrote: > Hi, > Sorry to be so noisy today but it seems that gnutls_assert is not a quit > function. > Thus we really do > ciphertext.data[-1] > in file gnutls_cipher.c:453 under the bad condition detailled below. So if you change this check (line 471) by: if (ver >= GNUTLS_TLS1 && pad_failed==0) fixes the problem? > BR, -- Nikos Mavrogiannopoulos From regit at inl.fr Wed Apr 27 18:19:29 2005 From: regit at inl.fr (Regit) Date: Wed, 27 Apr 2005 18:19:29 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <200504271804.28606.nmav@gnutls.org> References: <425A3F34.1050803@inl.fr> <1114612343.4613.61.camel@localhost.localdomain> <1114616792.4613.84.camel@localhost.localdomain> <200504271804.28606.nmav@gnutls.org> Message-ID: <1114618769.4613.89.camel@localhost.localdomain> Hi, I've done : if (pad > ciphertext.size - hash_size) { gnutls_assert(); /* We do not fail here. We check below for the * the pad_failed. If zero means success. */ pad_failed = GNUTLS_E_DECRYPTION_FAILED; return pad_failed; } And it works till a hour now. This is a never reached time during our stress test. Our stress test is basically having 200 processes connecting to the server at the same time, again and again and very quickly. This was enough to kill the server in usually less than 15min. BR, Le mercredi 27 avril 2005 ? 18:04 +0200, Nikos Mavrogiannopoulos a ?crit : > On Wednesday 27 April 2005 17:46, Regit wrote: > > Hi, > > > Sorry to be so noisy today but it seems that gnutls_assert is not a quit > > function. > > Thus we really do > > ciphertext.data[-1] > > in file gnutls_cipher.c:453 under the bad condition detailled below. > So if you change this check (line 471) by: > if (ver >= GNUTLS_TLS1 && pad_failed==0) > > fixes the problem? > > > BR, > From nmav at gnutls.org Wed Apr 27 18:49:05 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Apr 2005 18:49:05 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <1114618769.4613.89.camel@localhost.localdomain> References: <425A3F34.1050803@inl.fr> <200504271804.28606.nmav@gnutls.org> <1114618769.4613.89.camel@localhost.localdomain> Message-ID: <200504271849.05250.nmav@gnutls.org> On Wednesday 27 April 2005 18:19, you wrote: > Hi, > > I've done : > if (pad > ciphertext.size - hash_size) { > gnutls_assert(); > /* We do not fail here. We check below for the > * the pad_failed. If zero means success. > */ > pad_failed = GNUTLS_E_DECRYPTION_FAILED; > return pad_failed; > } I cannot include this in gnutls since it allows for information leakage to attackers. The next version of gnutls will include this line: > if (ver >= GNUTLS_TLS1 && pad_failed==0) in the next test. so it might be better to test this instead. What does you stress test do? This problem was triggered by wrongly encrypted data. -- Nikos Mavrogiannopoulos From regit at inl.fr Wed Apr 27 19:03:31 2005 From: regit at inl.fr (Regit) Date: Wed, 27 Apr 2005 19:03:31 +0200 Subject: [Help-gnutls] segfault in internal function In-Reply-To: <200504271849.05250.nmav@gnutls.org> References: <425A3F34.1050803@inl.fr> <200504271804.28606.nmav@gnutls.org> <1114618769.4613.89.camel@localhost.localdomain> <200504271849.05250.nmav@gnutls.org> Message-ID: <1114621411.4613.105.camel@localhost.localdomain> Le mercredi 27 avril 2005 ? 18:49 +0200, Nikos Mavrogiannopoulos a ?crit : > so it might be better to test this instead. What does you stress test > do? This problem was triggered by wrongly encrypted data. We run legitimate NuFW (http://www.nufw.org) clients in heavy loop with false login and password. There's a queuing mechanism which sends newly established connections to a pool of threads which work on user authentication. As it has to wait for a moment, we may have been experimenting some datas corruption by buffer overflow or something else (We aren't sure why this raised this problem since we did not actually try to send corrupted datas). BR, -- ?ric Leblond, eleblond at inl.fr T?l?phone : 01 44 89 46 40, Fax : 01 44 89 45 01 INL, http://www.inl.fr From nmav at gnutls.org Thu Apr 28 09:25:38 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Apr 2005 09:25:38 +0200 Subject: [Help-gnutls] certtool and win2k In-Reply-To: <20050426000513.GA4784@suffields.me.uk> References: <20050425182449.GA7181@suffields.me.uk> <200504252129.04759.nmav@gnutls.org> <20050426000513.GA4784@suffields.me.uk> Message-ID: <200504280925.38548.nmav@gnutls.org> On Tuesday 26 April 2005 02:05, Andrew Suffield wrote: > On Mon, Apr 25, 2005 at 09:29:04PM +0200, Nikos Mavrogiannopoulos wrote: > > On Monday 25 April 2005 20:24, Andrew Suffield wrote: > > > Has anybody managed to get certtool/gnutls-generated keys to work with > > > win2k? I started out with a weird problem, and eventually tracked it > > > down to something that makes no sense to me at all: > > Hello Andrew, > > can win2k import the attached key? > Nope. I've updated the library to generate the proper coefficient now. If desired old keys can be fixed to contain the correct parameters with the new certtool (certtool -k newkey). This does not change the secret key, but rather some parameters that depend on it. -- Nikos Mavrogiannopoulos From jas at extundo.com Thu Apr 28 13:06:48 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 28 Apr 2005 13:06:48 +0200 Subject: [Help-gnutls] GnuTLS 1.2.3 and 1.0.25 Message-ID: We are pleased to announce the availability of two new GnuTLS releases; GnuTLS 1.2.3 and GnuTLS 1.0.25! These releases were prompted by the discovery of a denial of service problem. We recommend 1.0 users to move to 1.2. We will continue to make releases on the old branch when security problems are discovered, for those who feel unable to upgrade. We do not have the resources to analyze and write an explanation of this security problem. Volunteers who want to read the bug reports and the CVS changes, and write up an explanation in plain English, are most welcome! Having a detailed track record of security problems can be a useful reference when discussing security in free software packages in general. Naturally, if you wish to sponsor us to do this work for you, please contact me. PS. The ftp.gnutls.org server appear down at the moment, but the files below will be available as soon as possible. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.0.25.tar.gz (1.5MB) ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.0.25.tar.gz (1.5MB) http://josefsson.org/gnutls/releases/gnutls-1.2.3.tar.bz2 (2.4MB) ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.3.tar.bz2 (2.4MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.0.25.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.0.25.tar.gz.sig http://josefsson.org/gnutls/releases/gnutls-1.2.3.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.2.3.tar.bz2.sig Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the MD5/SHA1 checksums: 3585b5b204135e51e0efc9084b3e028b gnutls-1.0.25.tar.gz 80527e5a5d17e199cb8a2848178990a6 gnutls-1.0.25.tar.gz.sig e790b848b9aa1e98d8f28ecf522d8e5dc7e0cb0b gnutls-1.0.25.tar.gz 7db580ff783bcfb2febe5085f3a3ad10d76d5508 gnutls-1.0.25.tar.gz.sig 4986c2bf8ce533d6b5d4dd6f9f1bbdf1 gnutls-1.2.3.tar.bz2 04a61b016ae24c4b7983c2373c9e023c gnutls-1.2.3.tar.bz2.sig 78e1b92a9d818479faca9042d446eed61770fb17 gnutls-1.2.3.tar.bz2 c3ccbd42db7918e5d1f69dbdd40e755f8fa5a985 gnutls-1.2.3.tar.bz2.sig Noteworthy changes since version 1.0.24/1.2.3: - Corrected bug in record packet parsing that could lead to a denial of service attack. - Corrected bug in RSA key export. Previously exported keys can be fixed using certtool. Use certtool -k outfile - API and ABI modifications: gnutls_x509_privkey_fix(): Add. Enjoy, Nikos and Simon