Problem with session resuming

[Sebastien Decugis]

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)