From nmav at gnutls.org Sat Aug 2 10:20:35 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Aug 2008 11:20:35 +0300 Subject: [Help-gnutls] TLS and SCTP In-Reply-To: <48903343.9040101@nict.go.jp> References: <48903343.9040101@nict.go.jp> Message-ID: <489418D3.5090203@gnutls.org> Sebastien Decugis wrote: > Hello, > > I am trying to implement TLS over a SCTP association with multiple > streams (the final goal is to make an open-source implementation of > Diameter). I'm not familiar with SCTP but I'll try to reply. > I understand how to specify my own transport-layer handlers in GNU TLS > with the set_push_function and set_pull_function, but I think it is not > sufficient support to handle the TLS over the multiple streams as > expected. We can create a wrapper function to send data on a specific > stream, but not to receive only from a given stream. The logic must be: > we receive a message, we can retrieve its stream number, and then we > know the TLS context (session) this message belongs to. I cannot see a > way to achieve this with the API of gnutls. As far as I understand SCTP is that it is a reliable connection with multiple streams. For that I'd treat each stream a separate connection and provide different push/pull functions for each stream. If the number of streams are undefined a thought of mine would be to have a multiplexer that will receive messages and tag them appropriately so the the proper recv function will receive them. Of course this would require to use custom transport ptr and custom recv/send functions. regards, Nikos From nmav at gnutls.org Sat Aug 2 10:37:57 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Aug 2008 11:37:57 +0300 Subject: [Help-gnutls] X.509 certificates around JUST A PUBLIC key... can it be done? In-Reply-To: <4219888f0807291325s267ecdecscf696a4bdc5e2738@mail.gmail.com> References: <4219888f0807291325s267ecdecscf696a4bdc5e2738@mail.gmail.com> Message-ID: <48941CE5.3010409@gnutls.org> Zach C. wrote: > I'm fully aware that I can currently generate the Root and Host certificates > without a problem in GnuTLS. The problem I'm having, though, is that I > *need* to be able to generate a certificate around the public key sent by > the iPhone and then sign that certificate with the root private key. I'm > wondering if that's possible in GnuTLS... I was considering doing a > gnutls_x509_privkey_import_rsa_raw and *only* setting the modulus and public > exponent (however I would get them), but I'm not sure if that would work or > if GnuTLS would throw an error out about it. And if it did it properly, > whether setting the new "private key" struct on a new certificate would do > what I'm describing here. It could work but I'm not sure since it was never designed to be like this. The best way would be to try it and see if it works. As I see it the best way for this to work would be to have a gnutls_crq_import_key_raw() that would create a certificate request with these parameters and then you could create a certificate using this request. It is already in my todo list. regards, Nikos From nmav at gnutls.org Sat Aug 2 11:06:11 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Aug 2008 12:06:11 +0300 Subject: [Help-gnutls] X.509 certificates around JUST A PUBLIC key... can it be done? In-Reply-To: <4219888f0807291325s267ecdecscf696a4bdc5e2738@mail.gmail.com> References: <4219888f0807291325s267ecdecscf696a4bdc5e2738@mail.gmail.com> Message-ID: <48942383.7000503@gnutls.org> Zach C. wrote: > So here's the dilemma. > I'm fully aware that I can currently generate the Root and Host certificates > without a problem in GnuTLS. The problem I'm having, though, is that I > *need* to be able to generate a certificate around the public key sent by > the iPhone and then sign that certificate with the root private key. I'm > wondering if that's possible in GnuTLS... I was considering doing a > gnutls_x509_privkey_import_rsa_raw and *only* setting the modulus and public > exponent (however I would get them), but I'm not sure if that would work or > if GnuTLS would throw an error out about it. And if it did it properly, > whether setting the new "private key" struct on a new certificate would do > what I'm describing here. Actually I sketched a function like that. I'd appreciate if you could try if it fits your needs. regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From fxchip at gmail.com Sat Aug 2 17:16:57 2008 From: fxchip at gmail.com (Zach C.) Date: Sat, 2 Aug 2008 09:16:57 -0600 Subject: [Help-gnutls] X.509 certificates around JUST A PUBLIC key... can it be done? In-Reply-To: <48942383.7000503@gnutls.org> References: <4219888f0807291325s267ecdecscf696a4bdc5e2738@mail.gmail.com> <48942383.7000503@gnutls.org> Message-ID: Hate to tell you this, but I managed to wrangle it to working the way I described using three datum structs, one filled with junk, and gnutls_x509_privkey_rsa_raw. Which I then set onto the cert directly. Worked like a charm. Since the certificate set_key function only ever imports the public exponent and modulus anyway. :) Thanks for the help though :) On Aug 2, 2008, at 3:06 AM, Nikos Mavrogiannopoulos wrote: > Zach C. wrote: >> So here's the dilemma. >> I'm fully aware that I can currently generate the Root and Host >> certificates >> without a problem in GnuTLS. The problem I'm having, though, is >> that I >> *need* to be able to generate a certificate around the public key >> sent by >> the iPhone and then sign that certificate with the root private >> key. I'm >> wondering if that's possible in GnuTLS... I was considering doing a >> gnutls_x509_privkey_import_rsa_raw and *only* setting the modulus >> and public >> exponent (however I would get them), but I'm not sure if that would >> work or >> if GnuTLS would throw an error out about it. And if it did it >> properly, >> whether setting the new "private key" struct on a new certificate >> would do >> what I'm describing here. > > Actually I sketched a function like that. I'd appreciate if you could > try if it fits your needs. > > regards, > Nikos > diff --git a/lib/x509/crq.c b/lib/x509/crq.c > index ff73c40..2eac706 100644 > --- a/lib/x509/crq.c > +++ b/lib/x509/crq.c > @@ -678,6 +678,74 @@ gnutls_x509_crq_set_key (gnutls_x509_crq_t crq, > gnutls_x509_privkey_t key) > } > > /** > + * gnutls_x509_crq_set_key_rsa_raw - This function will associate > the Certificate request with a key > + * @crq: should contain a gnutls_x509_crq_t structure > + * @m: holds the modulus > + * @e: holds the public exponent > + * > + * This function will set the public parameters from the given > private key to the > + * request. Only RSA keys are currently supported. > + * > + * Returns: On success, %GNUTLS_E_SUCCESS is returned, otherwise a > + * negative error value. > + * > + **/ > +int > +gnutls_x509_crq_set_key_rsa_raw (gnutls_x509_crq_t crq, > + const gnutls_datum_t * m, > + const gnutls_datum_t * e) > +{ > + int result, ret; > + size_t siz = 0; > + bigint_t temp_params[RSA_PUBLIC_PARAMS]; > + > + > + if (crq == NULL) > + { > + gnutls_assert (); > + return GNUTLS_E_INVALID_REQUEST; > + } > + > + memset(temp_params, 0, sizeof(temp_params)); > + > + siz = m->size; > + if (_gnutls_mpi_scan_nz (&temp_params[0], m->data, siz)) > + { > + gnutls_assert (); > + ret = GNUTLS_E_MPI_SCAN_FAILED; > + goto error; > + } > + > + siz = e->size; > + if (_gnutls_mpi_scan_nz (&temp_params[1], e->data, siz)) > + { > + gnutls_assert (); > + ret = GNUTLS_E_MPI_SCAN_FAILED; > + goto error; > + } > + > + result = _gnutls_x509_encode_and_copy_PKI_params (crq->crq, > + "certificationRequestInfo.subjectPKInfo", > + GNUTLS_PK_RSA, > + temp_params, > + RSA_PUBLIC_PARAMS); > + > + if (result < 0) > + { > + gnutls_assert (); > + ret = result; > + goto error; > + } > + > + ret = 0; > + > +error: > + _gnutls_mpi_release (&temp_params[0]); > + _gnutls_mpi_release (&temp_params[1]); > + return ret; > +} > + > +/** > * gnutls_x509_crq_set_challenge_password - This function will set > a challenge password > * @crq: should contain a gnutls_x509_crq_t structure > * @pass: holds a null terminated password From brian at brie.com Sun Aug 3 23:11:52 2008 From: brian at brie.com (Brian Lavender) Date: Sun, 3 Aug 2008 14:11:52 -0700 Subject: [Help-gnutls] Equivalent to fdopen? Message-ID: <20080803211152.GC13683@brie.com> I am trying to take a simple socket program and convert it to use gnutls. Is there an equivalent to fdopen so I can stream my secured socket as an fstream? int sock_fd; FILE *sock_fpi; sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); sock_fpi = fdopen( sock_fd, "r" )) But when I attempt to convert it to use gnutls, I run into the following. sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); session = initialize_tls_session (); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sock_fd ); ret = gnutls_handshake (session); And, it appears that I can only read using the following command. ret = gnutls_record_recv (session, buffer, MAX_BUF); Any sugguestions? Is there an fdopen equivalent, so I can still use the fgets and friends? Or, do I have to write my own buffering routine? brian #include #include #include #include #include #include #include #include #include #include #include /* for gcry_control */ #define PORTNUM 15000 #define HOSTLEN 256 #define DH_BITS 2048 #define oops(msg) { perror(msg); exit(1); } #define KEYFILE "key.pem" #define CERTFILE "cert.pem" #define CAFILE "ca.pem" #define CRLFILE "crl.pem" /* These are global */ gnutls_certificate_credentials_t x509_cred; gnutls_priority_t priority_cache; gnutls_session_t initialize_tls_session (void) { gnutls_session_t session; gnutls_init (&session, GNUTLS_SERVER); gnutls_priority_set (session, priority_cache); gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred); /* request client certificate if any. */ gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST); /* Set maximum compatibility mode. This is only suggested on public webservers * that need to trade security for compatibility */ gnutls_session_enable_compatibility_mode( session); return session; } static gnutls_dh_params_t dh_params; static int generate_dh_params (void) { /* Generate Diffie Hellman parameters - for use with DHE * kx algorithms. When short bit length is used, it might * be wise to regenerate parameters. * * Check the ex-serv-export.c example for using static * parameters. */ gnutls_dh_params_init (&dh_params); gnutls_dh_params_generate2 (dh_params, DH_BITS); return 0; } int main(int ac, char *av[] ) { int ret; // return value struct sockaddr_in saddr; struct sockaddr_in sa_cli; int client_len; struct hostent *hp; char hostname[HOSTLEN]; int sock_id, sock_fd; FILE *sock_fpi, *sock_fpo; FILE *pipe_fp; char topbuf[512]; char dirname[BUFSIZ]; char command[BUFSIZ]; int dirlen, c; gnutls_session_t session; /* to disallow usage of the blocking /dev/random */ /* gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);*/ /* this must be called once in the program */ gnutls_global_init (); gnutls_certificate_allocate_credentials (&x509_cred); gnutls_certificate_set_x509_trust_file (x509_cred, CAFILE, GNUTLS_X509_FMT_PEM); gnutls_certificate_set_x509_crl_file (x509_cred, CRLFILE, GNUTLS_X509_FMT_PEM); gnutls_certificate_set_x509_key_file (x509_cred, CERTFILE, KEYFILE, GNUTLS_X509_FMT_PEM); generate_dh_params (); gnutls_priority_init( &priority_cache, "NORMAL", NULL); gnutls_certificate_set_dh_params (x509_cred, dh_params); /* step 1 */ sock_id = socket( PF_INET, SOCK_STREAM, 0 ); if ( sock_id == -1 ) oops("socket"); /* step 2 */ bzero( (void *)&saddr, sizeof(saddr) ); gethostname( hostname, HOSTLEN ); hp = gethostbyname( hostname ); // bcopy( (void *)hp->h_addr, (void *)&saddr.sin_addr, hp->h_length); saddr.sin_addr.s_addr = INADDR_ANY; saddr.sin_port = htons(PORTNUM); saddr.sin_family = AF_INET; if( bind(sock_id, (struct sockaddr *)&saddr, sizeof(saddr)) != 0 ) oops( "bind" ); /* step 3 */ if ( listen(sock_id, 1) != 0 ) oops("listen"); printf ("Server ready. Listening to port '%d'.\n\n", PORTNUM); /* main loop: accept, write, close */ client_len = sizeof (sa_cli); while(1) { session = initialize_tls_session (); sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); if ( sock_fd == -1 ) oops("accept"); printf ("- connection from %s, port %d\n", inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, sizeof (topbuf)), ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sock_fd ); ret = gnutls_handshake (session); if (ret < 0) { close (sock_fd); gnutls_deinit (session); fprintf (stderr, "*** Handshake has failed (%s)\n\n", gnutls_strerror (ret)); continue; } printf ("- Handshake was completed\n"); /* STOP here. PARE aca. :) Now we have a tls_session that we read from. It's not a file descriptor anymore. Can't use fdopen on session :( */ /* open reading direction as buffered stream */ if ( ( sock_fpi = fdopen( sock_fd, "r" )) == NULL ) oops("fdopen reading "); if ( fgets( dirname, BUFSIZ - 5, sock_fpi) == NULL ) oops("reading dirname"); sanitize(dirname); /* open writing direction as buffered stream */ if ( (sock_fpo = fdopen(sock_fd,"w")) == NULL ) oops("fdopen writing"); sprintf( command, "ls %s", dirname); if ( (pipe_fp = popen(command, "r")) == NULL) oops("popen"); /* transfer data from ls to socket */ while ( ( c = getc(pipe_fp)) != EOF ) putc( c , sock_fpo ); pclose(pipe_fp); fclose(sock_fpo); fclose(sock_fpi); } return 0; } sanitize( char *str ) { char *src, *dest; for( src = dest = str; *src; src++ ) if ( *src == '/' || isalnum(*src) ) *dest++ = *src; *dest = '\0'; } -- Brian Lavender http://www.brie.com/brian/ From sdecugis at nict.go.jp Mon Aug 4 03:17:32 2008 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Mon, 04 Aug 2008 10:17:32 +0900 Subject: [SPAM] Re: [Help-gnutls] TLS and SCTP In-Reply-To: <489418D3.5090203@gnutls.org> References: <48903343.9040101@nict.go.jp> <489418D3.5090203@gnutls.org> Message-ID: <489658AC.30404@nict.go.jp> Thank you for reply. I have continued this thread on the gnutls-devel mailing-list. Sebastien. > I'm not familiar with SCTP but I'll try to reply. > > >> I understand how to specify my own transport-layer handlers in GNU TLS >> with the set_push_function and set_pull_function, but I think it is not >> sufficient support to handle the TLS over the multiple streams as >> expected. We can create a wrapper function to send data on a specific >> stream, but not to receive only from a given stream. The logic must be: >> we receive a message, we can retrieve its stream number, and then we >> know the TLS context (session) this message belongs to. I cannot see a >> way to achieve this with the API of gnutls. >> > > As far as I understand SCTP is that it is a reliable connection with > multiple streams. For that I'd treat each stream a separate connection > and provide different push/pull functions for each stream. > > If the number of streams are undefined a thought of mine would be to > have a multiplexer that will receive messages and tag them appropriately > so the the proper recv function will receive them. Of course this would > require to use custom transport ptr and custom recv/send functions. > > regards, > Nikos > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From nmav at gnutls.org Sat Aug 9 11:39:52 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 09 Aug 2008 12:39:52 +0300 Subject: [Help-gnutls] Equivalent to fdopen? In-Reply-To: <20080803211152.GC13683@brie.com> References: <20080803211152.GC13683@brie.com> Message-ID: <489D65E8.2060701@gnutls.org> Brian Lavender wrote: > I am trying to take a simple socket program and convert it to use > gnutls. Is there an equivalent to fdopen so I can stream my secured > socket as an fstream? > > int sock_fd; > FILE *sock_fpi; > > sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); > > sock_fpi = fdopen( sock_fd, "r" )) > > But when I attempt to convert it to use gnutls, I run into the > following. > > sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); > > session = initialize_tls_session (); > > gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sock_fd ); > > ret = gnutls_handshake (session); > > And, it appears that I can only read using the following command. > > ret = gnutls_record_recv (session, buffer, MAX_BUF); Isn't this the expected behavior? gnutls does not know about FILE* pointers, only about descriptors. You'd need a wrapper over gnutls_record_recv for that. regards, Nikos From lanas at securenet.net Tue Aug 12 01:27:31 2008 From: lanas at securenet.net (lanas) Date: Mon, 11 Aug 2008 19:27:31 -0400 Subject: [Help-gnutls] Export restrictions Message-ID: <20080811192731.30bdfdb0@mistral.stie> Hello all, Living in a country where export regulations makes it so that nothing can be shipped that's above 56 bits, I'd like to know if that path was once taken by any gnutls user and if so, if there are any compile recipes out there that would limit to DES (only DES, not 3DES !). Any comments/suggestions/hints appreciated. Cheers. From simon at josefsson.org Tue Aug 12 13:30:41 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 12 Aug 2008 13:30:41 +0200 Subject: [Help-gnutls] Re: Export restrictions In-Reply-To: <20080811192731.30bdfdb0@mistral.stie> (lanas@securenet.net's message of "Mon, 11 Aug 2008 19:27:31 -0400") References: <20080811192731.30bdfdb0@mistral.stie> Message-ID: <877iama2se.fsf@mocca.josefsson.org> lanas writes: > Hello all, > > Living in a country where export regulations makes it so that nothing > can be shipped that's above 56 bits, I'd like to know if that path was > once taken by any gnutls user and if so, if there are any compile > recipes out there that would limit to DES (only DES, not 3DES !). > > Any comments/suggestions/hints appreciated. Right now it isn't possible to disable AES/3DES/RC4-128, but if you write the patch to do add the proper --disable-foo flags, we can consider adding it. Just look at the example of Camellia. I'm not sure you'll be able to use GnuTLS for anything useful with <= 56 bit security though -- many sites on the Internet requires more. /Simon From brian at brie.com Wed Aug 13 20:30:56 2008 From: brian at brie.com (Brian Lavender) Date: Wed, 13 Aug 2008 11:30:56 -0700 Subject: [Help-gnutls] Equivalent to fdopen? In-Reply-To: <489D65E8.2060701@gnutls.org> References: <20080803211152.GC13683@brie.com> <489D65E8.2060701@gnutls.org> Message-ID: <20080813183056.GA16158@brie.com> On Sat, Aug 09, 2008 at 12:39:52PM +0300, Nikos Mavrogiannopoulos wrote: > Brian Lavender wrote: > > I am trying to take a simple socket program and convert it to use > > gnutls. Is there an equivalent to fdopen so I can stream my secured > > socket as an fstream? > > > > int sock_fd; > > FILE *sock_fpi; > > > > sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); > > > > sock_fpi = fdopen( sock_fd, "r" )) > > > > But when I attempt to convert it to use gnutls, I run into the > > following. > > > > sock_fd = accept( sock_id, (struct sockaddr *) &sa_cli, &client_len ); > > > > session = initialize_tls_session (); > > > > gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sock_fd ); > > > > ret = gnutls_handshake (session); > > > > And, it appears that I can only read using the following command. > > > > ret = gnutls_record_recv (session, buffer, MAX_BUF); > > Isn't this the expected behavior? gnutls does not know about FILE* > pointers, only about descriptors. You'd need a wrapper over > gnutls_record_recv for that. Ok, thanks. I thought maybe I was overlooking something. I ended up creating a buffer, reading into it, and then looking for a newline in it. brian -- Brian Lavender http://www.brie.com/brian/ From simon at josefsson.org Thu Aug 14 10:24:25 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 14 Aug 2008 10:24:25 +0200 Subject: [Help-gnutls] Re: Equivalent to fdopen? In-Reply-To: <20080803211152.GC13683@brie.com> (Brian Lavender's message of "Sun, 3 Aug 2008 14:11:52 -0700") References: <20080803211152.GC13683@brie.com> Message-ID: <87y730hume.fsf@mocca.josefsson.org> Brian Lavender writes: > Any sugguestions? Is there an fdopen equivalent, so I can still use the > fgets and friends? Or, do I have to write my own buffering routine? There is no such equivalent now. If it is possible to implement it, it would be a cool feature. But is it possible to implement it? I dunno. Seems like you need some hooks into the f* buffering structures used by libc. It doesn't sound trivial to do. /Simon From brian at brie.com Sat Aug 16 05:26:21 2008 From: brian at brie.com (Brian Lavender) Date: Fri, 15 Aug 2008 20:26:21 -0700 Subject: [Help-gnutls] Can you assign a gnutls_session_t from one variable to another? Message-ID: <20080816032621.GA28498@brie.com> Dumb question. Can you assign a gnutls_session_t from one variable to another? Say I have the following. What is the implication? gnutls_session_t a; gnutls_session_t b; // create socket accept sock_fd a = initialize_tls_session (); gnutls_transport_set_ptr (a, (gnutls_transport_ptr_t) sock_fd ); b = a; ret = gnutls_record_recv(b, &bufferIn.data[bufferIn.index], bufferIn.remaining); gnutls_bye (b, GNUTLS_SHUT_WR); gnutls_deinit (b); brian -- Brian Lavender http://www.brie.com/brian/ From nmav at gnutls.org Sun Aug 17 00:32:44 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 17 Aug 2008 01:32:44 +0300 Subject: [Help-gnutls] Can you assign a gnutls_session_t from one variable to another? In-Reply-To: <20080816032621.GA28498@brie.com> References: <20080816032621.GA28498@brie.com> Message-ID: <48A7558C.5040402@gnutls.org> Brian Lavender wrote: > Dumb question. Can you assign a gnutls_session_t from one variable to > another? > > Say I have the following. What is the implication? > > gnutls_session_t a; > gnutls_session_t b; > > // create socket accept sock_fd > > a = initialize_tls_session (); > gnutls_transport_set_ptr (a, (gnutls_transport_ptr_t) sock_fd ); > > b = a; It is just a pointer so you can do it. From fweimer at bfk.de Mon Aug 18 10:21:21 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 18 Aug 2008 10:21:21 +0200 Subject: [Help-gnutls] Re: Equivalent to fdopen? In-Reply-To: <87y730hume.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 14 Aug 2008 10:24:25 +0200") References: <20080803211152.GC13683@brie.com> <87y730hume.fsf@mocca.josefsson.org> Message-ID: <828wuulon2.fsf@mid.bfk.de> * Simon Josefsson: > There is no such equivalent now. If it is possible to implement it, it > would be a cool feature. But is it possible to implement it? I dunno. > Seems like you need some hooks into the f* buffering structures used by > libc. It doesn't sound trivial to do. You could use socketpair() and threads. But it's certainly not a nice approach. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Tue Aug 19 01:11:23 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 19 Aug 2008 01:11:23 +0200 Subject: [Help-gnutls] Re: Equivalent to fdopen? In-Reply-To: <828wuulon2.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 18 Aug 2008 10:21:21 +0200") References: <20080803211152.GC13683@brie.com> <87y730hume.fsf@mocca.josefsson.org> <828wuulon2.fsf@mid.bfk.de> Message-ID: <878wutex5w.fsf@mocca.josefsson.org> Florian Weimer writes: > * Simon Josefsson: > >> There is no such equivalent now. If it is possible to implement it, it >> would be a cool feature. But is it possible to implement it? I dunno. >> Seems like you need some hooks into the f* buffering structures used by >> libc. It doesn't sound trivial to do. > > You could use socketpair() and threads. But it's certainly not a nice > approach. Right, and since it would be good to avoid thread stuff in libgnutls, I think it cannot be made part of libgnutls. But if someone wants to provide code for this, putting it in a libgnutls-stream library or similar could be done, and may be useful. I suspect rewriting code to use normal read+write instead of buffered f* function is simpler and more reliable though. TLS has some semantic differences compared to network streams that may be difficult to simulate (e.g., re-handshakes and alert messages). /Simon From brian at brie.com Wed Aug 20 08:40:41 2008 From: brian at brie.com (Brian Lavender) Date: Tue, 19 Aug 2008 23:40:41 -0700 Subject: [Help-gnutls] support for ssl3.0 connection Message-ID: <20080820064041.GA8198@brie.com> Thanks for the feedback on the previous questions. I am looking at the docs for selecting different protocols and different ciphersuites. I would like my server connection to attempt ssl3.0 first. I see the command gnutls_priority_init, but I am a little unsure how to tell it to attempt ssl3.0 first. What sort of string should I use for the command? char *error_loc; gnutls_priority_init(&priority_cache, "NORMAL:SSL3.0",**error_loc) brian -- Brian Lavender http://www.brie.com/brian/ From simon at josefsson.org Wed Aug 20 16:42:11 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 20 Aug 2008 16:42:11 +0200 Subject: [Help-gnutls] Re: support for ssl3.0 connection In-Reply-To: <20080820064041.GA8198@brie.com> (Brian Lavender's message of "Tue, 19 Aug 2008 23:40:41 -0700") References: <20080820064041.GA8198@brie.com> Message-ID: <873akzwxx8.fsf@mocca.josefsson.org> Brian Lavender writes: > Thanks for the feedback on the previous questions. > > I am looking at the docs for selecting different protocols and different > ciphersuites. I would like my server connection to attempt ssl3.0 first. > I see the command gnutls_priority_init, but I am a little unsure how to > tell it to attempt ssl3.0 first. What sort of string should I use for > the command? > > char *error_loc; > > gnutls_priority_init(&priority_cache, "NORMAL:SSL3.0",**error_loc) I don't think it is possible to attempt SSL 3.0 before TLS 1.0: the highest mutually supported version number will be used. If both systems support SSL 3.0, TLS 1.0 and TLS 1.1, the only way to negotiate SSL 3.0 is to disable TLS 1.0 and TLS 1.1. To disable TLS 1.0 and TLS 1.1 (which are both enabled by default) you'll want to use a priority string like: NORMAL:-VERS-TLS1.0:-VERS-TLS1.1 /Simon From brian at brie.com Sun Aug 24 03:59:49 2008 From: brian at brie.com (Brian Lavender) Date: Sat, 23 Aug 2008 18:59:49 -0700 Subject: [Help-gnutls] support for ssl3.0 connection In-Reply-To: References: <20080820064041.GA8198@brie.com> Message-ID: <20080824015948.GA4454@brie.com> On Wed, Aug 20, 2008 at 12:08:58PM +0300, Nikos Mavrogiannopoulos wrote: > You cannot. The version negotiation works by trying to negotiate the > highest supported version. Older versions are only used as fallback. > So if you certainly want SSL 3.0 (why?) disable the other protocols. I had trouble getting a python client to connect and I wasn't sure if it didn't support tls and thought that perhaps if I changed the connection to do just SSL 3.0 that it might work. I have since got it working. And, the method for selecting different options makes more sense to me now. brian > > regards, > Nikos > > On Wed, Aug 20, 2008 at 9:40 AM, Brian Lavender wrote: > > Thanks for the feedback on the previous questions. > > > > I am looking at the docs for selecting different protocols and different > > ciphersuites. I would like my server connection to attempt ssl3.0 first. > > I see the command gnutls_priority_init, but I am a little unsure how to > > tell it to attempt ssl3.0 first. What sort of string should I use for > > the command? > > > > char *error_loc; > > > > gnutls_priority_init(&priority_cache, "NORMAL:SSL3.0",**error_loc) > > > > > > brian > > -- > > Brian Lavender > > http://www.brie.com/brian/ > > > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > -- Brian Lavender http://www.brie.com/brian/ From darkdemun at gmail.com Wed Aug 27 01:01:21 2008 From: darkdemun at gmail.com (darkdemun) Date: Wed, 27 Aug 2008 11:01:21 +1200 Subject: [Help-gnutls] GNUTLS ERROR: A TLS packet with unexpected length was received. Message-ID: <11d59200808261601g7225e1a7m36145f39c09a94d0@mail.gmail.com> Hi, I'm making a SSL IRC bot just for learning. The thing is I get "GNUTLS ERROR: A TLS packet with unexpected length was received." when handshaking every 4 connections (and if i keep trying to connect it'll keep happening till i wait for a bit) and i have no idea why, I have attached a log from gnutls-cli. Also I don't get the error when connecting to a inspircd server (only tried connecting to unrealircd servers), I'm using x509 certificate authentication and basically using the code from the examples. I'm using windows by the way, If any of you could help i'd greatly appreciate it. -- Cain. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error.txt URL: From simon at josefsson.org Wed Aug 27 12:35:10 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Aug 2008 12:35:10 +0200 Subject: [Help-gnutls] Re: GNUTLS ERROR: A TLS packet with unexpected length was received. In-Reply-To: <11d59200808261601g7225e1a7m36145f39c09a94d0@mail.gmail.com> (darkdemun@gmail.com's message of "Wed, 27 Aug 2008 11:01:21 +1200") References: <11d59200808261601g7225e1a7m36145f39c09a94d0@mail.gmail.com> Message-ID: <878wuiiw4h.fsf@mocca.josefsson.org> darkdemun writes: > Hi, I'm making a SSL IRC bot just for learning. The thing is I get "GNUTLS > ERROR: A TLS packet with unexpected length was received." when handshaking > every 4 connections (and if i keep trying to connect it'll keep happening > till i wait for a bit) and i have no idea why, I have attached a log from > gnutls-cli. > Also I don't get the error when connecting to a inspircd server (only tried > connecting to unrealircd servers), I'm using x509 certificate authentication > and basically using the code from the examples. I'm using windows by the > way, If any of you could help i'd greatly appreciate it. ... > |<3>| HSK[9b5be8]: CLIENT HELLO was send [43775681070366843 bytes] That was an unrelated problem: I've fixed the debug message to be somewhat more correct. > |<4>| REC[9b5be8]: Sending Packet[0] Handshake(22) with length: 123 > |<2>| ASSERT: ../../../src/gnutls-2.4.1/lib/gnutls_cipher.c:205 That seems strange, I'm not sure why that happens. Do you get this error on the successful connections too? > |<7>| READ: Got 5 bytes from 1916 > |<7>| READ: read 5 bytes from 1916 > |<7>| 0000 - 45 52 52 4f 52 > |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. > |<7>| RB: Requested 5 bytes > |<2>| ASSERT: ../../../src/gnutls-2.4.1/lib/gnutls_record.c:506 > |<4>| REC[9b5be8]: Expected Packet[0] Handshake(22) with length: 1 > |<4>| REC[9b5be8]: Received Packet[0] Unknown Packet(69) with length: 20306 > |<4>| REC[9b5be8]: FATAL ERROR: Received packet with length: 20306 If you decode the received 5 bytes of data, you'll see that it says 'ERROR'. Thus, the server is not talking TLS any more, but instead sent you an unencrypted 'ERROR' message. Presumably the server's TLS library failed, and the server didn't know what to do. It would help if you could debug things on the server side as well. Things to try is to disable all TLS extensions and enable compatibility hacks. Try gnutls-cli --priority NORMAL:%COMPAT And then disable more things too. /Simon From aspecialj at gmail.com Wed Aug 27 12:55:21 2008 From: aspecialj at gmail.com (John Brooks) Date: Wed, 27 Aug 2008 04:55:21 -0600 Subject: [Help-gnutls] GNUTLS ERROR: A TLS packet with unexpected length was received. In-Reply-To: <11d59200808261601g7225e1a7m36145f39c09a94d0@mail.gmail.com> References: <11d59200808261601g7225e1a7m36145f39c09a94d0@mail.gmail.com> Message-ID: Drawing on my knowledge of unrealircd for this (which is somewhat outdated, but I believe still correct), my guess is that you're hitting the throttling limit of the ircd. After a certain number of connections from an IP in a certain amount of time, it starts rejecting new ones - and I wouldn't be suprised if it rejects their handshakes as well (save resources, DDoS prevention). I believe this is configurable - check the config and try connecting repeatedly without SSL to see what it says. Another possibility is that the IP is Z-Lined; unrealircd will send an ERROR in plaintext even if you attempt to connect with SSL (which will show up as exactly that error). Again, to prevent excess resource usage and help stop DDoS. Either way, i'm inclined to think that this is one of those two slightly misguided features of unrealircd, rather than a SSL issue. Inspircd is better anyway :P - John Brooks On Tue, Aug 26, 2008 at 5:01 PM, darkdemun wrote: > > Hi, I'm making a SSL IRC bot just for learning. The thing is I get "GNUTLS > ERROR: A TLS packet with unexpected length was received." when handshaking > every 4 connections (and if i keep trying to connect it'll keep happening > till i wait for a bit) and i have no idea why, I have attached a log from > gnutls-cli. > Also I don't get the error when connecting to a inspircd server (only tried > connecting to unrealircd servers), I'm using x509 certificate authentication > and basically using the code from the examples. I'm using windows by the > way, If any of you could help i'd greatly appreciate it. > > -- > Cain. > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Aug 29 17:22:16 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Aug 2008 17:22:16 +0200 Subject: [Help-gnutls] Re: NSS info for the comparison table In-Reply-To: (Daniel Stenberg's message of "Fri, 25 Jul 2008 23:21:50 +0200 (CEST)") References: Message-ID: <87hc93u9qv.fsf@mocca.josefsson.org> Daniel Stenberg writes: > Hi > > I pointed out your excellent SSL/TLS lib comparison table to the NSS > guys the other day and they seem to have ideas about > corrections/updates for it. Here's the thread on the NSS list: > > http://thread.gmane.org/gmane.comp.mozilla.crypto/9950 Hi! Thanks for the pointer, I updated the page slightly. More suggestions are welcome. The page should probably be moved to a wiki page so everyone can edit it... /Simon