gmane.network.gnutls.general

Re: NSS info for the comparison table

Simon Josefsson — 2008-08-29T15:22:16

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

Re: GNUTLS ERROR: A TLS packet with unexpected lengthwas received.

John Brooks — 2008-08-27T10:55:21

_______________________________________________ Help-gnutls mailing list Help-gnutls< at >gnu.org http://lists.gnu.org/mailman/listinfo/help-gnutls

Re: GNUTLS ERROR: A TLS packet with unexpected lengthwas received.

Simon Josefsson — 2008-08-27T10:35:10

... That was an unrelated problem: I've fixed the debug message to be somewhat more correct. That seems strange, I'm not sure why that happens. Do you get this error on the successful connections too? 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

GNUTLS ERROR: A TLS packet with unexpected length wasreceived.

darkdemun — 2008-08-26T23:01:21

|<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[9b5be8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<

Re: support for ssl3.0 connection

Brian Lavender — 2008-08-24T01:59:49

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

Re: support for ssl3.0 connection

Simon Josefsson — 2008-08-20T14:42:11

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

support for ssl3.0 connection

Brian Lavender — 2008-08-20T06:40:41

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

Re: Equivalent to fdopen?

Simon Josefsson — 2008-08-18T23:11:23

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

Re: Re: Equivalent to fdopen?

Florian Weimer — 2008-08-18T08:21:21

* Simon Josefsson: You could use socketpair() and threads. But it's certainly not a nice approach.

Re: Can you assign a gnutls_session_t from one variableto another?

Nikos Mavrogiannopoulos — 2008-08-16T22:32:44

It is just a pointer so you can do it.

Can you assign a gnutls_session_t from one variableto another?

Brian Lavender — 2008-08-16T03:26:21

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

Re: Equivalent to fdopen?

Simon Josefsson — 2008-08-14T08:24:25

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

Re: Equivalent to fdopen?

Brian Lavender — 2008-08-13T18:30:56

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

Re: Export restrictions

Simon Josefsson — 2008-08-12T11:30:41

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

Export restrictions

lanas — 2008-08-11T23:27:31

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.

Re: Equivalent to fdopen?

Nikos Mavrogiannopoulos — 2008-08-09T09:39:52

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

Re: [SPAM] Re: TLS and SCTP

Sebastien Decugis — 2008-08-04T01:17:32

Thank you for reply. I have continued this thread on the gnutls-devel mailing-list. Sebastien.

Equivalent to fdopen?

Brian Lavender — 2008-08-03T21:11:52

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

Re: X.509 certificates around JUST A PUBLIC key... canit be done?

Zach C. — 2008-08-02T15:16:57

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 gnutls.org> wrote:

Re: X.509 certificates around JUST A PUBLIC key...can it be done?

Nikos Mavrogiannopoulos — 2008-08-02T09:06:11

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 < at >< at > -678,6 +678,74 < at >< at > 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 + * < at >crq: should contain a gnutls_x509_crq_t structure + * < at >m: holds the modulus + * < at >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_PUBLI

Re: X.509 certificates around JUST A PUBLIC key...can it be done?

Nikos Mavrogiannopoulos — 2008-08-02T08:37:57

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