Kyle,
Thanks for your long and detailed response.
> 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 no
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
> 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
- Original Message -
From: "Darryl Miles" <[EMAIL PROTECTED]>
To:
Sent: Friday, October 06, 2006 4:50 PM
Subject: Re: Need help: Understanding SSL object in multi-threaded
environment
> Mark wrote:
> > I think it would be helpful for me. If we need t
> > Is it the case that both SSL_read and SSL_write modify the same
> > part of the
> > SSL object ?
>
> Yes, but that's not the issue.
Well ... if this is not the issue? then what is ?
> > Could you give some more details about this? Could you throw some
> > more light
> > on the ssl state maint
Darryl,
> But the SSL_() API set is not re-entrant with respect of the same
> SSL * handle. So you have to serialize all API calls upon
> the same SSL
> * handle. This is why you can't mix SSL_read() with any other
> SSL_() API call on the same handle instance at the same time.
I t
Mark wrote:
I think it would be helpful for me. If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then I would think that OpenSSL would not need
any internal synchronisation, unless it creates its own threads
internally.
But
David,
> I'm not sure why more internal details of how OpenSSL works would be
> helpful. I've already explained the external interface.
I think it would be helpful for me. If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then
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 callb
sl-users@openssl.org
> Subject: RE: Need help: Understanding SSL object in
> multi-threaded environment
>
> David,
>
> > > 1. Is OpenSSL thread-safe?
> > > Yes (with limitations: an SSL connection may not
> > concurrently be used by multiple threads)
> &g
> Is it the case that both SSL_read and SSL_write modify the same
> part of the
> SSL object ?
Yes, but that's not the issue.
> Could you give some more details about this? Could you throw some
> more light
> on the ssl state maintained
> by the SSL object during SSL_read and SSL_write?
I'm not
> 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.
> As long as you use these it is safe to share the object AFAIK.
Then
- Original Message -
From: "David Schwartz" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 05, 2006 3:36 PM
Subject: RE: Need help: Understanding SSL object in multi-threaded
environment
>
> > 1. Is OpenSSL thread-safe?
> > Yes (with limitat
David,
> > 1. Is OpenSSL thread-safe?
> > Yes (with limitations: an SSL connection may not
> concurrently be used by multiple threads)
>
> This means exactly what it says. A single SSL connection may
> not be used concurrently by multiple threads. This means it is illegal
> for one thread to d
> 1. Is OpenSSL thread-safe?
> Yes (with limitations: an SSL connection may not concurrently be used by
> multiple threads)
This means exactly what it says. A single SSL connection may not be used
concurrently by multiple threads. This means it is illegal for one thread to
do a 'write' on the con
- Original Message -
From: "Mark" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 05, 2006 2:49 PM
Subject: RE: Need help: Understanding SSL object in multi-threaded
environment
> you may use the same H_SSL_CTX (handle to an SSL context) in
> concurrent threads.
> you may use the same H_SSL_CTX (handle to an SSL context) in
> concurrent threads. This structure serves as a factory of ssl
> connections.
> You use SSL_new to create SSL connection handles (H_SSL).
> These you can use only within one thread.
> So, you may share H_SSL_CTX, you may not share
Hi,
you may use the same H_SSL_CTX (handle to an SSL
context) in concurrent threads. This structure serves as a factory of ssl
connections.
You use SSL_new to create SSL connection handles (H_SSL).
These you can use only within one thread.
So, you may share H_SSL_CTX, you may not share
H_
18 matches
Mail list logo
