Versions Compared

Old Version 10

changes.mady.by.user Sergii Iaroslavtsev

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (shinrich)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

What's ssl session resumption

  • When a client and server establish an SSL connection for the first time they need to establish ashared a shared 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 a public key algorithms: algorithm such as EC, 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

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

...

  • In addition, TLS extensions support a ticket based session resumption.  On first TLS handshake the server returns an encrypted version of the session state.  The client treats this as an opaque ticket and presents it on the next TLS handshake to the same server.

Challenges for TrafficServer

  • For a single server session ID based resumption and ticket based resumption would work just fine.  If there are parallel traffic servers deployed behind a virtual IP and a client may be directed to different real servers, then some coordination must occur to successful resume TLS sessions.
  • For tickets, the parallel TrafficServers must share the same ticket encrypting keys.  You can copy around files as discussed in the documentation, or use the TSSslTicketKeyUpdate API to programmatically share and update the ticket key.
  • For session ID based resumptions, the TrafficServers must share session state.  For 8.0 we added TLS Session Plugin API, so one could write a plugin to propagate session state between TrafficServer installations.  
  • A ssl_session_reuse plugin is in the experimental plugin tree.  This plugin uses redis to communicate session state between traffic_server instances.  It also implements an algorithm to coordinate ticket encrypting key creation.