I confirm, session resuming works fine now! Both on 2.8.5 and 2.4.2 (debian stable).
Best regards, Sebastien. Le 18/02/2010 16:13, Sebastien Decugis a écrit : > 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
