On 10/6/06, Mark <[EMAIL PROTECTED]> wrote:
David,
> > I assume this a reason why OpenSSL has the locking callback
> functions.
>
> No. OpenSSL has the locking callback functions so it can
> protect internal
> structures. For example, if two SSL objects internally reference the
> objects.
I am still confused as to why the locking callbacks would protect
internal
structures but not allow access of the SSL objects from different
threads
at the same time (i.e. SSL_read() and SSL_write()).
Let's imagine the case of an SSL_CTX being called in two separate
threads to add certificates and keys -- one RSA, one DSA. (this is,
of course, not currently implemented to my knowledge, but this is an
example.) The SSL_CTX functions, since they access the certificate
chains and key structures internally, can lock the chains and key
structures. They don't directly modify the state of the SSL_CTX,
since the SSL_CTX is merely a set of pointers to other objects.
The SSL object is a different matter. The SSL object contains more
than just pointers, it contains information on what the sequence
numbers are for the incoming and outgoing streams. While OpenSSL
/could/ theoretically lock these itself, it would be a huge waste of
time and resources (locks tend to be a 'limited resource').for every
multithreaded OpenSSL application to abuse the OS's locking system
when it's otherwise unnecessary.
> > As long as you use these it is safe to share the object AFAIK.
>
> Then when wouldn't it be safe to share the object? The
> locking callback functions are required for all multithreaded
applications or
> else OpenSSL can't protect its internal state.
Sorry. I'm not sure what you are saying here.
OpenSSL can protect its internal state by employing locks on the
things that are interface-opaque. It cannot protect its transparent
state, especially as things other than OpenSSL that "just happen to
know how the interface works" may not use the same locking services.
This is why the requirement is pushed to the user to do thread-safety
in these situations.
SSL_read() can update the write state. SSL_write() can update the
read state. All of the SSL_*() functions are thread-unprotected
within the library -- but, as long as you ensure that there's no
concurrent access to the SSL object, you can make use of it in
multiple threads. You just have to make sure it's never used in
multiple threads *simultaneously*, because if that occurs the SSL
layer WILL throw a fatal alert (decryption failure, bad_hmac, or bad
sequence).
So, the condensed version is: If you don't use SSL objects in more
than one thread, you don't need to lock them -- so why should OpenSSL
take the time and waste the resources to lock them (and risk resource
exhaustion for the entire application)? If you do use SSL objects in
more than one thread, you do need to lock them. That is the same type
of requirement pushed onto EVERY multithreaded application that needs
to directly access the same data from multiple threads -- which
implies that you know that you need the locks, and thus must provide
them. (If there's a helper function that does the reading or writing
itself, you can just do the lock and unlock there.)
I hope this helps.
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
