Problem with session resuming

[Sebastien Decugis]

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)