Am 25.06.2014 um 18:22 schrieb Michael Wojcik <michael.woj...@microfocus.com>:
> […] > 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