From mrsam at courier-mta.com Sat May 1 15:56:24 2010 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 01 May 2010 09:56:24 -0400 Subject: Problem using the server name extension References: <87aasmptwz.fsf@mocca.josefsson.org> <8739ydf0hr.fsf@mocca.josefsson.org> Message-ID: Sam Varshavchik writes: > Simon Josefsson writes: > >> Sam Varshavchik writes: >> >>> Simon Josefsson writes: >>> >>>> Sam Varshavchik writes: >>>> >>>>> My client is compiled against gnutls 2.8.5. I am connecting to a >>>>> server that's built against OpenSSL 1.0.0. >>>>> >>>>> The OpenSSL server is failing the handshake with the following error >>>>> message: >>>>> >>>>> error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext >>>>> >>>>> After some Googling around, I remove my client's call to >>>>> gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes >>>>> OpenSSL happy. >>>>> >>>>> If I do not invoke gnutls_server_name_set(), we have a happy >>>>> conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out >>>>> during the handshake. >>>>> >>>>> Has anyone seen this before? >>>> >>>> We've seen it for very old implementations, notably some IBM-derived >>>> variant of OpenSSL, that cannot handle any extensions. But it is very >>>> surprising to see it for a recent OpenSSL. Are you sure OpenSSL 1.0.0 >>>> is used? Can you reproduce this using 'openssl s_server'? Maybe the >>>> application server is requesting SSLv2 from OpenSSL? >>> >>> The application is the client, and since the application is GnuTLS, it >>> can't be asking for SSLv2. >>> >>> Yes, Fedora 12, OpenSSL 1.0.0 is the server side. It's configured to >>> accept all protocols (SSLv23_method() in OpenSSL's API), but I also >>> tried TLSv1_method() as well, no difference. >>> >>> On the GnuTLS client side, I'm specifying GNUTLS_TLS1_1, >>> GNUTLS_TLS1_0, and GNUTLS_SSL3 in that order. This is not a direct >>> SSL/TLS connection, this is IMAP STARTTLS, so I can't easily drop in >>> s_server in the server's place. >>> >>> I'll explore what debugging messages are available on the OpenSSL >>> side. I gave up on the debugger. Debugging optimized code, on either >>> the server or the client side, just doesn't work very well. >> >> Maybe you can reproduce this using 'gnutls-cli'? It supports STARTTLS >> by using --starttls and entering ^D when you want to start the TLS >> handshake. Please post output from 'gnutls-cli -d 4711' if you can >> reproduce it. > > Well now, that seems to work. The handshake appears to complete successfully > with gnutls-cli. Perusing gnutls-cli's source, it does seem to use > gnutls_server_name_set() by default, so this is a valid, working baseline. > > So, it appears that I'm doing something on the client side, with GnuTLS, > that's making OpenSSL on the server side crap out. Looks like I have > something that I can dig into. Stay tuned. > >> Maybe the server name you provide is simply the wrong one, and that's >> why the server refuses to talk with you? > > I don't think that's it. It's "localhost" in both cases. I'm not certain > that OpenSSL implements this extension. Well, thanks to the suggestion to use gnutls-cli, it set me on the right path to track down a bug in my code that passed zero for the name_length parameter to gnutls_server_name_set(). This apparently slipped past the library, which still sent a SERVER_NAME extension packet, but with a null hostname, which OpenSSL on the server side rejected with an alert, terminating the handshake. Looks like OpenSSL either silently the server name extension which it doesn't recognize, or passes this down to the application (although a quick search doesn't seem to locate an OpenSSL API to retrieve the client's requested server name), however it rejects outright a 0-length requested server name. If you pass an empty string to gnutls_server_name_set() you'll see what I was seeing. And that's all she wrote. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From carolin.latze at unifr.ch Mon May 3 16:33:20 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Mon, 3 May 2010 16:33:20 +0200 Subject: supplemental data handshake message In-Reply-To: <87vdb9dllv.fsf@mocca.josefsson.org> References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> Message-ID: <4BDEDEB0.6030602@unifr.ch> Hi Simon >> >> int _gnutls_helloworld_supp_recv_params(gnutls_session_t session,const >> opaque *data,size_t _data_size) >> { >> uint8_t len; >> ssize_t data_size = _data_size; >> unsigned char *msg; >> >> if (data_size > 0) >> { >> len = data[0]; >> DECR_LEN (data_size, len); >> msg=(unsigned char*)malloc(len*sizeof(unsigned char)); >> memcpy(msg,&data[1],len); >> msg[len]='\0'; >> printf("supp data: %s\n",msg); >> } >> >> return 0; >> > > > Shouldn't you return the length of parsed data here? Look at > gnutls_supplemental.c, the function _gnutls_parse_supplemental trusts > your function to return the proper length for incrementing the length > pointer for its parsing code. > > Just a quick response, haven't looked into this in detail. > > /Simon > I don't know whether that would have been the next issue (I fixed it anyway now), but the bigger problem was that I forgot to specify the helloworld supplemental functions and type in lib/gnutls_supplemental.c: gnutls_supplemental_entry _gnutls_supplemental[] = { { "helloworld", GNUTLS_SUPPLEMENTAL_HELLOWORLD_DATA, gnutls_helloworld_supp_recv_params, gnutls_helloworld_supp_send_params }, {0, 0, 0, 0} }; Now, I got one step further and the crash occurs in ext_helloworld.c in _gnutls_helloworld_supp_recv_params in line "DECR_LEN (data_size, len);". I try to debug that further.... Thanks! Carolin From carolin.latze at unifr.ch Mon May 3 17:23:21 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Mon, 3 May 2010 17:23:21 +0200 Subject: supplemental data handshake message In-Reply-To: <4BDEDEB0.6030602@unifr.ch> References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> Message-ID: <4BDEEA69.608@unifr.ch> Hi again, it seems there is a mismatched between the length the sender assumes to send (which is the correct length) and the length the receiver is able to retrieve out of the buffer. The debug output on the sender says the following: --debug-- server.log screenshot --end debug-- (sorry didn't have time to capture that properly) The data is indeed 10 bytes long, which results in 14 bytes to be sent due to the 2 byte length and type. So, the server.log make sense to me. However the client does something strange: --debug-- REC[0x954f378]: Received Packet[1] Handshake(22) with length: 14 REC[0x954f378]: Decrypted Packet[1] Handshake(22) with length: 14 HSK[0x954f378]: SUPPLEMENTAL was received [14 bytes] EXT[0x954f378]: Got supplemental type=01 length=3 --end debug-- I set the type to 1, so that makes sense as well. However... why does it read out a length of 3? It receives the correct packet length of 14 bytes. It is gnutls_supplemental.c that generates the packet and parses it... so I would expect that it would parse it correctly. Any ideas or hints? Carolin Carolin Latze wrote: > Hi Simon > >>> int _gnutls_helloworld_supp_recv_params(gnutls_session_t session,const >>> opaque *data,size_t _data_size) >>> { >>> uint8_t len; >>> ssize_t data_size = _data_size; >>> unsigned char *msg; >>> >>> if (data_size > 0) >>> { >>> len = data[0]; >>> DECR_LEN (data_size, len); >>> msg=(unsigned char*)malloc(len*sizeof(unsigned char)); >>> memcpy(msg,&data[1],len); >>> msg[len]='\0'; >>> printf("supp data: %s\n",msg); >>> } >>> >>> return 0; >>> >>> >> Shouldn't you return the length of parsed data here? Look at >> gnutls_supplemental.c, the function _gnutls_parse_supplemental trusts >> your function to return the proper length for incrementing the length >> pointer for its parsing code. >> >> Just a quick response, haven't looked into this in detail. >> >> /Simon >> >> > I don't know whether that would have been the next issue (I fixed it > anyway now), but the bigger problem was that I forgot to specify the > helloworld supplemental functions and type in lib/gnutls_supplemental.c: > > > gnutls_supplemental_entry _gnutls_supplemental[] = { > { "helloworld", > GNUTLS_SUPPLEMENTAL_HELLOWORLD_DATA, > gnutls_helloworld_supp_recv_params, > gnutls_helloworld_supp_send_params }, > {0, 0, 0, 0} > }; > > Now, I got one step further and the crash occurs in ext_helloworld.c in > _gnutls_helloworld_supp_recv_params in line "DECR_LEN (data_size, > len);". I try to debug that further.... > > Thanks! > Carolin > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From simon at josefsson.org Mon May 3 17:45:35 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 May 2010 17:45:35 +0200 Subject: supplemental data handshake message In-Reply-To: <4BDEEA69.608@unifr.ch> (Carolin Latze's message of "Mon, 3 May 2010 17:23:21 +0200") References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> <4BDEEA69.608@unifr.ch> Message-ID: <87hbmp0z1c.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi again, > > it seems there is a mismatched between the length the sender assumes > to send (which is the correct length) and the length the receiver is > able to retrieve out of the buffer. The debug output on the sender > says the following: > > --debug-- > server.log screenshot > --end debug-- > > (sorry didn't have time to capture that properly) > > The data is indeed 10 bytes long, which results in 14 bytes to be sent > due to the 2 byte length and type. So, the server.log make sense to > me. However the client does something strange: > > --debug-- > REC[0x954f378]: Received Packet[1] Handshake(22) with length: 14 > REC[0x954f378]: Decrypted Packet[1] Handshake(22) with length: 14 > HSK[0x954f378]: SUPPLEMENTAL was received [14 bytes] > EXT[0x954f378]: Got supplemental type=01 length=3 > --end debug-- > > I set the type to 1, so that makes sense as well. However... why does > it read out a length of 3? It receives the correct packet length of 14 > bytes. It is gnutls_supplemental.c that generates the packet and > parses it... so I would expect that it would parse it correctly. Any > ideas or hints? It is difficult to tell from just description of the problem... Try printing the entire buffer that is sent by _gnutls_gen_supplement and the buffer received by _gnutls_parse_supplemental and hand-check that they are correct and match. Maybe you could push a git branch with your work somewhere, so we can more easily reproduce the problem? I suspect it is just a encoding/decoding bug somewhere. /Simon From carolin.latze at unifr.ch Wed May 5 14:07:44 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Wed, 5 May 2010 14:07:44 +0200 Subject: supplemental data handshake message In-Reply-To: <87hbmp0z1c.fsf@mocca.josefsson.org> References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> <4BDEEA69.608@unifr.ch> <87hbmp0z1c.fsf@mocca.josefsson.org> Message-ID: <4BE15F90.2050904@unifr.ch> Hi Simon, > > It is difficult to tell from just description of the problem... Try > printing the entire buffer that is sent by _gnutls_gen_supplement and > the buffer received by _gnutls_parse_supplemental and hand-check that > they are correct and match. If I did not do something completely wrong (which is ofc always possible), they do not match, which is weird. Like you will see in the source code below, I printed buf at the end of _gnutls_gen_supplemental as well as data at the beginning of _gnutls_parse_supplemental. > Maybe you could push a git branch with your > work somewhere, so we can more easily reproduce the problem? > > Due to the lack of a git server, I put my GnuTLS version on a webserver: http://diuf.unifr.ch/people/latzec/gnutls-2.9.11-CL.tar.gz If you prefer a git branch, I need to get a server first :-) (which is probably not impossible, but needs more time :)) Thanks a lot! Carolin From simon at josefsson.org Wed May 5 14:51:27 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 May 2010 14:51:27 +0200 Subject: supplemental data handshake message In-Reply-To: <4BE15F90.2050904@unifr.ch> (Carolin Latze's message of "Wed, 5 May 2010 14:07:44 +0200") References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> <4BDEEA69.608@unifr.ch> <87hbmp0z1c.fsf@mocca.josefsson.org> <4BE15F90.2050904@unifr.ch> Message-ID: <87pr1ase9c.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi Simon, > > >> >> It is difficult to tell from just description of the problem... Try >> printing the entire buffer that is sent by _gnutls_gen_supplement and >> the buffer received by _gnutls_parse_supplemental and hand-check that >> they are correct and match. > If I did not do something completely wrong (which is ofc always > possible), they do not match, which is weird. Like you will see in the > source code below, I printed buf at the end of > _gnutls_gen_supplemental as well as data at the beginning of > _gnutls_parse_supplemental. There is a bug in your printing code, it has to be: _gnutls_debug_log ("EXT[%p]: supp send buffer: ",session); for(i=0;ilength;i++) _gnutls_debug_log ("%02x",buf->data[i] & 0xFF); Check the warnings when you build the code, it would catch issues like that. With that, the buffers sent and received are identical: |<2>| EXT[0x9073780]: supp send buffer: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| |<2>| EXT[0x8de9c58]: recv supp buf: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| Another bug was that your ext_helloworld.c cleared out the buffer, you need to remove this call: _gnutls_buffer_init(buf); >> Maybe you could push a git branch with your >> work somewhere, so we can more easily reproduce the problem? >> >> > Due to the lack of a git server, I put my GnuTLS version on a webserver: > http://diuf.unifr.ch/people/latzec/gnutls-2.9.11-CL.tar.gz > > If you prefer a git branch, I need to get a server first :-) (which is > probably not impossible, but needs more time :)) A tarball is fine. You can push to free git servers out there, such as repo.or.cz. /Simon From simon at josefsson.org Fri May 7 11:32:36 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 07 May 2010 11:32:36 +0200 Subject: supplemental data handshake message In-Reply-To: <4BE3DA22.7040709@unifr.ch> (Carolin Latze's message of "Fri, 7 May 2010 11:15:14 +0200") References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> <4BDEEA69.608@unifr.ch> <87hbmp0z1c.fsf@mocca.josefsson.org> <4BE15F90.2050904@unifr.ch> <87pr1ase9c.fsf@mocca.josefsson.org> <4BE3DA22.7040709@unifr.ch> Message-ID: <87ocgsys3v.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi Simon, > > I finally got it running!! :-) > > The _gnutls_buffer_init was the problem that fixed the length > issue. The next problem was that I did not expect to get the data only > in _gnutls_helloworld_supp_recv. Instead I tried to parse it again > (reading the length etc) which caused segfaults. After I figured out > that I do not have to parse anything anymore, I got it running :-) Great! I think a "hello world" Supplemental Data extension example would be quite useful for people interested in writing such things, much like the writeup on writing a TLS extension. > I will prepare some (short) documentation that I will post to the list > in the next few days. Feel free to copy it into your documentation in > order to make it easier for other people when they try to implement a > new supplemental data handshake message. In order to use any contribution in the official documentation, you need to sign over the copyright to the FSF. I'll send you papers privately. /Simon > Regards and thanks a lot for your help! > Carolin > > On 05/05/2010 02:51 PM, Simon Josefsson wrote: >> Carolin Latze writes: >> >> >>> Hi Simon, >>> >>> >>> >>>> It is difficult to tell from just description of the problem... Try >>>> printing the entire buffer that is sent by _gnutls_gen_supplement and >>>> the buffer received by _gnutls_parse_supplemental and hand-check that >>>> they are correct and match. >>>> >>> If I did not do something completely wrong (which is ofc always >>> possible), they do not match, which is weird. Like you will see in the >>> source code below, I printed buf at the end of >>> _gnutls_gen_supplemental as well as data at the beginning of >>> _gnutls_parse_supplemental. >>> >> There is a bug in your printing code, it has to be: >> >> _gnutls_debug_log ("EXT[%p]: supp send buffer: ",session); >> for(i=0;ilength;i++) _gnutls_debug_log ("%02x",buf->data[i]& 0xFF); >> >> Check the warnings when you build the code, it would catch issues like >> that. >> >> With that, the buffers sent and received are identical: >> >> |<2>| EXT[0x9073780]: supp send buffer: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| >> >> |<2>| EXT[0x8de9c58]: recv supp buf: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| >> >> Another bug was that your ext_helloworld.c cleared out the buffer, you >> need to remove this call: >> >> _gnutls_buffer_init(buf); >> >> >>>> Maybe you could push a git branch with your >>>> work somewhere, so we can more easily reproduce the problem? >>>> >>>> >>>> >>> Due to the lack of a git server, I put my GnuTLS version on a webserver: >>> http://diuf.unifr.ch/people/latzec/gnutls-2.9.11-CL.tar.gz >>> >>> If you prefer a git branch, I need to get a server first :-) (which is >>> probably not impossible, but needs more time :)) >>> >> A tarball is fine. You can push to free git servers out there, such as >> repo.or.cz. >> >> /Simon >> From carolin.latze at unifr.ch Fri May 7 11:15:14 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Fri, 7 May 2010 11:15:14 +0200 Subject: supplemental data handshake message In-Reply-To: <87pr1ase9c.fsf@mocca.josefsson.org> References: <4BDAE3F0.6070804@unifr.ch> <87vdb9dllv.fsf@mocca.josefsson.org> <4BDEDEB0.6030602@unifr.ch> <4BDEEA69.608@unifr.ch> <87hbmp0z1c.fsf@mocca.josefsson.org> <4BE15F90.2050904@unifr.ch> <87pr1ase9c.fsf@mocca.josefsson.org> Message-ID: <4BE3DA22.7040709@unifr.ch> Hi Simon, I finally got it running!! :-) The _gnutls_buffer_init was the problem that fixed the length issue. The next problem was that I did not expect to get the data only in _gnutls_helloworld_supp_recv. Instead I tried to parse it again (reading the length etc) which caused segfaults. After I figured out that I do not have to parse anything anymore, I got it running :-) I will prepare some (short) documentation that I will post to the list in the next few days. Feel free to copy it into your documentation in order to make it easier for other people when they try to implement a new supplemental data handshake message. Regards and thanks a lot for your help! Carolin On 05/05/2010 02:51 PM, Simon Josefsson wrote: > Carolin Latze writes: > > >> Hi Simon, >> >> >> >>> It is difficult to tell from just description of the problem... Try >>> printing the entire buffer that is sent by _gnutls_gen_supplement and >>> the buffer received by _gnutls_parse_supplemental and hand-check that >>> they are correct and match. >>> >> If I did not do something completely wrong (which is ofc always >> possible), they do not match, which is weird. Like you will see in the >> source code below, I printed buf at the end of >> _gnutls_gen_supplemental as well as data at the beginning of >> _gnutls_parse_supplemental. >> > There is a bug in your printing code, it has to be: > > _gnutls_debug_log ("EXT[%p]: supp send buffer: ",session); > for(i=0;ilength;i++) _gnutls_debug_log ("%02x",buf->data[i]& 0xFF); > > Check the warnings when you build the code, it would catch issues like > that. > > With that, the buffers sent and received are identical: > > |<2>| EXT[0x9073780]: supp send buffer: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| > > |<2>| EXT[0x8de9c58]: recv supp buf: |<2>| 00|<2>| 00|<2>| 07|<2>| 00|<2>| 01|<2>| 00|<2>| 03|<2>| 6c|<2>| 6c|<2>| 6f|<2>| > > Another bug was that your ext_helloworld.c cleared out the buffer, you > need to remove this call: > > _gnutls_buffer_init(buf); > > >>> Maybe you could push a git branch with your >>> work somewhere, so we can more easily reproduce the problem? >>> >>> >>> >> Due to the lack of a git server, I put my GnuTLS version on a webserver: >> http://diuf.unifr.ch/people/latzec/gnutls-2.9.11-CL.tar.gz >> >> If you prefer a git branch, I need to get a server first :-) (which is >> probably not impossible, but needs more time :)) >> > A tarball is fine. You can push to free git servers out there, such as > repo.or.cz. > > /Simon > From pedro.pereira at tut.fi Mon May 10 16:08:25 2010 From: pedro.pereira at tut.fi (Pedro Pereira) Date: Mon, 10 May 2010 17:08:25 +0300 Subject: Error compiling a example code ("undefined reference to tcp_connect and tcp_close") Message-ID: <20100510170825.15703ue0tbaonwao@webmail.tut.fi> Hi all, I am beginning with gnutls for the first time. I have already installed every libraries and gnutls. For now I am trying to compile a simple example that is available in the manual, "Simple Client Example with Anonymous Authentication": http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-anonymous-authentication.html#Simple-client-example-with-anonymous-authentication I am just compiling adding the -lgnutls, and I receive some errors. the following output: $ gcc -o foo foo.c -lgnutls /tmp/ccnYRTg5.o: In function `main': foo.c:(.text+0x73): undefined reference to `tcp_connect' foo.c:(.text+0x22e): undefined reference to `tcp_close' collect2: ld returned 1 exit status It seems that the functions tcp_connect and tcp_close are not found inside the gnutls library.. Can someone help me to compile this example? Kind Regards, Pedro From simon at josefsson.org Mon May 10 17:50:32 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 May 2010 17:50:32 +0200 Subject: Error compiling a example code ("undefined reference to tcp_connect and tcp_close") In-Reply-To: <20100510170825.15703ue0tbaonwao@webmail.tut.fi> (Pedro Pereira's message of "Mon, 10 May 2010 17:08:25 +0300") References: <20100510170825.15703ue0tbaonwao@webmail.tut.fi> Message-ID: <87bpcn7o3b.fsf@mocca.josefsson.org> Pedro Pereira writes: > Hi all, > > I am beginning with gnutls for the first time. > I have already installed every libraries and gnutls. > For now I am trying to compile a simple example that is available in > the manual, "Simple Client Example with Anonymous Authentication": > http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-anonymous-authentication.html#Simple-client-example-with-anonymous-authentication > > I am just compiling adding the -lgnutls, and I receive some errors. > the following output: > > $ gcc -o foo foo.c -lgnutls > /tmp/ccnYRTg5.o: In function `main': > foo.c:(.text+0x73): undefined reference to `tcp_connect' > foo.c:(.text+0x22e): undefined reference to `tcp_close' > collect2: ld returned 1 exit status > > It seems that the functions tcp_connect and tcp_close are not found > inside the gnutls library.. > Can someone help me to compile this example? Read this section: http://www.gnu.org/software/gnutls/manual/html_node/Helper-function-for-TCP-connections.html /Simon From rutski89 at gmail.com Sun May 16 23:50:05 2010 From: rutski89 at gmail.com (Patrick Rutkowski) Date: Sun, 16 May 2010 17:50:05 -0400 Subject: gnutls_priority_set() -- default value? Message-ID: Is it necessary to call gnutls_priority_set() if all you're going to do is set the priority to "NORMAL" anyway? Is there a default priority that a session takes on? -Patrick P.S. I just learned about GnuTLS after several months of suffering with OpenSSL; it's so much better documented, it's just a dream :-) From nmav at gnutls.org Tue May 18 13:52:12 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 May 2010 13:52:12 +0200 Subject: gnutls_priority_set() -- default value? In-Reply-To: References: Message-ID: <4BF27F6C.4080406@gnutls.org> Patrick Rutkowski wrote: > Is it necessary to call gnutls_priority_set() if all you're going to do is set the priority to "NORMAL" anyway? > Is there a default priority that a session takes on? No, unfortunately you have to set a priority string even if it is "NORMAL". regards, Nikos From rutski89 at gmail.com Tue May 18 13:53:24 2010 From: rutski89 at gmail.com (Patrick Rutkowski) Date: Tue, 18 May 2010 07:53:24 -0400 Subject: gnutls_priority_set() -- default value? In-Reply-To: <4BF27F6C.4080406@gnutls.org> References: <4BF27F6C.4080406@gnutls.org> Message-ID: Ah, well, at least that forces you to be aware of it :-) I wonder what happens if you don't set it? Crash? I'll have to test that sometime. -Patrick On May 18, 2010, at 7:52 AM, Nikos Mavrogiannopoulos wrote: > Patrick Rutkowski wrote: >> Is it necessary to call gnutls_priority_set() if all you're going to do is set the priority to "NORMAL" anyway? >> Is there a default priority that a session takes on? > > No, unfortunately you have to set a priority string even if it is "NORMAL". > > > regards, > Nikos From nmav at gnutls.org Tue May 18 14:28:17 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 May 2010 14:28:17 +0200 Subject: gnutls_priority_set() -- default value? In-Reply-To: References: <4BF27F6C.4080406@gnutls.org> Message-ID: <4BF287E1.9000706@gnutls.org> Patrick Rutkowski wrote: > Ah, well, at least that forces you to be aware of it :-) > > I wonder what happens if you don't set it? Crash? > I'll have to test that sometime. The handshake fails but no creash :) regards, Nikos From rutski89 at gmail.com Tue May 18 14:28:47 2010 From: rutski89 at gmail.com (Patrick Rutkowski) Date: Tue, 18 May 2010 08:28:47 -0400 Subject: gnutls_priority_set() -- default value? In-Reply-To: <4BF287E1.9000706@gnutls.org> References: <4BF27F6C.4080406@gnutls.org> <4BF287E1.9000706@gnutls.org> Message-ID: Ah, neat. Good :) On May 18, 2010, at 8:28 AM, Nikos Mavrogiannopoulos wrote: > Patrick Rutkowski wrote: >> Ah, well, at least that forces you to be aware of it :-) >> >> I wonder what happens if you don't set it? Crash? >> I'll have to test that sometime. > > The handshake fails but no creash :) > > regards, > Nikos > From simon at josefsson.org Wed May 26 16:28:18 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 26 May 2010 16:28:18 +0200 Subject: GNU_TLS Support In-Reply-To: (Joel Hart's message of "Wed, 26 May 2010 08:22:00 -0600") References: Message-ID: <87ocg2rb3x.fsf@mocca.josefsson.org> Joel Hart writes: > Hi, > > I'm located in Colorado, USA. I am having a hell of a time installing a certificate from godaddy using GNU_TLS. It appears my apache mod is working perfectly, but my issue is godaddy has the cert, the key, and a chain file. I can combine the cert and key into a .pem file, but I can't figure out how to use a GNU_TLS directive to include the chain file and I'm getting this error when I restart Apache: > > GnuTLS: Failed to Import Private Key '/opt/bitnami/certs/dae/dae.key': (-207) Base64 unexpected header error. > apache config test fails, aborting > > Can you set me in the right direction? Make sure to remove any whitespace, see this bug report (which hasn't been fixed yet unfortunately): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579631 /Simon From carolin.latze at unifr.ch Fri May 28 17:20:02 2010 From: carolin.latze at unifr.ch (LATZE Carolin) Date: Fri, 28 May 2010 17:20:02 +0200 Subject: how to send arbitrary data in supplemental data message Message-ID: Hi everybody, I ran again into problems with the supplemental data messages. I tried to copy a certificate into the buffer of type gnutls_buffer and do not manage to send all 1314 bytes of the certificate. Instead it sends only 41 bytes. I tried it with another certificate which resulted in 65 bytes sent. This is pretty strange. I expected the buffer to stop at a \0 character in the signature, but that does not seem to be the case since strlen of the original data results in the correct length of 1314. Any ideas? In order to simplify debugging, I copied my gnutls version including the tls-tpm extension (not finished yet, but does not cause crashes :-)) onto a server: http://diuf.unifr.ch/people/latzec/gnutls-CL-28052010.tar.gz Furthermore, I uploaded my little sample program as well: http://diuf.unifr.ch/people/latzec/sample.tar.gz I would be happy for any hints or ideas since I am clueless at the moment. Carolin From bortzmeyer at nic.fr Sat May 29 23:37:48 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 29 May 2010 23:37:48 +0200 Subject: GnuTLS considered harmful Message-ID: <20100529213748.GA18424@sources.org> As far as I know, this rant has never been discussed here: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html [...] I strongly recommend that GnuTLS not be used. All of its APIs would need to be overhauled to correct its flaws [...] From nmav at gnutls.org Sun May 30 11:54:34 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 30 May 2010 11:54:34 +0200 Subject: GnuTLS considered harmful In-Reply-To: <20100529213748.GA18424@sources.org> References: <20100529213748.GA18424@sources.org> Message-ID: <4C0235DA.2090001@gnutls.org> Stephane Bortzmeyer wrote: > As far as I know, this rant has never been discussed here: > > http://www.openldap.org/lists/openldap-devel/200802/msg00072.html > > [...] I strongly recommend that GnuTLS not be used. All of its APIs > would need to be overhauled to correct its flaws [...] It's a rant. As far as I remember he was referring to a single function that had an issue in gnutls and generalized it. His generalized claims were not true back then and are not true now. His claim about the given function was true and was fixed in later versions. I believe he got confused by the ASN.1 library API that uses strings to refer to positions on the PKIX1 schema, such as "PKIX1.GeneralTime". For those fixed size strings we use string functions, and this might confuse someone just doing grep on the code and not familiar with the api. regards, Nikos From nmav at gnutls.org Sun May 30 13:05:57 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 30 May 2010 13:05:57 +0200 Subject: how to send arbitrary data in supplemental data message In-Reply-To: References: Message-ID: <4C024695.4090809@gnutls.org> LATZE Carolin wrote: > Hi everybody, > > I ran again into problems with the supplemental data messages. I tried to copy a certificate into the buffer of type gnutls_buffer and do not manage to send all 1314 bytes of the certificate. Instead it sends only 41 bytes. I tried it with another certificate which resulted in 65 bytes sent. This is pretty strange. I expected the buffer to stop at a \0 character in the signature, but that does not seem to be the case since strlen of the original data results in the correct length of 1314. Any ideas? > > In order to simplify debugging, I copied my gnutls version including the tls-tpm extension (not finished yet, but does not cause crashes :-)) onto a server: > http://diuf.unifr.ch/people/latzec/gnutls-CL-28052010.tar.gz > > Furthermore, I uploaded my little sample program as well: > http://diuf.unifr.ch/people/latzec/sample.tar.gz > > I would be happy for any hints or ideas since I am clueless at the moment. Could you use debugging output with gnutls_global_set_log_function (tls_log_func); gnutls_global_set_log_level (level); ? Level 2 should be sufficient. regards, Nikos From dev.admin at ntlworld.com Mon May 31 01:27:25 2010 From: dev.admin at ntlworld.com (dev.admin at ntlworld.com) Date: Mon, 31 May 2010 00:27:25 +0100 Subject: [2.8.6] build time symbol not found error. Message-ID: Hey, I feel a bit of a noob but I can't seem to get the current or previous versions to build. I did read the README and tried the suggested flags but I still get the same problem. I'm building it as a static. A. output from make. --------------- * Making all in x509 libtool: link: gcc -std=gnu99 -arch x86_64 -g -Os -pipe -no-cpp- precomp -arch x86_64 -bind_at_load -o errcodes errcodes.o ../ lib/.libs/libgnutls.a -L/usr/local/gnu/lib.a/lib /usr/local/gnu/lib.a/ lib/libtasn1.a -lz /usr/local/gnu/lib.a/lib/libgcrypt.a -L/usr/local/ gnu/lib/lib /usr/local/gnu/lib.a/lib/libgpg-error.a /usr/local/gnu/lib/ lib/libintl.dylib /usr/local/gnu/lib/lib/libiconv.dylib -lc ../ gl/.libs/libgnu.a Undefined symbols: "__gnutls_log_func", referenced from: __gnutls_log in libgnutls.a(gnutls_errors.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[4]: *** [errcodes] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carolin.latze at unifr.ch Mon May 31 17:15:12 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Mon, 31 May 2010 17:15:12 +0200 Subject: how to send arbitrary data in supplemental data message In-Reply-To: <4C024695.4090809@gnutls.org> References: <4C024695.4090809@gnutls.org> Message-ID: <4C03D280.7020203@unifr.ch> Hi Nikos, On 05/30/2010 01:05 PM, Nikos Mavrogiannopoulos wrote: > LATZE Carolin wrote: > >> Hi everybody, >> >> I ran again into problems with the supplemental data messages. I tried to copy a certificate into the buffer of type gnutls_buffer and do not manage to send all 1314 bytes of the certificate. Instead it sends only 41 bytes. I tried it with another certificate which resulted in 65 bytes sent. This is pretty strange. I expected the buffer to stop at a \0 character in the signature, but that does not seem to be the case since strlen of the original data results in the correct length of 1314. Any ideas? >> >> In order to simplify debugging, I copied my gnutls version including the tls-tpm extension (not finished yet, but does not cause crashes :-)) onto a server: >> http://diuf.unifr.ch/people/latzec/gnutls-CL-28052010.tar.gz >> >> Furthermore, I uploaded my little sample program as well: >> http://diuf.unifr.ch/people/latzec/sample.tar.gz >> >> I would be happy for any hints or ideas since I am clueless at the moment. >> > Could you use debugging output with > gnutls_global_set_log_function (tls_log_func); > gnutls_global_set_log_level (level); > ? > > Oh sorry, I did that already (with level 3), but forgot to add the file. You find it here: http://diuf.unifr.ch/people/latzec/out Thats the output of the client who is supposed to send the supplemental data. Carolin > Level 2 should be sufficient. > > regards, > Nikos > > > > From nmav at gnutls.org Mon May 31 17:43:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 31 May 2010 17:43:33 +0200 Subject: how to send arbitrary data in supplemental data message In-Reply-To: <4C03D280.7020203@unifr.ch> References: <4C024695.4090809@gnutls.org> <4C03D280.7020203@unifr.ch> Message-ID: <4C03D925.70200@gnutls.org> Carolin Latze wrote: Here is the trouble maker: _gnutls_buffer_append(buf, session->security_parameters.extensions.aik_sent->data, (uint8_t) session->security_parameters.extensions.aik_sent->size); Remove the cast (uint8_t) to solve the issue. You're are effectively doing a (mod 256) to the data size. regards, Nikos > Hi Nikos, > > On 05/30/2010 01:05 PM, Nikos Mavrogiannopoulos wrote: >> LATZE Carolin wrote: >> >>> Hi everybody, >>> >>> I ran again into problems with the supplemental data messages. I >>> tried to copy a certificate into the buffer of type gnutls_buffer and >>> do not manage to send all 1314 bytes of the certificate. Instead it >>> sends only 41 bytes. I tried it with another certificate which >>> resulted in 65 bytes sent. This is pretty strange. I expected the >>> buffer to stop at a \0 character in the signature, but that does not >>> seem to be the case since strlen of the original data results in the >>> correct length of 1314. Any ideas? >>> >>> In order to simplify debugging, I copied my gnutls version including >>> the tls-tpm extension (not finished yet, but does not cause crashes >>> :-)) onto a server: >>> http://diuf.unifr.ch/people/latzec/gnutls-CL-28052010.tar.gz >>> >>> Furthermore, I uploaded my little sample program as well: >>> http://diuf.unifr.ch/people/latzec/sample.tar.gz >>> >>> I would be happy for any hints or ideas since I am clueless at the >>> moment. >>> >> Could you use debugging output with >> gnutls_global_set_log_function (tls_log_func); >> gnutls_global_set_log_level (level); >> ? >> >> > Oh sorry, I did that already (with level 3), but forgot to add the file. > You find it here: > > http://diuf.unifr.ch/people/latzec/out > > Thats the output of the client who is supposed to send the supplemental > data. > > Carolin > >> Level 2 should be sufficient. >> >> regards, >> Nikos >> >> >> >> > From simon at josefsson.org Mon May 31 20:28:13 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 May 2010 20:28:13 +0200 Subject: [2.8.6] build time symbol not found error. In-Reply-To: (dev admin's message of "Mon, 31 May 2010 00:27:25 +0100") References: Message-ID: <87mxvghqo2.fsf@mocca.josefsson.org> dev.admin at ntlworld.com writes: > Hey, > > I feel a bit of a noob but I can't seem to get the > current or previous versions to build. > > I did read the README and tried the suggested > flags but I still get the same problem. > > I'm building it as a static. What platform is this? I'm able to build a static GnuTLS (./configure --enable-static --disable-shared) fine on a Debian x86 machine. The _gnutls_log_func variable is defined in gnutls_global.c and there is a prototype for it in gnutls_global.h, which gnutls_errors.c includes (via gnutls_errors.h). So I don't understand why linking fails. /Simon > output from make. > --------------- > * > Making all in x509 > libtool: link: gcc -std=gnu99 -arch x86_64 -g -Os -pipe -no-cpp- > precomp -arch x86_64 -bind_at_load -o errcodes errcodes.o ../ > lib/.libs/libgnutls.a -L/usr/local/gnu/lib.a/lib /usr/local/gnu/lib.a/ > lib/libtasn1.a -lz /usr/local/gnu/lib.a/lib/libgcrypt.a -L/usr/local/ > gnu/lib/lib /usr/local/gnu/lib.a/lib/libgpg-error.a > /usr/local/gnu/lib/ > lib/libintl.dylib /usr/local/gnu/lib/lib/libiconv.dylib -lc ../ > gl/.libs/libgnu.a > Undefined symbols: > "__gnutls_log_func", referenced from: > __gnutls_log in libgnutls.a(gnutls_errors.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[4]: *** [errcodes] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From simon at josefsson.org Mon May 31 20:37:02 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 May 2010 20:37:02 +0200 Subject: GnuTLS considered harmful In-Reply-To: <20100529213748.GA18424@sources.org> (Stephane Bortzmeyer's message of "Sat, 29 May 2010 23:37:48 +0200") References: <20100529213748.GA18424@sources.org> Message-ID: <87iq63j4tt.fsf@mocca.josefsson.org> Stephane Bortzmeyer writes: > As far as I know, this rant has never been discussed here: > > http://www.openldap.org/lists/openldap-devel/200802/msg00072.html > > [...] I strongly recommend that GnuTLS not be used. All of its APIs > would need to be overhauled to correct its flaws [...] The gnutls_x509_crt_set_subject_alt_name function has been added which can handle binary structures like packed IP addresses. Non-domain SANs doesn't seem to be widely used though; I haven't been able to get a IP address SAN through any commercial CA. From a systems perspective, I'm not sure the complexity introduced by this outweigh the benefit, but hey, at least we now support it. I have no idea what other APIs he is referring to -- all relevant APIs should take opaque buffer pointers plus buffer size. I also have no idea what APIs he think is problematic wrt strlen/strcat. I would expect that if strlen is used on binary data things would break quickly and we'd notice. Essentially, we have corrected the substantial part, and we'd be happy to improve anything else if the rant is converted into a substantial report about missing or incorrect functionality. /Simon