From nmav at gnutls.org Tue May 11 13:47:55 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 11 May 2004 14:47:55 +0300 Subject: [Help-gnutls] programs that use gnutls Message-ID: <200405111447.55259.nmav@gnutls.org> Hello, I'll create a list of programs that use gnutls to be put in the gnutls' site. I'd appreciate if you have such a program to send me, the name, an URL, and a one-two line description of it, to be included. Thank you. -- Nikos Mavroyanopoulos From typo at netcabo.pt Mon May 17 23:43:29 2004 From: typo at netcabo.pt (Pedro Corte-Real) Date: Mon, 17 May 2004 22:43:29 +0100 Subject: [Help-gnutls] Strange error when using libgnutls Message-ID: <1084830208.1269.16.camel@dijkstra> When using a slightly modified version of the example code at: http://www.gnu.org/software/gnutls/documentation/gnutls/gnutls.html#SECTION00731000000000000000 The only modification I've done is to run gnutls_record_recv in a loop to fetch everything until it gets an error or EOF. The file is attatched. I get this error: "A TLS packet with unexpected length was received." This happens when receiving the last block of information when gnutls_record_recv returns an error (-9) instead of 0 for EOF. I'm using libgnutls10 from debian sid at version 1.0.4-3. I can reproduce this reliably against my local apache-ssl (OpenSSL) server. This does not seam to happen when testing with https://www.gnutls.org:5555/. I'm not subscribed to the list so please CC me on replies. Greetings, Pedro C?rte-Real. -------------- next part -------------- A non-text attachment was scrubbed... Name: fetcher_ssl.c Type: text/x-csrc Size: 2997 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Tue May 18 09:50:33 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 18 May 2004 10:50:33 +0300 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <1084830208.1269.16.camel@dijkstra> References: <1084830208.1269.16.camel@dijkstra> Message-ID: <200405181050.33387.nmav@gnutls.org> On Tuesday 18 May 2004 00:43, Pedro Corte-Real wrote: > When using a slightly modified version of the example code at: > http://www.gnu.org/software/gnutls/documentation/gnutls/gnutls.html#SECTION >00731000000000000000 > The only modification I've done is to run gnutls_record_recv in a loop > to fetch everything until it gets an error or EOF. > The file is attatched. > I get this error: > "A TLS packet with unexpected length was received." > This happens when receiving the last block of information when > gnutls_record_recv returns an error (-9) instead of 0 for EOF. This is because the other end does not properly terminate the TLS session. Several https servers do that. > Greetings, > Pedro C?rte-Real. -- Nikos Mavroyanopoulos From typo at netcabo.pt Tue May 18 15:06:18 2004 From: typo at netcabo.pt (Pedro Corte-Real) Date: Tue, 18 May 2004 14:06:18 +0100 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <200405181050.33387.nmav@gnutls.org> References: <1084830208.1269.16.camel@dijkstra> <200405181050.33387.nmav@gnutls.org> Message-ID: <1084885578.1271.0.camel@dijkstra> On Tue, 2004-05-18 at 10:50 +0300, Nikos Mavroyanopoulos wrote: > On Tuesday 18 May 2004 00:43, Pedro Corte-Real wrote: > > > When using a slightly modified version of the example code at: > > http://www.gnu.org/software/gnutls/documentation/gnutls/gnutls.html#SECTION > >00731000000000000000 > > The only modification I've done is to run gnutls_record_recv in a loop > > to fetch everything until it gets an error or EOF. > > The file is attatched. > > I get this error: > > "A TLS packet with unexpected length was received." > > This happens when receiving the last block of information when > > gnutls_record_recv returns an error (-9) instead of 0 for EOF. > This is because the other end does not properly terminate the > TLS session. Several https servers do that. Any way around this? Pedro C?rte-Real. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Tue May 18 20:09:56 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue, 18 May 2004 21:09:56 +0300 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <1084885578.1271.0.camel@dijkstra> References: <1084830208.1269.16.camel@dijkstra> <200405181050.33387.nmav@gnutls.org> <1084885578.1271.0.camel@dijkstra> Message-ID: <200405182109.56102.nmav@gnutls.org> On Tuesday 18 May 2004 16:06, you wrote: > > This is because the other end does not properly terminate the > > TLS session. Several https servers do that. > Any way around this? Treat that error as an EOF. > Pedro C?rte-Real. -- Nikos Mavroyanopoulos From typo at netcabo.pt Tue May 18 21:04:46 2004 From: typo at netcabo.pt (Pedro Corte-Real) Date: Tue, 18 May 2004 20:04:46 +0100 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <200405182109.56102.nmav@gnutls.org> References: <1084830208.1269.16.camel@dijkstra> <200405181050.33387.nmav@gnutls.org> <1084885578.1271.0.camel@dijkstra> <200405182109.56102.nmav@gnutls.org> Message-ID: <1084907085.1271.5.camel@dijkstra> On Tue, 2004-05-18 at 21:09 +0300, Nikos Mavroyanopoulos wrote: > On Tuesday 18 May 2004 16:06, you wrote: > > > > This is because the other end does not properly terminate the > > > TLS session. Several https servers do that. > > Any way around this? > Treat that error as an EOF. And what if I get a real one of those errors? One that happens at some time other than EOF? Pedro C?rte-Real. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Thu May 20 10:59:55 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu, 20 May 2004 11:59:55 +0300 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <1084907085.1271.5.camel@dijkstra> References: <1084830208.1269.16.camel@dijkstra> <200405182109.56102.nmav@gnutls.org> <1084907085.1271.5.camel@dijkstra> Message-ID: <200405201159.55836.nmav@gnutls.org> On Tuesday 18 May 2004 22:04, you wrote: > > Treat that error as an EOF. > And what if I get a real one of those errors? One that happens at some > time other than EOF? You cannot distinguish it from a real error. Servers with that behaviour violate the TLS protocol. > Pedro C?rte-Real. -- Nikos Mavroyanopoulos From typo at netcabo.pt Fri May 21 19:14:17 2004 From: typo at netcabo.pt (Pedro Corte-Real) Date: Fri, 21 May 2004 18:14:17 +0100 Subject: [Help-gnutls] Small gnutls bug Message-ID: <1085159657.5884.8.camel@dijkstra> The gnutls_record_recv() function has a small but annoying bug. The documentation claims that it follows recv() semantics. But while this is valid with recv: call to recv(...) returns someval call to recv(...) returns 0 call to recv(...) returns 0 The same thing with gnutls_record_recv does not work and returns an error on the last call. Pedro C?rte-Real. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Fri May 21 22:19:40 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri, 21 May 2004 23:19:40 +0300 Subject: [Help-gnutls] Strange error when using libgnutls In-Reply-To: <1085159412.5884.2.camel@dijkstra> References: <1084830208.1269.16.camel@dijkstra> <200405201159.55836.nmav@gnutls.org> <1085159412.5884.2.camel@dijkstra> Message-ID: <200405212319.40487.nmav@gnutls.org> On Friday 21 May 2004 20:10, you wrote: > > You cannot distinguish it from a real error. Servers with that behaviour > > violate the TLS protocol. > OpenSSL is used in a big portion of the HTTPS servers in the web > couldn't gnutls work around this? This could either be done my emitting > a different error ("OpenSSL sucks and violates the TLS protocol") or by > having an gnutls call that makes in lets strict about these things. This is not an openssl problem, but rather a problem with the specific https[0] server. Gnutls does the proper thing in that case. It warns you about the premature close, but you can always be less strict by ignoring this error, it's up to you and your application's requirements. > Pedro C?rte-Real. -- Nikos Mavroyanopoulos From nmav at gnutls.org Sat May 22 11:53:39 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat, 22 May 2004 12:53:39 +0300 Subject: [Help-gnutls] Small gnutls bug In-Reply-To: <1085159657.5884.8.camel@dijkstra> References: <1085159657.5884.8.camel@dijkstra> Message-ID: <200405221253.40041.nmav@gnutls.org> On Friday 21 May 2004 20:14, Pedro Corte-Real wrote: > The gnutls_record_recv() function has a small but annoying bug. The > documentation claims that it follows recv() semantics. But while this is > valid with recv: > call to recv(...) returns someval > call to recv(...) returns 0 > call to recv(...) returns 0 > The same thing with gnutls_record_recv does not work and returns an > error on the last call. Thank you for reporting this. If there are no side-effects I'll correct it soon. > Pedro C?rte-Real. -- Nikos Mavroyanopoulos From jas at extundo.com Mon May 31 20:53:41 2004 From: jas at extundo.com (Simon Josefsson) Date: Mon, 31 May 2004 20:53:41 +0200 Subject: [Help-gnutls] Default cipher priority in `gnutls-cli'? Message-ID: I just installed GNUTLS support for STARTTLS in Emacs, via gnutls-cli. When doing so, and personally moving away from the OpenSSL based 'starttls' tool to gnutls-cli, I noticed gnutls-cli default to RC4: starttls: TLSv1 with cipher RC4-SHA (128/128 bits new) no authentication Whereas OpenSSL's default was AES-256. Looking at the code, the current default priority list appear to be: RC4-128, AES-128, 3DES, AES-256, RC4-40 Is there some motivation for that priority order? IMHO, I find a list like the following would be easier to motivate: AES-256, AES-128, 3DES, RC4-128, RC4-40 Where the motivation would be: first use strongest standardized cipher (AES-256/128), followed by strongest historical cipher (3DES), followed by interop ciphers. Thanks. --- cli.c 21 May 2004 19:55:09 +0200 2.237 +++ cli.c 31 May 2004 20:45:32 +0200 @@ -90,8 +90,8 @@ GNUTLS_KX_ANON_DH, GNUTLS_KX_RSA_EXPORT, 0 }; int cipher_priority[PRI_MAX] = - { GNUTLS_CIPHER_ARCFOUR_128, GNUTLS_CIPHER_AES_128_CBC, - GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_AES_256_CBC, + { GNUTLS_CIPHER_AES_256_CBC, GNUTLS_CIPHER_AES_128_CBC, + GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_ARCFOUR_128, GNUTLS_CIPHER_ARCFOUR_40, 0 }; int comp_priority[PRI_MAX] = { GNUTLS_COMP_ZLIB, GNUTLS_COMP_NULL, 0 }; From nmav at gnutls.org Mon May 31 22:13:32 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon, 31 May 2004 23:13:32 +0300 Subject: [Help-gnutls] Default cipher priority in `gnutls-cli'? In-Reply-To: References: Message-ID: <200405312313.32965.nmav@gnutls.org> On Monday 31 May 2004 21:53, Simon Josefsson wrote: > I just installed GNUTLS support for STARTTLS in Emacs, via gnutls-cli. > When doing so, and personally moving away from the OpenSSL based > 'starttls' tool to gnutls-cli, I noticed gnutls-cli default to RC4: > starttls: TLSv1 with cipher RC4-SHA (128/128 bits new) no authentication > Whereas OpenSSL's default was AES-256. > Looking at the code, the current default priority list appear to be: > > RC4-128, AES-128, 3DES, AES-256, RC4-40 > Is there some motivation for that priority order? > IMHO, I find a list like the following would be easier to motivate: > AES-256, AES-128, 3DES, RC4-128, RC4-40 > Where the motivation would be: first use strongest standardized cipher > (AES-256/128), followed by strongest historical cipher (3DES), > followed by interop ciphers. As far as I remember speed was the motivation, but you are right, the cipher strength should be the sorting key. I'll update the client soon. > Thanks. -- Nikos Mavroyanopoulos