Le 16/10/2015 10:38, Willy Tarreau a écrit :
Thus this sparks a new question : when the cache is disabled, are we sure
to always free the ssl_ctx on all error paths after it's generated ? Or
are we certain that we always pass through ssl_sock_close() ?
That's a good question. By greping on SSL_free, it should be good.
The other problem I'm having is related to how we manage the LRU cache.
Is there a risk that we kill some objects in this cache while they're
still in use ?
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.
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.
In my patch, I chosen to use a specific flag on the connection instead
of doing certificates comparisons. This seems to me easier to understand
and more efficient. But it could be discussed, there are many other
solutions I guess.
I'm not disagreeing with your proposal, it may even end up being the only
solution. I'm just having a problem with keeping this information outside
of the ssl_ctx itself while I think we have to deal with a ref count there
due to it being present both in the tree and in sessions which make use of
it. Very likely we'll have the flag in the connection to indicate that the
cert was generated and must be freed one way or another, but I'm still
bothered by checking the lru_tree when doing this because I fear that it
means that we don't properly track the ssl_ctx's usage.
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 and to track if it is in the cache or not.
finally, we can of course discuss the design of this feature. There is
no problem. I will be happy to find a more elegant way to handle it, if
it is possible.
Ideally we'd have the info in the ssl_ctx itself, but I remember that Emeric
told me a while ago that we couldn't store anything in an ssl_ctx. Thus I
can understand that we can't easily "tag" the ssl_ctx as being statically
or dynamically allocated, which is why I understand the need for the flag
on the connection as an alternative.
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.
Functionally, I agree with you. It would be better to keep info on
SSL_CTX object inside this object. And, at the beginning, I considered
using these functions. But I was not enough confident to do it. Maybe
Emeric can enlighten us.
--
Christopher Faulet
