what's ssl session resumption

• When a client and server establish an SSL connection for the first time they need to establish ashared key called the master_secret. The master_secret is then used to create all the bulk encryption keys used to protect the traffic. The master_secret is almost invariably established using one of two public key algorithms: RSA or Diffie-Hellman (DH). Unfortunately, both of these algorithms are quite slow. In order to improve performance, SSL contains a "session resumption" feature that allows a client/server pair to skip this time consuming step if they have already established a master_secret in a previous connection. (from Eric Rescorla's article http://www.linuxjournal.com/article/5487)

what's the problem in TS

• ssl session resumption can not work in some case
  • https://issues.apache.org/jira/browse/TS-718
• sessions store in ssl internal cache
  • https://issues.apache.org/jira/browse/TS-463

what we have done

• we have complete a solution for single server.
  • disable internal session cache(set SSL_SESS_CACHE_NO_INTERNAL).
  • store session cache in a hashtable in memory.
  • hook the get session API and look up session from hashtable by session_id.
  • have a continuation to delete stale cache when hashtable full.

single server solution cannot solve all the problem

• when in a production, the most case you will get a VIP device in front, the session resumption can not work unless all connections on the same hosts, that is impossible. – cluster wide session data sharing
• when you have many connections to manage, it's not so good to store all these session data in memory while you do not even know when the user would like to use it. – need a way to store data on disk and do LRU etc.
• when you have two VIP in the same DNS, would you like to share the session data? even when the two VIP/cluster in different colo?
• we don't want to add more codes in iocore, can we make this a plugin?
• if I don't like the idea of your plugin, can I do my own plugin? we need to get a new hook?

what's our plan

• use http cache in TS to store ssl sesion
  • make the session_id like http request(http://ssl.session.cache/session_id) as the key
  • make the session as the value
  • use cacheProcessor API to set and get ssl session
    • use the cluster to share the session in multi-server through cacheProcessor
    • use the partition to limit the size of the cache

we need your advice