On 2014-06-25 at 17:33, Jeffrey Walton <noloa...@gmail.com> wrote: > On Wed, Jun 25, 2014 at 11:15 AM, Jens Maus <m...@jens-maus.de> wrote: >> ... >> >> Actually, I now understand that I can keep a single SSL_CTX throughout the >> whole lifetime of my application and just assign it to the SSL_new() call. >> However, as I outlined in my last posts, if I change my code like this I run >> into the verify_callback problem and that I have to be able to specify >> different app_data pointers per SSL connection or otherwise I cannot store >> the certificate check results for evaluation by my application. >> > The SSL* should be unique per connection. Is it not possible to keep a > data structure somewhere that uses the SSL* as a key? Then stuff the > data as the value of the pair.
Of course, everything is possible. But if I create a global data structure now that uses the SSL* as a key so that I can search for that one within the verify_callback this would certainly involve that I need to do an own thread locking (e.g. via a mutex). And that’s IMHO very inconvenient if OpenSSL should be in principle able to provide me that functionality so that I can access the correct application specific data even on the SSL* level. > I know there's a difference between connections and sessions (one > connection can have multiple sessions; sessions can be resumed, etc). > So I'm not clear if it will meet all your needs. Here, I am not dealing with sessions at all. Here I simply generate unique connections and each connection get its own SSL*. And now I need to be able to supply my application specific data to the verify callback I specify myself. If I use a unique SSL_CTX* per connection I can perfectly do that, but how to do that if I want to have one global SSL_CTX* throughout my application and just create unique SSL* per connection? How can I then access connection specific data from within the verify callback? That’s the one million dollar question. ;) 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
