[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
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 ?
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 ?
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.
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].
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-session-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
