[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
Ok, I have tried to incorporate all of your valuable feedback, Simon and I
have created a PR against the 2.0.x branch since this is the one that we are
doing development for "clustering support". I therefore have deleted the
"session_cache" branch.
We can still add support for RFC 5077 later on, I guess.
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
On Mi, 2016-09-21 at 18:52 +0200, Simon Bernard wrote:
> 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
> _______________________________________________
> 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
