From ekarttun at cs.helsinki.fi Mon Aug 1 15:08:33 2005 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Mon, 01 Aug 2005 16:08:33 +0300 Subject: [Help-gnutls] Order of freing various structures Message-ID: <87br4hhkj2.fsf@yui.aoinet> Hello I am writing a wrapper of GnuTLS in Haskell and the order of freing structures seems quite important. Is one allowed to first free credentials and then deinit a session they were associated with? Or must the credentials be valid when deinit is called on the session? i.e. is the following sequence legal: gnutls_credentials_set(session, cred, ...); gnutls__credentials_free(cred); gnutls_deinit(session); or must deinit allways be called first? May they be called concurrently if gcry_control has been properly initialized for multithreaded operation? - Einar Karttunen From nmav at gnutls.org Mon Aug 1 21:05:12 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 01 Aug 2005 21:05:12 +0200 Subject: [Help-gnutls] Order of freing various structures In-Reply-To: <87br4hhkj2.fsf@yui.aoinet> References: <87br4hhkj2.fsf@yui.aoinet> Message-ID: <42EE7268.1070906@gnutls.org> Einar Karttunen wrote: > Hello > I am writing a wrapper of GnuTLS in Haskell and the order of freing > structures seems quite important. Is one allowed to first free > credentials and then deinit a session they were associated with? Or > must the credentials be valid when deinit is called on the session? Hi, Actually not since they are not used at that point. However you cannot use a session after the credentials are freed. regards, Nikos From jas at extundo.com Wed Aug 3 17:15:28 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 03 Aug 2005 17:15:28 +0200 Subject: [Help-gnutls] Re: Order of freing various structures In-Reply-To: <87br4hhkj2.fsf@yui.aoinet> (Einar Karttunen's message of "Mon, 01 Aug 2005 16:08:33 +0300") References: <87br4hhkj2.fsf@yui.aoinet> Message-ID: Einar Karttunen writes: > Hello > > I am writing a wrapper of GnuTLS in Haskell Hello Einar. Wonderful, Haskell is my favorite functional language. :) Do you have an URL for your project? I may add it to gnutls.org, if you want. > and the order of freing > structures seems quite important. Is one allowed to first free > credentials and then deinit a session they were associated with? Or > must the credentials be valid when deinit is called on the session? > > i.e. is the following sequence legal: > gnutls_credentials_set(session, cred, ...); > gnutls__credentials_free(cred); > gnutls_deinit(session); It is OK assuming nothing happens between the credentials_free and deinit call, however, if something happens in the session that require access to the certificates (e.g., a re-handshake initiated by the other side?), things will break. I recommend to free the credentials after the session in which they are used is completely finished and deallocated. It is a better separation of things. > or must deinit allways be called first? Not necessarily. > May they be called concurrently > if gcry_control has been properly initialized for multithreaded operation? Currently yes, but I could only tell by looking at the code. The gnutls_deinit function doesn't access the certificates. If you have suggestions how to better document this to explain things better, please share. Regards, Simon From e_agf at yahoo.es Mon Aug 8 13:39:54 2005 From: e_agf at yahoo.es (Fran) Date: Mon, 08 Aug 2005 13:39:54 +0200 Subject: [Help-gnutls] Really I can not understand nothing of SSL... Message-ID: <1123501195.3307.6.camel@localhost> Hello, Why certtool request for a int number for serial?, if I think that should be >= unsigned long long (64 bit): > int size, serial, client; > > serial = get_serial(); > > int get_serial(void) > { > if (batch) { > if (cfg.serial < 0) > return 0; > return cfg.serial; > } else { > return > read_int("Enter the certificate's serial number (decimal): "); > } > } > > serial = get_serial(); > buffer[3] = serial & 0xff; > buffer[2] = (serial >> 8) & 0xff; > buffer[1] = (serial >> 16) & 0xff; > buffer[0] = 0; > > result = gnutls_x509_crt_set_serial(crt, buffer, 4); > if (result < 0) { > fprintf(stderr, "serial: %s\n", gnutls_strerror(result)); > exit(1); > } > From jas at extundo.com Mon Aug 8 14:34:04 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 08 Aug 2005 14:34:04 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: <1123501195.3307.6.camel@localhost> (Fran's message of "Mon, 08 Aug 2005 13:39:54 +0200") References: <1123501195.3307.6.camel@localhost> Message-ID: Fran writes: > Hello, > Why certtool request for a int number for serial?, if I think that > should be >= unsigned long long (64 bit): Hello. 'Unsigned long long' is a non-standard C extension, is it not? We want the code to work with standard compilers. Further, it seems serial's should be allowed to be even longer than 64/128 bits, so I believe the proper solution is to make get_serial support a hex string format too (perhaps recognized through a prefix of '0x'?). If this is important for you, please propose a patch for inclusion. Thanks, Simon > >> int size, serial, client; >> >> serial = get_serial(); >> >> int get_serial(void) >> { >> if (batch) { >> if (cfg.serial < 0) >> return 0; >> return cfg.serial; >> } else { >> return >> read_int("Enter the certificate's serial number (decimal): "); >> } >> } >> >> serial = get_serial(); >> buffer[3] = serial & 0xff; >> buffer[2] = (serial >> 8) & 0xff; >> buffer[1] = (serial >> 16) & 0xff; >> buffer[0] = 0; >> >> result = gnutls_x509_crt_set_serial(crt, buffer, 4); >> if (result < 0) { >> fprintf(stderr, "serial: %s\n", gnutls_strerror(result)); >> exit(1); >> } >> From asuffield at suffields.me.uk Mon Aug 8 15:17:24 2005 From: asuffield at suffields.me.uk (Andrew Suffield) Date: Mon, 8 Aug 2005 14:17:24 +0100 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: References: <1123501195.3307.6.camel@localhost> Message-ID: <20050808131724.GA4415@suffields.me.uk> On Mon, Aug 08, 2005 at 02:34:04PM +0200, Simon Josefsson wrote: > > Why certtool request for a int number for serial?, if I think that > > should be >= unsigned long long (64 bit): > > Hello. 'Unsigned long long' is a non-standard C extension, is it not? > We want the code to work with standard compilers. No, it's C99. If you'd rather have POSIX, use uint64_t. -- .''`. ** 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 jas at extundo.com Mon Aug 8 15:41:24 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 08 Aug 2005 15:41:24 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: <20050808131724.GA4415@suffields.me.uk> (Andrew Suffield's message of "Mon, 8 Aug 2005 14:17:24 +0100") References: <1123501195.3307.6.camel@localhost> <20050808131724.GA4415@suffields.me.uk> Message-ID: Andrew Suffield writes: > On Mon, Aug 08, 2005 at 02:34:04PM +0200, Simon Josefsson wrote: >> > Why certtool request for a int number for serial?, if I think that >> > should be >= unsigned long long (64 bit): >> >> Hello. 'Unsigned long long' is a non-standard C extension, is it not? >> We want the code to work with standard compilers. > > No, it's C99. If you'd rather have POSIX, use uint64_t. I believe the goal is for GnuTLS to work on C89 platforms. 'long long' isn't used by GnuTLS today. Further, according to: http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html uint64_t is not required by POSIX, it is optional. uint64_t is also not used by GnuTLS today. So I don't think neither is a good solution here. X.509 serials are frequently larger than 64 and even 128 bits, so the real solution would be to make get_serial return a hex string instead. Then we won't have arbitrary limits, be them 32, 64 or 128 bits. Fixing that look rather simple; patches welcome. Regards, Simon From e_agf at yahoo.es Tue Aug 9 00:44:27 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 09 Aug 2005 00:44:27 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... Message-ID: <1123541068.3982.19.camel@localhost> I am not a hacker of gnutls, I'm not a hacker of unix, I'm not a hacker of C What need a stupid programmer like me here? It's easy: - Extract the visible parameters, like serial, CN, Issuer, etc... (real world) Why? Common name and serial identify a certificate ->> Identify an user. Which is the problem?, if I make a struct to store visible parameters, I do not known sizeof(serial). Could be store in hexadecimal number, but hexadecimal number is very difficult to manage. (The limit is in the sky) > gnutls_x509_crt_get_serial (cert, serial, &serial_size) >= 0) Isn't hexadecimal, decimal. 1,844674407 E19 /* puuufff */ X509_useful.serial = strtoll (raw_to_string (serial, serial_size), NULL, 10); /* bug, bug,bug, if expected size > 2^64 */ > >Why certtool request for a int number for serial?, if I think that >should be >= unsigned long long (64 bit): > Hello. 'Unsigned long long' is a non-standard C extension, is it not? ? > We want the code to work with standard compilers. Yes "int" can be -1,..., tralala, tralala,0,..., I think that from "int" you can not use a number larger that 2^32 (u int). how to extract number larger than "int"? > >> int size, serial, client; > >> > >> serial = get_serial(); > >> > >> "int" get_serial(void) > >> { > >> if (batch) { > >> if (cfg.serial < 0) > >> return 0; > >> return cfg.serial; > >> } else { > >> return > >> read_int("Enter the certificate's serial number > (decimal): "); > >> } > >> } > > I believe the proper solution is to make get_serial > support a hex string format too (perhaps recognized through a >prefix of '0x'?). Ok, get_serial should support a hex string or decimal bigger number. >If this is important for you, please propose a patch for > inclusion. Time ago I sent you some ideas, about other things >> trash. > get_serial return a hex string instead. > Then we won't have arbitrary limits, be them 32, 64 or 128 bits. > Fixing that look rather simple; patches welcome. I can not help you, sorry. who have certificates? >How much time a certificate could be valid, 1 year,two year, >100year :) >How much users can be CA certificate ?9E9?, 0ne certificate per hour >for each user: >8760 hours per year >7.884E13 crt per year >2^64 / 7.884E13 = 233976.9669 years. >In my opinion when serial >= limit should be reset to another CA >name .(my opinion >> trash). >Support Verisig.n enterprise ....... years? The problem is easy "manage and store certificate information" (user level). Here is the problem: -compatibility (all systems) or -efficiency How to solve the problem? Put a config flag, verify all times if serial < 64 bits, transform every time to hexadecimal number, or functions should return hexadecimal? Thanks, for your time; sorry for my English. On Lun, 2005-08-08 at 15:41 +0200, Simon Josefsson wrote: > Andrew Suffield writes: > > > On Mon, Aug 08, 2005 at 02:34:04PM +0200, Simon Josefsson wrote: > >> > Why certtool request for a int number for serial?, if I think that > >> > should be >= unsigned long long (64 bit): > >> > >> Hello. 'Unsigned long long' is a non-standard C extension, is it not? > >> We want the code to work with standard compilers. > > > > No, it's C99. If you'd rather have POSIX, use uint64_t. > > I believe the goal is for GnuTLS to work on C89 platforms. 'long > long' isn't used by GnuTLS today. Further, according to: > > http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html > > uint64_t is not required by POSIX, it is optional. uint64_t is also > not used by GnuTLS today. So I don't think neither is a good solution > here. > > X.509 serials are frequently larger than 64 and even 128 bits, so the > real solution would be to make get_serial return a hex string instead. > Then we won't have arbitrary limits, be them 32, 64 or 128 bits. > Fixing that look rather simple; patches welcome. > > Regards, > Simon > > > _______________________________________________ > Help-gnutls mailing list > From jas at extundo.com Tue Aug 9 13:13:19 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 09 Aug 2005 13:13:19 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: <1123541068.3982.19.camel@localhost> (Fran's message of "Tue, 09 Aug 2005 00:44:27 +0200") References: <1123541068.3982.19.camel@localhost> Message-ID: Fran writes: > What need a stupid programmer like me here? > It's easy: > - Extract the visible parameters, like serial, CN, Issuer, etc... (real > world) > Why? > Common name and serial identify a certificate ->> Identify an user. > > Which is the problem?, if I make a struct to store visible parameters, I > do not known sizeof(serial). Could be store in hexadecimal number, but > hexadecimal number is very difficult to manage. (The limit is in the > sky) There are many options, but the most flexible is probably to use a real bignum library. There is one in libgcrypt, which GnuTLS uses. >> gnutls_x509_crt_get_serial (cert, serial, &serial_size) >= 0) > > Isn't hexadecimal, decimal. > > 1,844674407 E19 /* puuufff */ > X509_useful.serial = strtoll (raw_to_string (serial, serial_size), NULL, > 10); /* bug, bug,bug, if expected size > 2^64 */ Right, strtoll will only work for small integers. >>If this is important for you, please propose a patch for >> inclusion. > > Time ago I sent you some ideas, about other things >> trash. If I don't have time to implement ideas, I try to write them down into TODO. Are your ideas in there? Code, on the other hand, doesn't write itself... Cheers, Simon From e_agf at yahoo.es Tue Aug 9 17:50:37 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 09 Aug 2005 17:50:37 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: References: <1123541068.3982.19.camel@localhost> Message-ID: <1123602637.3199.35.camel@localhost> > There are many options, but the most flexible is probably to use a > real bignum library. There is one in libgcrypt, which GnuTLS uses. Thanks, seems good choice; but I think (in my opinion) that serial number should be unique (not int here and BIGNUM there). > Right, strtoll will only work for small integers. Right > If I don't have time to implement ideas, I try to write them down into > TODO. Are your ideas in there? Code, on the other hand, doesn't > write itself... Ideas = tar.gz archive with C code (as well I can). Skeleton of interface + Makefile for examples/doc Another thing, in 1.2.4 one certificate dn_size for gnutls_x509_crt_get_dn -> 111 bytes gnutls_x509_crt_get_issuer_dn -> 98 bytes now, the same certificate, in 1.2.6 - 110 bytes and 97bytes ?It is ok? And I can not copy (I can print it) issuer_dn with strncpy, snprintf or memcpy (segfault), only with (dn_size - 40); store size 256 > 97 ?returned size is correct?, seems to be bigger. > dn_size = sizeof (dn); > ret = gnutls_x509_crt_get_dn (cert, dn, &dn_size); > if (ret >= 0) > { > ..."Saving to Useful:sizeof store %u, %s (%u bytes)", sizeof(X509_useful.issuer_client),dn, dn_size); > snprintf (X509_useful.issuer_client, 254, "%s", dn); /*Work ok*/ > ..."Printing; %s (%u bytes)", dn, dn_size); > > ..."Subject: %s", X509_useful.issuer_client); > } > else > { > ..."get_dn: %s", gnutls_strerror (ret)); > }; > /* Issuer > */ > ret = gnutls_x509_crt_get_issuer_dn (cert, dn, &dn_size); > if (ret >= 0) > { > ..."Saving to Useful: sizeof store %u, %s (%u bytes) to copy %u", sizeof(r->X509_useful.issuer_ca),dn, d > /*snprintf ()*/ > /* strncpy (r->X509_useful.issuer_ca, dn, dn_size - 10 );*/ > memcpy (r->X509_useful.issuer_ca, dn, dn_size - 10 );/*Do not work*/ > ..."Printing; %s (%u bytes) to copy %u", dn, dn_size, dn_size - 10 ); > ..."Issuer: %s", X509_useful.issuer_ca); > } > else > { > ..."get_issuer_dn: %s", gnutls_strerror (ret)); > }; > ------------------ > if (cbuf == NULL) > *sizeof_buf = 0; > > > len = *sizeof_buf; > result = > asn1_read_value(asn1_struct, tmpbuffer3, buf, &len);<------------ > > if (result != ASN1_SUCCESS) { > gnutls_assert(); > if (result==ASN1_MEM_ERROR) > ------->*sizeof_buf = len; > result = _gnutls_asn2err(result); > goto cleanup; > } > > if (raw_flag != 0) { > if ((uint) len > *sizeof_buf) { > -----> *sizeof_buf = len; > result = GNUTLS_E_SHORT_MEMORY_BUFFER; > goto cleanup; > } > -------->*sizeof_buf = len; > > return 0; > > } else { /* parse data. raw_flag == 0 */ > printable = _gnutls_x509_oid_data_printable(oid); > if (printable == 1) > result = > _gnutls_x509_oid_data2string(oid, buf, len, > cbuf, sizeof_buf); > else > result = > _gnutls_x509_data2hex(buf, len, cbuf, > sizeof_buf); > > if (result < 0) { > gnutls_assert(); > goto cleanup; > } > > return 0; > Regards, From e_agf at yahoo.es Tue Aug 9 23:27:27 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 09 Aug 2005 23:27:27 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: <1123602637.3199.35.camel@localhost> References: <1123541068.3982.19.camel@localhost> <1123602637.3199.35.camel@localhost> Message-ID: <1123622847.8304.10.camel@localhost> Do not read my last message all is false. Hey, I wrote the last message too fast. Sorry (This is not spam) > Another thing, in 1.2.4 one certificate dn_size for > gnutls_x509_crt_get_dn -> 111 bytes > gnutls_x509_crt_get_issuer_dn -> 98 bytes > now, the same certificate, in 1.2.6 > - 110 bytes and 97bytes > ?It is ok? No, no, isn?t true > And I can not copy (I can print it) issuer_dn with strncpy, snprintf or > memcpy (segfault), only with (dn_size - 40); store size 256 > 97 > ?returned size is correct?, seems to be bigger. Is not a gnutls problem; (really I do not where is the problem same size of store a,b and store in a work in b not- I think that is a red demon :) ) Sorry again, Regards, F. J. From jas at extundo.com Wed Aug 10 11:15:12 2005 From: jas at extundo.com (Simon Josefsson) Date: Wed, 10 Aug 2005 11:15:12 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... In-Reply-To: <1123602637.3199.35.camel@localhost> (Fran's message of "Tue, 09 Aug 2005 17:50:37 +0200") References: <1123541068.3982.19.camel@localhost> <1123602637.3199.35.camel@localhost> Message-ID: Fran writes: >> There are many options, but the most flexible is probably to use a >> real bignum library. There is one in libgcrypt, which GnuTLS uses. > Thanks, seems good choice; but I think (in my opinion) that serial > number should be unique (not int here and BIGNUM there). Agreed, but the GnuTLS API never uses int for X.509 serials. The tool does, but it has to convert it to a printable format somehow. Arguable it should use libgcrypt.. >> Right, strtoll will only work for small integers. > Right >> If I don't have time to implement ideas, I try to write them down into >> TODO. Are your ideas in there? Code, on the other hand, doesn't >> write itself... > Ideas = tar.gz archive with C code (as well I can). Skeleton of interface + Makefile for examples/doc I fixed the examples now, they should be built during a normal build, so any problems should be spotted easily. I don't recall the other matters, do you have a message-id or something? > Another thing, in 1.2.4 one certificate dn_size for > gnutls_x509_crt_get_dn -> 111 bytes > gnutls_x509_crt_get_issuer_dn -> 98 bytes > now, the same certificate, in 1.2.6 > - 110 bytes and 97bytes > ?It is ok? Yes, see NEWS: - Fixed off-by-one bug in the size parameter of gnutls_x509_crt_get*_dn, reported by Adam Langley . Cheers, Simon From mario.lists at gmail.com Thu Aug 11 04:10:57 2005 From: mario.lists at gmail.com (Mario Fuentes) Date: Wed, 10 Aug 2005 22:10:57 -0400 Subject: [Help-gnutls] Asynchronous Connections Message-ID: Hello! I'm working on the support of secure connections in Gyrus, a Cyrus IMAPd administrator. Reading the GNUtls documentation I don't found information about Asynchronous connections, I will be very happy if any can help me :> Sorry my precary english. Mario From jas at extundo.com Thu Aug 11 11:16:18 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 11 Aug 2005 11:16:18 +0200 Subject: [Help-gnutls] Re: Asynchronous Connections In-Reply-To: (Mario Fuentes's message of "Wed, 10 Aug 2005 22:10:57 -0400") References: Message-ID: Mario Fuentes writes: > Hello! > > I'm working on the support of secure connections in Gyrus, a Cyrus > IMAPd administrator. Reading the GNUtls documentation I don't found > information about Asynchronous connections, I will be very happy if > any can help me :> Hi! Exactly what do you mean? Non-hanging read/write? The standard select() mechanism should work. Perhaps you can explain more what you want to do. Cheers, Simon From mario.lists at gmail.com Thu Aug 11 17:32:52 2005 From: mario.lists at gmail.com (Mario Fuentes) Date: Thu, 11 Aug 2005 11:32:52 -0400 Subject: [Help-gnutls] Re: Re: Asynchronous Connections In-Reply-To: References: Message-ID: Hola :) ! 2005/8/11, Simon Josefsson : > Mario Fuentes writes: > > > Hello! > > > > I'm working on the support of secure connections in Gyrus, a Cyrus > > IMAPd administrator. Reading the GNUtls documentation I don't found > > information about Asynchronous connections, I will be very happy if > > any can help me :> > > Hi! Exactly what do you mean? Non-hanging read/write? The standard > select() mechanism should work. Perhaps you can explain more what you > want to do. > > Cheers, > Simon > Gyrus uses the GNET library for the comunication, it provide a function to create a connection with a callback called when the transmision finish. We uses this because Gyrus can manage multi-sessions and the GUI not will can freeze. In the GNUtls documentation/examples the functions gnu_record_[send|recv] are used to send/recv data in the channel... I'm confused ?:| Sorry my newbie confusion :( bye, Mario From cascardo at minaslivre.org Thu Aug 11 17:58:52 2005 From: cascardo at minaslivre.org (cascardo at minaslivre.org) Date: Thu, 11 Aug 2005 12:58:52 -0300 Subject: [Help-gnutls] Re: Re: Asynchronous Connections In-Reply-To: References: Message-ID: <20050811155851.GW8010@cascardo.localdomain> I also use GNET in my libtc library. I have some special modules for the connection. Check the libconn directory in the package. It's available on jabberstudio.org. If you wish, I may send only the required files to you in private mail. The files are licensed under LGPL. Regards, Thadeu Cascardo. On Thu, Aug 11, 2005 at 11:32:52AM -0400, Mario Fuentes wrote: > Hola :) ! > > 2005/8/11, Simon Josefsson : > > Mario Fuentes writes: > > > > > Hello! > > > > > > I'm working on the support of secure connections in Gyrus, a Cyrus > > > IMAPd administrator. Reading the GNUtls documentation I don't found > > > information about Asynchronous connections, I will be very happy if > > > any can help me :> > > > > Hi! Exactly what do you mean? Non-hanging read/write? The standard > > select() mechanism should work. Perhaps you can explain more what you > > want to do. > > > > Cheers, > > Simon > > > > Gyrus uses the GNET library for the comunication, it provide a > function to create a connection with a callback called when the > transmision finish. We uses this because Gyrus can manage > multi-sessions and the GUI not will can freeze. > > In the GNUtls documentation/examples the functions > gnu_record_[send|recv] are used to send/recv data in the channel... > I'm confused ?:| > > Sorry my newbie confusion :( > > bye, > Mario > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From e_agf at yahoo.es Fri Aug 12 21:14:41 2005 From: e_agf at yahoo.es (Fran) Date: Fri, 12 Aug 2005 21:14:41 +0200 Subject: [Help-gnutls] Re: Really I can not understand nothing of SSL... For the moment to avoid confusion... Message-ID: <1123874082.10421.25.camel@localhost> Fran