IF one starts using something global, here some thoughts;

When ssluse creates a SSL_CTX it could keep a global pointer to it. When
ssl_connect is
called again, you just use this SSL_CTX as a paremeter to the SSL.
Adding an SSL
to a SSL_CTX, i.e. the SSL_new(ctx) call only increases a reference
counter in
the SSL_CTX, and SSL_CTX_free decreases it and frees it only when it is
the last,
so you can share it among different SSL objects. Unfortunately, you
don't know the
SSL_CTX_free actually frees the SSL_CTX, so end up with a dangling
global SSL_CTX
unless you count yourself or create one additional SSL or don't free
immediately the last
SSL, and keep this SSL also in a global pointer.

Whenever you change some parameter for any easy handle which that would
require
a different SSL_CTX like the CA filename, free the cached SSL and SSL_CTX,
so the next ssl_connect will start with a fresh one.
This also applies when you create a new easy unless ...
Now, in the presence of the SSL initialisation callback, things may get
complicated,
if you modify things in the SSL_CTX. If this is the case, the
application can
call setoptions before the connect in order to force a new SSL_CTX. This
breaks
existing code that uses the SSL_CTX callback, thus, one could use some
easy_setoption(USE_SHARED_SSL_CTX), which would have internally three
values,
no set, false, true. so that one can have shared ctxs as long as one
does not use
the ssl init callback function etc.

Almost Finally, it seems that the logic of SSL_CTX and SSL is intended
to work in such a way,
that information from the SSL_CTX are cached into the SSL so after
creating of an
SSL you can modify the SSL_CTX so one could use one global SSL_CTX.
*BUT* I am not 100% sure whether this is really correctly implemented.

Now comes into my mind a totally different approach:

Since SSL_CTX represents parameters that can be reused, one can
create one as soon as soon as one sets an option concerning it
with easy_setopt and do everything that is done at the beginning
of ssl_connect,
Then, when using easy_dup_handle, one also has all the options initialised,
one marks, that this is a 'fresh' cache. if one sets any option in any
handle, one should free
the cached SSL_CTX and create a new one.
Again, there would be a problem when you easy_duphandle and then cleanup
the original
one before having an SSL object in it. So when duphandle is called, at
least a fake SSL
needs to be created that keeps the distributed SSL_CTX alive until
SSL_connect creates
the SSL object for the connection, the intermediate would be freed
immediately after
the SSL_new.

In this solution, the SSL_CTX caches itself, and no global object is
needed.

Shmulik Regev wrote:
> Contrary to my original thoughts, the share object turned out to be a
> problematic container for the cached SSL_CTX objects. Why? Because the
> SSL_CTX objects are really used by the connection objects, which in
> turn may outlive all the easy objects. Specifically, a SSL_CTX needs
> to be released ( i.e. returned to the cache and possibly freed) when
> the connection is about to close (in the function Curl_ossl_close).
> Alas, at this point in time, the connection can not rely on the
> existence of a valid easy handle and therefore no way to reach the
> share object (which is referenced by the easy objects).
No, an SSL_CTX does not need to be released when a connection is
released. The SSL object represents
a connection,
>
> There are a couple of ways around that, each with its own problems:
> 1. the connection will keep a pointer to the share object
> 2. the connection cache struct will manage the SSL_CTX cache and not
> the share object
> 3. keep a global lookup table mapping SSL_CTX objects to the relevant
> share objects. I don't like this approach but it is an option
>
> Any other ideas or preferences?
>
> Cheers,
> Shmul
>