[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
Le 21/09/2016 à 18:19, Hudalla Kai (INST/ESY1) a écrit :
Thanks for the excellent feedback, Simon :-)
On Mi, 2016-09-21 at 18:04 +0200, Simon Bernard wrote:
This seems to me a better approach than the previous one :) (trying to
persist ConnectionStore).
Some remarks/questions below :
1) Why LeastRecentlyUsedCache.class is no more threadsafe ?
I thought that it would make sense to leave that to the context in which the
cache is used in case you find other ways of making sure that a cache is
always only accessed by a single thread.
2) The TLS spec[1] say :
"Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal alert
MUST NOT be resumed."
Should we implement this ?
You mean that we need to make sure that a session is removed from the cache
in such cases, right? I guess we should do that.
Exactly.
3) If we implement 2) the "InMemoryConnectionStore.find()" should always
look in the shared store (SessionCache) and should not check before in
the connections map in memory.
To make sure that we do not use a "stale" session that has been removed from
the cache by another node, right?
Right.
4) Not directly linked to this branch but the RF5077[2] is another way
to resume session:
"This mechanism is useful in the following situations:
1. servers that handle a large number of transactions from
different users
2. servers that desire to cache sessions for a long time
3. ability to load balance requests across servers
4. embedded servers with little memory"
Here[3][4] are interesting posts about session resumption and Forward
Secrecy [3][4].
Thanks for the links. I already had taken a look at RFC5077 but my concern is
that we will probably not find many client implementations supporting it,
right?
This begin to be implemented. gnutls support it and wolfssl seems to
support it too.
Simon
[1]https://tools.ietf.org/html/rfc5246#section-7.2.2
[2]https://tools.ietf.org/html/rfc5077
[3]https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-sess
ion-resumption-implementations/
[4]https://blog.twitter.com/2013/forward-secrecy-at-twitter-0
Le 21/09/2016 à 12:04, Hudalla Kai (INST/ESY1) a écrit :
Hi,
some months ago I had started to work on introducing means to Scandium to
be
able to share state of an established DTLS session (crypto params) among
multiple nodes.
The idea is to allow for clients being able to resume a DTLS session
(using
an abbreviated handshake) with another node than the one the session has
been
originally been established with (e.g. after the original node has
crashed).
I have added the code to the session_cache branch based on current master
[1]. There also has been a question raised around that topic [2].
I would be interested in getting some feedback whether you think this is
a
useful addition and you could put this to work in your environment.
[1] https://github.com/eclipse/californium/tree/session_cache
[2] https://github.com/eclipse/californium/issues/89
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
