Hello again, I just found that my debug routine was actually writing the current timestamp at the beginning of the key id!!! I am very sorry for all the noise because of my stupid mistake... I am going to check again with a fixed routine and let you know if everything is fine now.
Best regards, Sebastien. Le 18/02/2010 16:00, Sebastien Decugis a écrit : > Hello Nikos, all, > > Thank you for your feedback! I just tried with 2.8.5 and got exactly the > same issue. > > Before going further, let me report a few glintches I got with the 2.8.5 > (retrieved from the tag in git), if it is of interest: > - it did not compile "out of the box". There was a warning preventing > the compilation in gnutls_compress.c line 402 about unused label. I > worked around this one by installing libz-dev (maybe worth adding inside > the README-alpha list of packages? or adding #ifdef's around the label?) > - Once I tried to use this new version, I got a "Ohhhh jeeee: operation > is not possible without initialized secure memory" or something similar > from my software. After googling a little bit, I added "gcry_control > (GCRYCTL_DISABLE_SECMEM, NULL, 0);" in my code before calling the > gnutls_global_init(), along with my other initializers for gcry (that I > need because of multithreading). Maybe this should be written in the > GNUTLS manual where examples for multithreading are given (7.2 > Multi-Threaded Applications) ? > > Ok, now to my issue. > > Can you help me with valgrind? I never used it, and I am not sure how I > can proceed... If possible I'd like to avoid spending 1 week learning > about this tool. Thank you in advance :) > BTW: about the hardware I am using, it is two virtualbox virtual > machines (maybe not relevant but anyway). The client is 64bits Ubuntu > Karmic. The server is 32 bits Debian (with 2.8.5 "fresh" GNUTLS). > > For reference, here is the sequence of calls I am doing in gnutls: > > [initialization] > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread) > gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0) > gcry_control (GCRYCTL_DISABLE_SECMEM, NULL, 0) > gnutls_global_init() > gnutls_certificate_allocate_credentials (...) > gnutls_dh_params_init (...) > gnutls_certificate_set_x509_key_file( ... ) > gnutls_certificate_set_x509_trust_file( ... ) > gnutls_priority_init( ..., GNUTLS_DEFAULT_PRIORITY, ...) > gnutls_dh_params_generate2( ..., GNUTLS_DEFAULT_DHBITS) > > [connection of the client : first, full handshake on stream 0] > gnutls_init (..., GNUTLS_SERVER) > gnutls_priority_set( ... ) > gnutls_credentials_set (..., GNUTLS_CRD_CERTIFICATE, ...) > gnutls_transport_set_ptr(...) > gnutls_transport_set_lowat( ..., 0 ) > gnutls_transport_set_pull_function(...) > gnutls_transport_set_push_function(...) > gnutls_db_set_retrieve_function(..., sr_fetch) > gnutls_db_set_remove_function (..., sr_remove) > gnutls_db_set_store_function ( ..., sr_store) > gnutls_db_set_ptr ( ...) > gnutls_handshake(...) > * at this point, data is exchanged with the client. S: sent, R: > received. number of bytes follows: > R:81 > S:79 > S:2333 > S:44 > S:9 > R:2333 > R:139 > R:6 > R:69 > S:6 > S:85 > Gnutls callback: sr_store, key id: [key > 2e303600c0e985f29a780d6814e0b76ee6e318dc7d0360e7c8f704b570dbdf34] > > This is the detail of the session when I verify the credentials: > - Key Exchange: RSA > - Protocol: TLS1.1 > - Certificate Type: X.509 > - Compression: NULL > - Cipher: AES-128-CBC > - MAC: SHA1 > > [now, I want to start a resumed handshake on other 2 streams.] > [the following happens in paralel in two threads. There are 3 different > gnutls_session_t in total.] > gnutls_init (..., GNUTLS_SERVER) > gnutls_priority_set( ... ) > gnutls_credentials_set (..., GNUTLS_CRD_CERTIFICATE, ...) > gnutls_db_set_retrieve_function(..., sr_fetch) > gnutls_db_set_remove_function (..., sr_remove) > gnutls_db_set_store_function ( ..., sr_store) > gnutls_db_set_ptr ( ...) > gnutls_transport_set_ptr(...) > gnutls_transport_set_lowat( ..., 0 ) > gnutls_transport_set_pull_function(...) > gnutls_transport_set_push_function(...) > gnutls_handshake(...) > R:113 > Gnutls callback: sr_fetch [key > 2e313300c0e985f29a780d6814e0b76ee6e318dc7d0360e7c8f704b570dbdf34] > This callback fails because the id is different... > > > Can you see something obviously wrong in this sequence of calls? > > Thank you in advance! > Best regards, > Sebastien. > > Le 17/02/2010 18:24, Nikos Mavrogiannopoulos a écrit : > >> On Wed, Feb 17, 2010 at 8:36 AM, Sebastien Decugis <[email protected]> >> wrote: >> >> >>> Hello, >>> >>> I am running in a problem with session resuming, I hope someone can >>> understand the source of the issue ^^. Please excuse the long mail... >>> >>> >> [...] >> >> >>> My understanding of the issue is that the server tries to resume a >>> session with a different ID than what was stored. Here is exactly the >>> sequence of events, I hope it clarifies. >>> >>> >> As far as I understand from your description this is not normal, something is >> weird on the server side. Could you try with a more recent server version? >> (i just tried with 2.8.5 version and seems to work ok). There are some fixes >> in the session resumption code, but nothing similar to what you describe >> here. >> This looks like a memory corruption. If the problem insists with 2.8.5 >> please try >> running the server with valgrind on the same hardware. >> >> regards, >> Nikos >> >> >> > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
