Current SSL module doesn't manage SSL sessions, so any connection must do the full SSL handshake.

SSL/TLS support session restarting, when an old SSL context is used in a new connection, so you don't need to do the full SSL handshake.

This is a huge performance improvement.

I think SSL module should keep a small pool of sessions in core, to reuse. Better yet:

a) In SSL sockets, a method should be added to get the SSL context.

b) When creating a SSL socket, in client mode, a new optional parameter should be accepted, for a SSL context.

c) When creating a SSL socket, in server mode, we have two options: a) provide a dictionary or similar, with different contexts for possible clients connections or, better b) provide a callback the SSL module will call when getting an incoming connection, with a session ID as a parameter. The callback can provide a session SSL state or "None". This second approach allow for session management, like expiration or persistence to disk.

(the second option is equivalent to the first if the dict-like object includes this logic inside)

What do you think?.

bpo-8550 is probably a prerequisite for implementing this properly.

http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html suggests that SSL session caching already occurs by default in server mode:

“SSL_SESS_CACHE_SERVER

Server sessions are added to the session cache. When a client proposes a session to be reused, the server looks for the corresponding session in (first) the internal session cache (unless SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is set), then (second) in the external cache if available. If the session is found, the server will try to reuse the session. This is the default.”

A nice and easy thing to do would be to export the statistics given by http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html# .

Ok, I propose the following plan:

• add a new opaque type allowing to wrap a SSL_SESSION
• add a get_session() method to SSLSocket, returning the current session
• add an optional "session=..." parameter to SSLContext.wrap_socket, allowing to specify a session which we hope to reuse during the handshake

There is however, one complication (from OpenSSL man pages):

"""SSL_SESSION objects keep internal link information about the session cache list, when being inserted into one SSL_CTX object's session cache. One SSL_SESSION object, regardless of its reference count, must therefore only be used with one SSL_CTX object (and the SSL objects created from this SSL_CTX object)."""

So we would somehow also need to keep a pointer to the SSL context in our session object wrapper, and check that the session isn't reused with another context... (yuck)

I'm going to implement sessions in bpo-19500.