The current implementation of TLS server emits resumeSession event for sessions that are resumed via TLS session ticket extension. Such sessions are not announced via newSession, thus resumeSession handler always returns null. To do that, the handler has to do an expensive query to an external store first. This hurts the performance of node TLS/HTTPS server.

See also #5853.

More details:

1. In order to resume sessions, you have to specify session in client connection options. This applies to both TLSv1 and SSLv3 protocols. (Note that in TLS server event newSession not fired for TLSv1 client #5853 I incorrectly claimed that it is not necessary for TLSv1).
2. In order to resume TLS sessions the old way (without session tickets), you have to install newSession/resumeSession listeners on your server (for both single-process and cluster scenarios).
3. Establishment of a connection via TLS session ticket extension is slowed down now, because resumeSession has to query the external store for a session that was never stored there.

As a developer, you have to decide which clients will have degraded performance:

• either clients not supporting TLS session ticket extensions, like Internet Explorer and mostly everything using Microsoft's TLS stack.
• or clients sending TLSv1 session tickets.

I looked at the commit 8e0c830 and I understand why it will be difficult to solve this issue (we need to do an async call to javascript from a sync openssl callback), but that fact IMO does not justify leaving the problem unsolved.

Also note that a presence of a session ticket in client hello is not enough to restore a session, the ticket could be invalid or expired. Perhaps we could install our own SSL_CTX_set_tlsext_ticket_key_cb [1] to make sure the same algorithm is used by openssl and our hello parser? See diff [2] from the Apache revision [3] for a sample implementation.

P.S. TLS session ticket extension actually does not work in the cluster (see #5871). The result is a double slowdown - external session store is consulted and the session has to be renegotiated.

/cc @indutny

[1] http://www.mail-archive.com/[email protected]/msg30246/SSL_CTX_set_tlsext_ticket_key_cb.pod
[2] https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?r1=1200040&r2=1200039&pathrev=1200040
[3] https://svn.apache.org/viewvc?view=revision&revision=1200040