Am 25.06.2014 um 18:22 schrieb Michael Wojcik <[email protected]>:
> […]
> To retrieve it in the callback, you use the code Viktor provided. First you
> get the index of the SSL* object in the X509_STORE_CTX's "external data"
> collection:
>
> int ssl_idx = SSL_get_ex_X509_STORE_CTX_idx();
>
> Then you use that index to get the SSL* itself:
>
> SSL *conn = X509_STORE_CTX_get_ex_data(store_ctx, ssl_idx);
>
> (Where "store_ctx" is the second parameter passed to the verify callback).
>
> Of course you can do this in a single line:
>
> SSL *conn = X509_STORE_CTX_get_ex_data(store_ctx,
> SSL_get_ex_X509_STORE_CTX_idx());
>
> That's it.
Thank you Michael for this very nice description. When Steven sent the link to
the documentation around I already had a look at the API and found out about
X509_STORE_CTX_get_ex_data() myself. However, there is still one open point
which I feel needs to be addressed before I can actually implement it that way:
> Now, if you need additional application-specific information in the callback,
> the best thing is to add it as external data in the SSL object:
>
> /* Create an index for our data in the SSL object */
> int get_index(void) {
> /* Serialize as necessary */
> static int index = -1;
> if (index < 0) index = SSL_get_ex_new_index(...);
> return index;
> }
>
> /* After creating the SSL object */
> SSL_set_ex_data(conn, get_index(), my_data_ptr);
>
> ...
>
> /* In the verify callback, or wherever */
> my_data_ptr = SSL_get_ex_data(conn, get_index());
>
> But if all you need in the callback is the SSL object, you needn't worry
> about all that.
Exactly, I need more than just the plain SSL object within the verify callback
because I want to store the individual verify callback results in a connection
specific variable as pointed out in my earlier post.
Now that you have provided the above pseudo-code and due to the point that I
read the documentation about SSL_set_ex_data() I perfectly understand what
Viktor meant. The only thing that still worries me is that particular
get_index() function and the point that you use a static int variable inside
there. The reason for that is, that in multithreaded environments that actually
would involve locking access to „index“ via a separate mutex which IMHO is
sub-optimal, to say the least. In addition, when doing parallel connections
with unique SSL* pointers per connection the above would fail since get_index()
will only return the index number of the first get_index() call in the first
SSL connection. But if two or more parallel SSL connections are initiated you
would AFAICS require a unique index variable per running SSL*. So somehow this
looks to me like a hen vs. egg problem since I need to store the index number
to access the external data outside the verify callback function. Or is there
anything else I can do about that using OpenSSL functionality?
best regards,
jens
--
Jens Maus, Dresden/Germany
http://jens-maus.de/
(Please note a real name change effective since 5.9.2013.
Former name: Jens Langner)
*** Content is authentic only with digital signature ***
smime.p7s
Description: S/MIME cryptographic signature
