Versions Compared

Old Version 7

changes.mady.by.user zhang zirong

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/5487Image Removed)

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.

sigle server solution can not slove all the problem

  • when in a cluster mode and have a LB in front, session resumption can not work

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_idImage Removed) 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.