Problem with session resuming

[Sebastien Decugis]

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 <sdecugis at nict.go.jp> 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)