Brief features of rfc5077:
 * Like session IDs, this allows client to resume tls sessions with a quicker
   startup latency by a full round trip. All of these clients can connect with
   the quicker session resumption.
 * This feature is TLS only and not in SSLv3.
 * A single AES key and HMAC on the server are used to protect session information of
   an unlimited number of clients that support the TLS extension session tickets.
 * The state, including the cryptographic variables, any client certificates or
   other stored authentication, or any element of client state, is stored
   encrypted on in the client browser.
 * The client stores the crypto state as an opaque blob encrypted by the AES key
   and validated by the HMAC in the server.

For full details, and perhaps more accurate information, read RFC5077.

Security considerations is described in rfc5077.

Client support:

Seems all Firefox and Chrome support it. IE doesn't yet according to:
http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html

IMPLEMENTATION:

This follows the recommended reference implementation of RFC5077 which are
largely part of the openssl libraries.

This patch uses a fixed 120 bytes of the ssl_session_cache for two session tickets.

The timeout from ssl_ticket_timeout is also used for session tickets defaulting to
one week (Based on the security considerations in 5.6 of the RFC5077).

The current full session ID is still available after applying this patch.

If session ticket fails due to any reason the session ID of the client is used
to store the session resumption.

The full ngx_ssl_tlsext_ticket_key_cb was implemented following a similar form
to the internal openssl. This was done so that a future extension could support
a shared cache between servers.

Consequential changes:

* renamed the following to better represent their content:
ngx_ssl_session_cache_init -> ngx_ssl_cache_init
ngx_ssl_session_cache_t -> ngx_ssl_cache_t

ssl_ticket_timeout added to http and mail modules

* data structures

changes to where ssl session id information is stored as both tickets and
sessions are now in the same structure.

TICKET RENEWAL

The design was that two tickets have overlapping expire times so even if a
session resumption occurs within the expiry time the server will issue the next
session ticket anyway to allow the next connection of the client use a new ticket.

The tickets were designed to renew after 1/2 the timeout period has passed.

Unfortunately after testing clients the following clients it seems that all
abort with an unexpected tls message.

The following libraries were tested:
 * nss 3.13.5
 * gnutls 2.12.17
 * openssl 1.0.0j

Google Chrome Version 23.0.1271.10 dev also aborted connection though because of
its many connection policy it appears to have dropped its session ticket after
the connection was aborted and the new (concurrent possibly) connection picked
up the new ticket.

Looking at the Apache implementation of the callback
(httpd-trunk/modules/ssl/ssl_engine_kernel.c:ssl_callback_SessionTicket) the
resume option isn't used.

A #define NGX_RENEW_SSL_TICKET is included to enable the feature but commenting it
out will disable the renewal process and leave the tickets to expire.

SESSION ID AND SESSION TICKET BEHAVIOUR:

Clients presenting both session id and session tickets will be processed down the
session ticket path as per 3.4 of RFC5077. This is all handled internally within
openssl. As a result of this the session id callbacks will not be called if the
session ticket callback is successful.