Re: [PATCH] Dynamic SSL Certificate Generation

On 11/11/2010 04:24 PM, Amos Jeffries wrote:
>>>
>>> Over in the dynamic generation code this nasty usage case is implemented
>>> by the http_port contexts and again in the context "storage".
>>>
>>> Specifically on the http_port... if you recall the history of bug
>>> http://bugs.squid-cache.org/show_bug.cgi?id=2586 the destructor of
>>> http_port globals are perfectly capable of cleanly erasing the member
>>> contexts. We had to leave the SSL context leaking until they could be
>>> *RefCounted* (with a full 1->N count) because active connections held
>>> raw-pointers to it long after the "owner" port was closed.

I am reading the SSL_CTX_free man page:

"SSL_CTX_free() decrements the reference count of ctx, and removes the
SSL_CTX object pointed to by ctx and frees up the allocated memory if
the the reference count has reached 0. "

Looks that openSSL library already uses RefCounts internally.
We should not have any problem releasing SSL contexts even if still used
by active connections.
Why are we consider it as a problem?
I am trying to find in squid-dev related discussions but I can not found
any.

>>> Using a TidyPointers there, with get() method in httpsAccept() to attach
>>> to SSL* children is exactly identical logic to our previous attempt at
>>> making the http_port destructor cleanup.
>>
>> hmm, I had forgot this bug.
>> About SSL_CTX objects (and SSL * ?) we may have to use RefCounts. But it
>> is not so simple. You can not just use a different type of pointer.
>
> Yes. So as I see it, until this problems is resolved the http_port will
> need to stay using a raw-pointer.
> The context "storage" containers will need a look to see if they suffer
> the same problem or resolve it somehow.
>
>
>> The major problem is that we are not passing RefCount or TidyPointers to
>> the openSSL library functions. We are passing raw pointers.
>
> If they do not throw that is not a problem. Or if they do throw we much
> catch in our caller where the pointer can be treated to special cleanup.
>
>>
>> From what I can understand the major problem is that on reconfigure
>> there are SSL_CTX objects which are used by some SSL objects so the
>> SSL_CTX objects can not be released.
>
> Yes exactly.
>
>>
>> Most possible is that we should write a new object classes which
>> represents SSL objects and their dependencies on SSL_CTX objects...
>
> Maybe.
>
> Or move to GnuTLS and NSS instead of OpenSSL which has been requested by
> several groups of people. Apparently GnuTLS has a nicer API as well,
> though I have not looked.
>
> Amos
Received on Mon Nov 15 2010 - 15:48:56 MST