Bootstrap parallel connections using session resume ?

[Sebastien Decugis-2]

Hello,

I am trying to establish several parallel TLS-protected channels between
two nodes, like this :
- establish the first connection (called "master")
- TLS handshake, verify credentials,
- If successful, establish the other connections (same endpoints)
- TLS handshake each of these connections (in parallel in several
threads), using the same credentials as the master session.

I got this working, but I would like to optimize the establishment of
the multi-connections. I can see several ways to do this, but I would
like to know if they are not mis-use of the GnuTLS library.  What I am
trying to do is:
- create several threads after the master handshake and verification,
and handle each children handshake independently.
- use session resuming from the master session to accelerate the
handshake in all children connections.

Each connection has an independant gnutls_session_t object, but share
the same credentials structures. On the server side, I have set the same
session store for all sessions. I need to set the transport pointer in
the sessions using the gnutls_transport_set_ptr function. Should I do it
before or after the gnutls_session_set_data on the client side? Is there
anything more to do ?

I don't know if it is relevant, my different channels are actually the
same socket object, but different SCTP streams, and I use customs
push/pull functions to mux/demux the messages. I can send my code
showing the actual implementation if you are interested.

So far, I was not able to use multithreading and resuming efficiently.
Most of the sessions fail to resume and fallback to a full handshake. I
have seen also some strange behavior (store operation with the same key
but different data) so I am wondering if this whole mechanism is really
possible with GnuTLS. I don't really understand what is behind session
resuming, so please tell me if what I am trying to do is really wrong...

Thank you in advance,
Best regards,
Sebastien.


_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos]

Sebastien Decugis wrote:

> Hello,
>
> I am trying to establish several parallel TLS-protected channels between
> two nodes, like this :
> - establish the first connection (called "master")
> - TLS handshake, verify credentials,
> - If successful, establish the other connections (same endpoints)
> - TLS handshake each of these connections (in parallel in several
> threads), using the same credentials as the master session.
>
> I got this working, but I would like to optimize the establishment of
> the multi-connections. I can see several ways to do this, but I would
> like to know if they are not mis-use of the GnuTLS library.  What I am
> trying to do is:
> - create several threads after the master handshake and verification,
> and handle each children handshake independently.
> - use session resuming from the master session to accelerate the
> handshake in all children connections.
>
> Each connection has an independant gnutls_session_t object, but share
> the same credentials structures. On the server side, I have set the same
> session store for all sessions. I need to set the transport pointer in
> the sessions using the gnutls_transport_set_ptr function. Should I do it
> before or after the gnutls_session_set_data on the client side?

There is no real difference.

> Is there
> anything more to do ?

I don't think so. It looks correct.


> I don't know if it is relevant, my different channels are actually the
> same socket object, but different SCTP streams, and I use customs
> push/pull functions to mux/demux the messages. I can send my code
> showing the actual implementation if you are interested.

Actually I'm interested in the implementation. Would you be interested
to write few words and example push/pull functions on how to use gnutls
over SCTP, to add in the manual? It can be something like the examples
there:
http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples

> So far, I was not able to use multithreading and resuming efficiently.
> Most of the sessions fail to resume and fallback to a full handshake. I
> have seen also some strange behavior (store operation with the same key
> but different data) so I am wondering if this whole mechanism is really
> possible with GnuTLS.

Was this on the server side or client side? If it is on client side, you
should note that you need not and better shouldn't keep the session data
of a resumed session. Just use the session data of the original one or
the last on that didn't success in resuming. If this is not the case
please let me know of the details as well.

I don't really understand what is behind session
> resuming, so please tell me if what I am trying to do is really wrong...

What you do is what session resuming was made for.


regards,
Nikos


_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

[Sebastien Decugis-2]

Hi Nikos, thank you for your fast answer.

>> Each connection has an independant gnutls_session_t object, but share
>> the same credentials structures. On the server side, I have set the same
>> session store for all sessions. I need to set the transport pointer in
>> the sessions using the gnutls_transport_set_ptr function. Should I do it
>> before or after the gnutls_session_set_data on the client side?
>>    
>
> There is no real difference.
>  
[talking about the client side here]
Ok, so if I understand correctly the transport parameters are not stored
inside the data returned by gnutls_session_get_data2, right ?
What about the credentials (priority, CA, key, ...) ? Do I have to set
them before I set the session data, or does this operation set them for
me (so I don't have to do it at all ?)

>> I don't know if it is relevant, my different channels are actually the
>> same socket object, but different SCTP streams, and I use customs
>> push/pull functions to mux/demux the messages. I can send my code
>> showing the actual implementation if you are interested.
>>    
>
> Actually I'm interested in the implementation. Would you be interested
> to write few words and example push/pull functions on how to use gnutls
> over SCTP, to add in the manual? It can be something like the examples
> there:
> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples
>  

Well, I can at least send you pointers to my code with some explanation
so that you get an idea of how I am doing it, and then if you're still
interested I'll try to extract the parts interesting for the manual or
build a demonstration sample. BTW my code is BSD licensed (but I think
it is no problem to extract a small part for the gnutls manual and
release this part under a different license --  at least on my side)

>> So far, I was not able to use multithreading and resuming efficiently.
>> Most of the sessions fail to resume and fallback to a full handshake. I
>> have seen also some strange behavior (store operation with the same key
>> but different data) so I am wondering if this whole mechanism is really
>> possible with GnuTLS.
>>    
>
> Was this on the server side or client side? If it is on client side, you
> should note that you need not and better shouldn't keep the session data
> of a resumed session. Just use the session data of the original one or
> the last on that didn't success in resuming. If this is not the case
> please let me know of the details as well.
>  

Well, currently I am using the db_* functions only on the server side,
my understanding was that they are not used on the client side, right ?
On the client side, I only get the data of my primary (handshaken)
session and then set this data in all other sessions before handshake.

Anyway for some reason that I don't understand, it seems that now it
started to work properly, and I see successfully resumed sessions -- I
really don't know what I changed in my code for this result -- but I am
not complaining ^^

> What you do is what session resuming was made for.
>  
Ok, great then :)

Thank you again!
Best regards,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)



_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos]

Sebastien Decugis wrote:

> [talking about the client side here]
> Ok, so if I understand correctly the transport parameters are not stored
> inside the data returned by gnutls_session_get_data2, right ?

Indeed.

> What about the credentials (priority, CA, key, ...) ? Do I have to set
> them before I set the session data, or does this operation set them for
> me (so I don't have to do it at all ?)

Those are needed to be set since the server might decide not to resume.
If he doesn't typically they are ignored.

>>> I don't know if it is relevant, my different channels are actually the
>>> same socket object, but different SCTP streams, and I use customs
>>> push/pull functions to mux/demux the messages. I can send my code
>>> showing the actual implementation if you are interested.
>>>    
>> Actually I'm interested in the implementation. Would you be interested
>> to write few words and example push/pull functions on how to use gnutls
>> over SCTP, to add in the manual? It can be something like the examples
>> there:
>> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples
>>  
> Well, I can at least send you pointers to my code with some explanation
> so that you get an idea of how I am doing it, and then if you're still
> interested I'll try to extract the parts interesting for the manual or
> build a demonstration sample.

That would be perfect. Please send me.

>>> So far, I was not able to use multithreading and resuming efficiently.
>>> Most of the sessions fail to resume and fallback to a full handshake. I
>>> have seen also some strange behavior (store operation with the same key
>>> but different data) so I am wondering if this whole mechanism is really
>>> possible with GnuTLS.
>>>    
>> Was this on the server side or client side? If it is on client side, you
>> should note that you need not and better shouldn't keep the session data
>> of a resumed session. Just use the session data of the original one or
>> the last on that didn't success in resuming. If this is not the case
>> please let me know of the details as well.
>>  
> Well, currently I am using the db_* functions only on the server side,
> my understanding was that they are not used on the client side, right ?
> On the client side, I only get the data of my primary (handshaken)
> session and then set this data in all other sessions before handshake.

Correct.

> Anyway for some reason that I don't understand, it seems that now it
> started to work properly, and I see successfully resumed sessions -- I
> really don't know what I changed in my code for this result -- but I am
> not complaining ^^

I'm quite curious on the previous behavior, where you noticed the same
session ID being save twice in server side. It seems the server was
wrongly trying to overwrite the initial session parameters with the
resumed one. The attached patch should fix what you have noticed.
(what you see now might be a timing issue if all the clients connect
before the server has overwritten the initial parameters).


regards,
Nikos


diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c
index 93e0553..261348d 100644
--- a/lib/gnutls_handshake.c
+++ b/lib/gnutls_handshake.c
@@ -2822,6 +2822,13 @@ _gnutls_handshake_common (gnutls_session_t session)
 
       ret = _gnutls_send_handshake_final (session, FALSE);
       IMED_RET ("send handshake final", ret, 0);
+
+      /* only store if we are not resuming */
+      if (session->security_parameters.entity == GNUTLS_SERVER)
+        {
+          /* in order to support session resuming */
+          _gnutls_server_register_current_session (session);
+        }
     }
   else
     { /* if we are a client not resuming - or we are a server resuming */
@@ -2848,14 +2855,10 @@ _gnutls_handshake_common (gnutls_session_t session)
 
       ret = _gnutls_recv_handshake_final (session, FALSE);
       IMED_RET ("recv handshake final 2", ret, 1);
-    }
 
-  if (session->security_parameters.entity == GNUTLS_SERVER)
-    {
-      /* in order to support session resuming */
-      _gnutls_server_register_current_session (session);
     }
 
+
   /* clear handshake buffer */
   _gnutls_handshake_hash_buffers_clear (session);
   return ret;

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls

[Sebastien Decugis-2]

Hi again Nikos,

>> Well, I can at least send you pointers to my code with some explanation
>> so that you get an idea of how I am doing it, and then if you're still
>> interested I'll try to extract the parts interesting for the manual or
>> build a demonstration sample.
>>    
>
> That would be perfect. Please send me.
>  
Ok, I am sending this in private mail, to avoid spamming the list :)

>> Anyway for some reason that I don't understand, it seems that now it
>> started to work properly, and I see successfully resumed sessions -- I
>> really don't know what I changed in my code for this result -- but I am
>> not complaining ^^
>>    
>
> I'm quite curious on the previous behavior, where you noticed the same
> session ID being save twice in server side. It seems the server was
> wrongly trying to overwrite the initial session parameters with the
> resumed one. The attached patch should fix what you have noticed.
> (what you see now might be a timing issue if all the clients connect
> before the server has overwritten the initial parameters).
>  

Well, I might have used some un-initialized pointers at some point when
I saw those traces, so maybe it's better to ignore them... I'll
investigate more seriously if I run into them again.
Thank you for the patch, but I am using a pre-compiled GnuTLS library
currently, and I would prefer to stick with it if I can...

Best regards,
Sebastien.


_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
http://lists.gnu.org/mailman/listinfo/help-gnutls