Hi Willy,
Le 16/10/2015 19:07, Willy Tarreau a écrit :
The SSL_CTX and SSL objects are reference-counted objects, so there is
no problem.
When a SSL_CTX object is created, its refcount is set to 1. When a SSL
connection use it, it is incremented and when the connection is closed,
it is decremented. Of course, it is also decremented when SSL_CTX_free
is called.
During a call to SSL_free or SSL_CTX_free, its reference count reaches
0, the SSL_CTX object is freed. Note that SSL_free and SSL_CTX_free can
be called in any order.
OK so the unused objects in the tree have a refcount of 1 while the used
ones have 2 or more, thus the refcount is always valid. Good that also
means we must not test if the tree is null or not in ssl_sock_close(),
we must always free the ssl_ctx as long as it was dynamically created,
so that its refcount decreases, otherwise it keeps increasing upon every
reuse.
No. Maybe my explanation was not really clear. The SSL_CTX refcount is
not exposed. It is an internal parameter. So, it is not incremented when
the SSL_CTX is pushed in the cache tree.
The call to SSL_set_SSL_CTX increases the refcount and the call to
SSL_free decrements it (when the connection is closed). And, of course,
the call to SSL_CTX_free decrements it too. The SSL_CTX object is
released when the refcount reaches 0.
For a SSL_CTX object, SSL_CTX_free must be called once. When it is
evicted from the cache tree (or when the tree is destroyed) _OR_ when
the connection is closed if there is no cache tree. If we always release
SSL_CTX objects when the SSL connection is closed, we will have
undefined references for cached objects, leading to a segfault.
So, if a call to SSL_CTX_free is called whilst a SSL connection uses the
corresponding SSL_CTX object, there is no problem. Actually, this
happens when a SSL_CTX object is evicted from the cache. There is no
need to check if it is used by a connection or not.
Not only it is not needed, but we must not.
We do not track any reference count on SSL_CTX, it is done internally by
openssl. The only thing we must do, is to know if it a generated
certificate
I totally agree.
and to track if it is in the cache or not.
And here I disagree for the reason explained above since this is already
covered by the refcount.
The refcount is not incremented when a SSL_CTX object is pushed in the
cache. There is no way to manually increment or decrement it. So, we
must really know if the SSL_CTX object was cached or not when the SSL
connection is closed.
Well, I'm not an openssl guru. It is possible to store and retrieve data
on a SSL_CTX object using SSL_CTX_set_ex_data/SSL_CTX_get_ex_data
functions. But I don't know if this a good practice to use it. And I
don't know if this is expensive or not.
That's also what Rémi suggested. I don't know how it's used, I'm seeing
an index with it and that's already used for DH data, so I don't know how
it mixes (if at all) with this. I'm not much concerned by the access cost
in fact since we're supposed to access it once at session creation and once
during the release. It's just that I don't understand how this works. Maybe
the connection flag is simpler for now.
Well, use SSL_CTX_set_ex_data/SSL_CTX_get_ex_data seems to work. But,
I'm not a SSL expert, so maybe I missed something (and bugs related to
my recent patches show that this is not false modesty...). I sent 2
fixes for this bug [1][2]. If you want I rework one of them, I will be
happy to do it.
[1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html
[2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html
Regards
--
Christopher Faulet
