Server based TLS-Session-Resumption

[marvin-enthus]

Hi,

with this pull request we would provide server-based TLS session caching and resumption. The code for handling the session resumption is within TlsServerProtocol.java, but there is no default session management. This has to be provided by an extra TlsServer implementation that handles the getResumableSession(byte[] sessionID) and getNewResumableSession(byte[] requestedClientSessionID) accordingly.

For the implementation following changes have been done:

• TlsServer.java / AbstractTlsServer.java:
  Introduced two new methods for session resumption and session creation. TlsServer.java defines the methods, AbstractTlsServer.java implements two placeholders that just fulfil the interface requirements but don't do anything...

  The methods are:

  • public TlsSession getResumableSession(byte[] sessionID) throws IOException
  • public TlsSession getNewResumableSession(byte[] requestedClientSessionID)

• TlsServerProtocol.java:
  Here is most of the work done:
  class level:

  • New class variable to hold the session ID requested by the client

  handleHandshakeMessage():

  • during HandshakeType.client_hello / CS_START: it is checked if we are resuming a session and if yes we do the appropriate handshake flow for a resumed session.
  • during HandshakeType.finished / CS_SERVER_FINISHED: Do the rest of the resume session workflow.

  receiveClientHelloMessage():

  • save the client's requested session ID to the class variable
  • Ask the TlsServer if there is an existing session for this session ID
  • If yes, set the flag that we are resuming the session
  • Implemented some of the RFC 5246 TODO's

  sendServerHelloMessage()

  • send back the client's sessionID if we are resuming or ask the TlsServer for a new session ID if we have no session or the session is not resumable
  • moved some common things (prfAlgorithm decision, verifyDataLength & applyMaxFragmentLengthExtension()) to an earlier position
  • If we are doing a session resumption stop before building and seding server extensions - RFC 3546 sais during resumption the server hello doesn't hold any extensions.

• SessionParameters.java (with related changes in TlsClientProtocol.java and DTLSClientProtocol.java):
  Refactored encodedServerExtension to encodedPeerExtensions because in this case it holds the client extensions...

• TlsProtocol.java:
  Fill SessionParameters.java accordingly depending if server or client...

We tested session resumption against Linux (OpenSSL), Mac OSX and Microsoft clients and it works in our scenarios. We hope this pull request will be included in the main stream.

If there are questions or comments just ask ;)

bye,
Chris

[marvin-enthus]

I just updated this pull request. We discovered that some RFC 3546 statements about TLS hello extensions handling during resumption have been misleading. Some other RFC's define explicit handling for some extensions during resumption, so we adopted it. It was discovered by problems with the latest version of Apple's coreTLS. It seems neither OpenSSL nor Microsoft's implementations take care of it...

@peterdettman you self-assigned this to you. Any thoughts on this PR?

[marvin-enthus]

Hi. I've just rebased this PR to the master to resolve the conflicts.