Re: Question about thread safety and SSL_CTX* and its SSL*

[Thomas Bailleux]

> Perhaps you're freeing some objects that are owned by the library, or
> continuting to use objects that the library owned and freed.
I don't think so, I'm using the reference counter whenever I can (for instance 
with the trust store). Also, SSL_CTX is never destroyed.

> What you're doing should work, if implemented correctly, but my advice
> is to not use SSL_clear(), rather create a fresh (SSL *) handle for
> each connection.  These are cheap enough to not warrant recycling.
Using a fresh (SSL *) seems to work.

So I guess there is something wrong with SSL_clear() ?

> On 27 Sep 2022, at 18:42, Viktor Dukhovni  wrote:
> 
> On Tue, Sep 27, 2022 at 06:35:47PM +0200, Thomas Bailleux wrote:
> 
>> However, I am still facing issues when I use `SSL_CTX` and `SSL` objects.
>> 
>> I use `SSL_CTX` and `SSL` inside a threaded application. Threads are managed 
>> using pthread primitives.
>> 
>> Basically, I create a `SSL_CTX`, and I fill it depending on the TLS method.
>> At this point, the `SSL_CTX` is final. I never change it again.
>> 
>> Then, I create n `SSL`s from the `SSL_CTX`, and I spawn n pthreads.
>> Each pthread takes the ownership of a single `SSL`. Finally, each
>> pthread is going to use its `SSL` object for establishing some TLS
>> connections.  `SSL` objects never get destroyed, instead I use
>> `SSL_clear` for kind of recycling them.
> 
> Perhaps you're freeing some objects that are owned by the library, or
> continuting to use objects that the library owned and freed.
> 
>> My question is: Is my app thread safe ? I wonder, because I am facing
>> random null deref.  If I create a `SSL_CTX` for each thread,
>> everything is fine.
> 
> What you're doing should work, if implemented correctly, but my advice
> is to not use SSL_clear(), rather create a fresh (SSL *) handle for
> each connection.  These are cheap enough to not warrant recycling.
> 
> -- 
>Viktor.

Re: Question about thread safety and SSL_CTX* and its SSL*

[Viktor Dukhovni]

On Tue, Sep 27, 2022 at 06:35:47PM +0200, Thomas Bailleux wrote:

> However, I am still facing issues when I use `SSL_CTX` and `SSL` objects.
> 
> I use `SSL_CTX` and `SSL` inside a threaded application. Threads are managed 
> using pthread primitives.
> 
> Basically, I create a `SSL_CTX`, and I fill it depending on the TLS method.
> At this point, the `SSL_CTX` is final. I never change it again.
> 
> Then, I create n `SSL`s from the `SSL_CTX`, and I spawn n pthreads.
> Each pthread takes the ownership of a single `SSL`. Finally, each
> pthread is going to use its `SSL` object for establishing some TLS
> connections.  `SSL` objects never get destroyed, instead I use
> `SSL_clear` for kind of recycling them.

Perhaps you're freeing some objects that are owned by the library, or
continuting to use objects that the library owned and freed.

> My question is: Is my app thread safe ? I wonder, because I am facing
> random null deref.  If I create a `SSL_CTX` for each thread,
> everything is fine.

What you're doing should work, if implemented correctly, but my advice
is to not use SSL_clear(), rather create a fresh (SSL *) handle for
each connection.  These are cheap enough to not warrant recycling.

-- 
Viktor.

Question about thread safety and SSL_CTX* and its SSL*

[Thomas Bailleux]

Hello OpenSSL.

I know that thread safety in OpenSSL is a much discussed topic. I have read 
several GitHub issues[1], Stack Overflow threads[2], and I have read the blog 
paper[3] too.

However, I am still facing issues when I use `SSL_CTX` and `SSL` objects.

I use `SSL_CTX` and `SSL` inside a threaded application. Threads are managed 
using pthread primitives.

Basically, I create a `SSL_CTX`, and I fill it depending on the TLS method.
At this point, the `SSL_CTX` is final. I never change it again.

Then, I create n `SSL`s from the `SSL_CTX`, and I spawn n pthreads. Each 
pthread takes the ownership of a single `SSL`. Finally, each
pthread is going to use its `SSL` object for establishing some TLS connections.
`SSL` objects never get destroyed, instead I use `SSL_clear` for kind of 
recycling them.

My question is: Is my app thread safe ? I wonder, because I am facing random 
null deref.
If I create a `SSL_CTX` for each thread, everything is fine.

Best regards,

Thomas B.

[1] https://github.com/openssl/openssl/issues/2165 
<https://github.com/openssl/openssl/issues/2165>
[2] https://stackoverflow.com/questions/40583314/ssl-new-thread-safe-or-not 
<https://stackoverflow.com/questions/40583314/ssl-new-thread-safe-or-not> 
[3] https://www.openssl.org/blog/blog/2017/02/21/threads/ 
<https://www.openssl.org/blog/blog/2017/02/21/threads/> 

NB: I'am using OpenSSL 1.1.1, from git.

Re: RAND_bytes() thread safety

[Matt Caswell]

On 14/11/2020 11:00, Rahul Godbole wrote:
> Is OpenSSL function RAND_bytes () thread safe?

Short answer: Yes

Longer answer: Yes assuming that:
- you are using >= OpenSSL 1.1.0
or
- you are using OpenSSL 1.0.2 or below and you have set up the locking
callbacks

AND

- You have not compiled OpenSSL with "no-threads"

Matt

RAND_bytes() thread safety

[Rahul Godbole]

Hi

Is OpenSSL function RAND_bytes () thread safe?

Thanks
Rahul

RAND_bytes() thread safety

[Rahul Godbole]

Hi

Is the OpenSSL function RAND_bytes() thread safe? I do not find any mention
about thread safety in its man page.

Thanks
Rahul

Re: [openssl-users] X509_STORE manipulations and thread-safety

[hokusai]

> Objects are copied and ref-counted when an SSL is created from an SSL_CTX...


To me this seems is only half-true. In SSL_new() we see that only the own certificate/key gets duplicated with ssl_cert_dup(ctx->cert), as for the trusted stuff in X509_STORE only the pointer is copied.
Inside ssl_verify_cert_chain() when a temporary X509_STORE_CTX is created it will share the X509_STORE instance with all other connections.

Therefore we must assume that replacing the X509_STORE instance from an other thread during running connections is definitely unsafe.
Alternatively, do you think the reference counter system is able to correctly handle additions/removals to/from the existing X509_STORE obj list instead of replacing it?   

 

Fabrizio

 


Gesendet: Mittwoch, 12. August 2015 um 15:38 Uhr
Von: "Salz, Rich" 
An: "openssl-users@openssl.org" 
Betreff: Re: [openssl-users] X509_STORE manipulations and thread-safety

> Is it safe to have a thread reload trusted certificates and crls into a SSL_CTX's X509_STORE while connections are running in other threads, especially when considering renegotiations?

As a general rule, multi-thread simultaneous access doesn't work and will often make things go ka-boom. But generally ongoing connections use SSL objects, not SSL_CTX, so a brief locking scheme should be okay. Objects are copied and ref-counted when an SSL is created from an SSL_CTX...

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509_STORE manipulations and thread-safety

[Salz, Rich]

> Is it safe to have a thread reload trusted certificates and crls into a 
> SSL_CTX's X509_STORE while connections are running in other threads, 
> especially when considering renegotiations?

As a general rule, multi-thread simultaneous access doesn't work and will often 
make things go ka-boom.  But generally ongoing connections use SSL objects, not 
SSL_CTX, so a brief locking scheme should be okay.  Objects are copied and 
ref-counted when an SSL is created from an SSL_CTX...

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] X509_STORE manipulations and thread-safety

[hokusai]

Hello All,

 


Is it safe to have a thread reload trusted certificates and crls into a SSL_CTX's X509_STORE while connections are running in other threads, especially when considering renegotiations?

The idea would be to replace the instance of X509_STORE with a new one or is there a better way to do it?

 

Pseudo code of the store updater thread:

 

ReloadTrustedStore(SSL_CTX* ctx)
{
    X509_STORE *newStore = X509_STORE_new();
    CopySettingsfromExistingStore(newStore, ctx)
    LoadCertsCrls(newStore);
    SSL_CTX_set_cert_store(ctx, newStore);    
}

 

Thanks

Fabrizio

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Thread Safety of ssl_write()

[Krzysztof Kwiatkowski]

Hi,

It is unsafe to access SSL context from 2 different threads. When you
call SSL_write function, the SSL context object state is changed.
Probably you can end up in case that data is not delivered to the peer.

Kris

On Tue, 2014-09-30 at 13:46 +, S P, Swaroop (NSN - IN/Bangalore)
wrote:
> Hi,
>  
> We have a use-case where multiple threads are required to use the same
> SSL context [created using SSL_new()] and do a ssl_write().
> So, there might be a scenario where two threads (or more) can be doing
> a ssl_write() on the same SSL context at exactly the same time.
> Is this safe?
> Is the data delivered properly to the peer?
>  
> Regards,
> Swaroop
>  


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Thread Safety of ssl_write()

[Michael Wojcik]

[Top-posted because Outlook can't deal correctly with HTML email.]

> Is this safe?

No. There's a lot of state in the SSL object (which is not an "SSL context", in 
OpenSSL terminology; the SSL_CTX object is an "SSL context"), and the SSL/TLS 
methods' write functions do not serialize access to it. Look at ssl3_write in 
ssl/s3_lib.c, for example, and consider what happens if two threads trigger 
renegotiation at the same time, or if two threads try to send the first message 
after the handshake.

I can imagine applications where multiple threads write to the same SSL/TLS 
conversation (not everything is request-response), but in that case, the 
application layer will have to serialize access to the conversation. And 
remember that OpenSSL has to be built for thread safety, and that its error 
handling is thread-based, so each thread needs to check its error state.

> Is the data delivered properly to the peer?

Define "properly". If you just mean that sends shouldn't be interleaved, then 
serializing access to the conversation should suffice, since the underlying BIO 
is a streaming abstraction. Non-blocking I/O would complicate that - you'd have 
to ensure a send completes before releasing the conversation.

Michael Wojcik
Technology Specialist, Micro Focus


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of S P, Swaroop (NSN - IN/Bangalore)
Sent: Tuesday, 30 September, 2014 09:46
To: openssl-users@openssl.org
Subject: Thread Safety of ssl_write()

Hi,

We have a use-case where multiple threads are required to use the same SSL 
context [created using SSL_new()] and do a ssl_write().
So, there might be a scenario where two threads (or more) can be doing a 
ssl_write() on the same SSL context at exactly the same time.
Is this safe?
Is the data delivered properly to the peer?

Regards,
Swaroop



Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report 
this email as spam.


This message has been scanned for malware by Websense. www.websense.com

Thread Safety of ssl_write()

[S P, Swaroop (NSN - IN/Bangalore)]

Hi,

We have a use-case where multiple threads are required to use the same SSL 
context [created using SSL_new()] and do a ssl_write().
So, there might be a scenario where two threads (or more) can be doing a 
ssl_write() on the same SSL context at exactly the same time.
Is this safe?
Is the data delivered properly to the peer?

Regards,
Swaroop

Thread safety questions in OpenSSL 1.0.1

[Jason Schultz]

Back in November a question(and response) were posted regarding thread safety 
in the 1.0.1 branch of OpenSSL:
 
http://www.mail-archive.com/openssl-users@openssl.org/msg69322.html
 
In the response to the questions, the user states he removed the thread ID 
callback function and the call to CRYPTO_set_id_callback(). However, there was 
nothing as far as follow up to verify this was correct.
 
Is there information out there(perhaps another thread on this list I am unable 
to find) someone could link me to that discusses the differences in ensuring 
thread safety between 0.9.8 and 1.0.1?
 
Thanks.
 
  

RE: thread-safety questions on 1.0.1c

[Jeremy Farrell]

> From: Thomas Eckert [mailto:thomas.eck...@sophos.com]
> Sent: Tuesday, November 20, 2012 9:44 AM
> 
> I am seeing lots of errors whose error message reads
>   "S : 2851965808:error:14092105:SSL
> routines:SSL3_GET_SERVER_HELLO:wrong cipher returned:s3_clnt.c:963:"
> if I run it in at least several (8+) threads. Single threaded it's all
> doing fine, so I guess the kind of issue is obvious.
> 
> I assumed this was related to my code initiating OpenSSL thread-safety
> with deprecated calls, e.g.
>  CRYPTO_set_locking_callback(ssl_lock);
>  CRYPTO_set_id_callback(ssl_get_thread_id);
> where ssl_lock() simply uses glib mutexes to do the locking and
> ssl_get_thread_id() uses pthread_self() to return the thread's id.
> These
> have worked perfectly in the past for a long time so I didn't expect
> them to be the source of the problem. Anyway, since the docs at
> http://www.openssl.org/docs/crypto/threads.html advise to use the new
> calls with any version >= 1.0.0 I replaced
>  CRYPTO_set_locking_callback(ssl_lock);
> with
>  CRYPTO_THREADID_set_callback(threadid_func));
> where threadid_func is just
>  CRYPTO_THREADID_set_numeric(id, pthread_self());

That threads man page got updated as part of these changes, which was a great 
idea, but unfortunately it got mangled in the process. In particular, while it 
talks in detail about locking and thread ID callbacks it apparently no longer 
gives any clue how to actually set the locking callback. It also now contains a 
lot of stuff which appears to be internal implementation detail and APIs which 
are private to the library, getting in the way of finding the required 
information for the external APIs (the most important bit of which is no longer 
there, or it's ended up so well hidden that I can't find it at least).

My understanding is that you still need to call CRYPTO_set_locking_callback() 
to register your locking function, as before. Without that you have no locking, 
leading to what you're seeing.

What's really changed is the thread ID mechanism. The biggest change for people 
working on "normal" OSes (such as Windows, and UNIX and other POSIXy things) is 
that you no longer need thread ID callbacks at all. If your OS is Windows, or 
if errno has a different address in each thread, then the built-in thread ID 
mechanism is all you need.

My code runs only on such server OSes, and my change when moving up to 1.0.0 
and later was simply to remove my dodgy thread ID callback function and the 
call to CRYPTO_set_id_callback(). All the standard and dynamic locking stuff 
stays the same.

I can't say for certain that this is correct, and I've only just made the 
change and haven't yet tested it thoroughly, but it's my understanding after 
some thinking and digging.

Not that this explains why you started seeing the problem when you still had 
your original locking callback in place, that is worrying ...

Regards,
 jjf


> and also added the dynamic locking functions. Before, though, I checked
> the OpenSSL sources and I got the feeling those dynamic locks would
> only
> rarely (if at all) get get called. So far, my dynamic locks have not
> been called once by OpenSSL - confirming this here
> http://fixunix.com/openssl/359957-re-clarification-questions-openssl-
> thread-safe-support.html
> 
> In my application, there is only one global context and it is used to
> set up all SSL sessions. To be able to do so, it is modified heavily
> (read: for every connection) prior to calling SSL_new(ssl_ctx). This
> may
> include setting the ciphers, the certificates, SNI, etc., depending on
> the situation and the needs for that connection. Since I couldn't find
> a
> locking callback inside the SSL_CTX, the whole code is protected by a
> mutex on my end so I am fairly sure concurrent access on the SSL_CTX in
> my code is not the problem. But maybe after calling SSL_new(ssl_ctx)
> there's some magic going on behind the doors which accesses the context
> again ? Of course, such access would no longer be safe and would need
> to
> be controlled (how?).
> 
> As a side note: Am I correct in assuming the 'old'
> CRYPTO_set_locking_callback() function did not get a replacement, as
> did
> CRYPTO_set_id_callback() ? I couldn't find any such replacement in the
> sources and I suppose that's one of the places where the dyn locks are
> supposed to come in, in future versions.
> 
> Anyone got an idea on how to procede ?
> 
> Regards,
>   Thomas
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

thread-safety questions on 1.0.1c

[Thomas Eckert]

I am seeing lots of errors whose error message reads
 "S : 2851965808:error:14092105:SSL 
routines:SSL3_GET_SERVER_HELLO:wrong cipher returned:s3_clnt.c:963:"
if I run it in at least several (8+) threads. Single threaded it's all 
doing fine, so I guess the kind of issue is obvious.


I assumed this was related to my code initiating OpenSSL thread-safety 
with deprecated calls, e.g.

CRYPTO_set_locking_callback(ssl_lock);
CRYPTO_set_id_callback(ssl_get_thread_id);
where ssl_lock() simply uses glib mutexes to do the locking and 
ssl_get_thread_id() uses pthread_self() to return the thread's id. These 
have worked perfectly in the past for a long time so I didn't expect 
them to be the source of the problem. Anyway, since the docs at 
http://www.openssl.org/docs/crypto/threads.html advise to use the new 
calls with any version >= 1.0.0 I replaced

CRYPTO_set_locking_callback(ssl_lock);
with
CRYPTO_THREADID_set_callback(threadid_func));
where threadid_func is just
CRYPTO_THREADID_set_numeric(id, pthread_self());

and also added the dynamic locking functions. Before, though, I checked 
the OpenSSL sources and I got the feeling those dynamic locks would only 
rarely (if at all) get get called. So far, my dynamic locks have not 
been called once by OpenSSL - confirming this here 
http://fixunix.com/openssl/359957-re-clarification-questions-openssl-thread-safe-support.html


In my application, there is only one global context and it is used to 
set up all SSL sessions. To be able to do so, it is modified heavily 
(read: for every connection) prior to calling SSL_new(ssl_ctx). This may 
include setting the ciphers, the certificates, SNI, etc., depending on 
the situation and the needs for that connection. Since I couldn't find a 
locking callback inside the SSL_CTX, the whole code is protected by a 
mutex on my end so I am fairly sure concurrent access on the SSL_CTX in 
my code is not the problem. But maybe after calling SSL_new(ssl_ctx) 
there's some magic going on behind the doors which accesses the context 
again ? Of course, such access would no longer be safe and would need to 
be controlled (how?).


As a side note: Am I correct in assuming the 'old' 
CRYPTO_set_locking_callback() function did not get a replacement, as did 
CRYPTO_set_id_callback() ? I couldn't find any such replacement in the 
sources and I suppose that's one of the places where the dyn locks are 
supposed to come in, in future versions.


Anyone got an idea on how to procede ?

Regards,
 Thomas
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL on Win => Thread Safety

[Jeffrey Walton]

Hi Jakob,

I do agree with you that a NULL SecAttrib will get you a default
descriptor. After sending the post (before you jumped on it), I wanted
to preface the statement with "some hand waiving." What constitutes a
default descriptor is somewhat of a moving target when over the
Windows OS's and its usually easiest to explain it as "Everyone, Full
Control" though it might be weakened to "Current User, Full Control".
Unless, of course, two processes are engaged in IPC/Synchronization,
and one process is a "Local Service" and the other is a desktop
program running under "Current User". In this case, a NULL SecAtrrib
on a named securable object acts like "Everyone, Full Control".
Confer: What did the analysis Paget's Shatter Attack reveal? How did
Microsoft remediate it?

I suppose I should bounce it back at you: why is it appropriate that
either "Administrators", Local Service", or "SYSTEM" (any one of whom
might show up due to a default descriptor) have access to my mutex,
when all that is required is a single ACE of {Current User,
STANDARD_RIGHTS_READ|SYNCHRONIZE}?

Jeff

On Fri, Jun 25, 2010 at 5:24 PM, Jakob Bohm  wrote:
> Read my post again,
>
> I did not say that NULL DACLs are not obviously dangerous (they are
> and have been deprecated since the mid 1990s).  I said that a
> NULL SECURITY_ATTRIBUTES does not result in a NULL DACL but something
> much less dangerous.
>
> If you found a way to make the SRM assign a NULL DACL in response to
> a NULL lpSecurityDescriptor, then you found yet another security bug in the
> SRM itself (congratulations).
>
> PS: One small correction to my post: For at least some APIs, Windows 9x
> will not object to a non-NULL lpSecurityDescriptor anyway.
>
>
> On 25-06-2010 21:08, Jeffrey Walton wrote:
>>
>> Hi Jakob,
>>
>> Boy this is an argumentative list at times
>>
>> As a Win32 guy, I understand your the finer points you are making.
>> Unfortunately, there are implicit assumptions that are being made
>> which are undermining your arguments. Put another way, its the attacks
>> which you *don't* know about which will burn you with these NULL
>> DACLs.
>>
>> In the discussion with Patrick Eisenacher [2], I claimed a wilcard
>> cert violated principle of least privilege. Patrick pressed me for the
>> next attack using wildcard certs, which I did not have. In this case,
>> I have the next attacks. We have not released the paper yet, though
>> its been shared with those affected, including Microsoft.
>>
>> The response to "This is plain wrong" is inlined. I did not claim a
>> NULL DACL violates Principle of Least Privilige this time around (I'm
>> trying to learn from my mistakes). I cited the guys who wrote the
>> proverbial security book at Microsoft. Hopefully their opinion will be
>> weighed more appropriately.
>>
>> I could also cite Richter, but he usually offers Win32 best practices
>> (Richter will also tell you not to use NULL DACLs). But its fairly
>> obvious (to me) if one is going to discard a security related best
>> practice and the SDLC, one is probably not going to follow Win32 best
>> practices (is this 'too much' of a leap?).
>>
>> On Fri, Jun 25, 2010 at 5:01 AM, Jakob Bohm  wrote:
>>>
>>> On 24-06-2010 23:31, Jeffrey Walton wrote:

 [SNIP]

 Critical sections have the added benefit that you don't have to supply
 a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
 folks leave unspecified (NULL) so the net effect is "Everyone, Full
 Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
 security audit.

>>>
>>> This is plain wrong, and I certainly hope nobody uses this
>>> misunderstanding
>>> in security audits.
>>>
>>
>> NULL DALCS and other Dangerous ACE Types: "A NULL DACL is a way of
>> granting all accessd to all users of an object, including attackers. I
>> sometimes quip that NULL DACL == No Defense. And its absolutely true.
>> If you don't care that anyone can do anything to your object -
>> including read from it, write to it, delete existing data, modify
>> existing data, and deny others access to the object - a NULL DACL is
>> fine. However, I have yet to see a product for which such a
>> requirement is of benefit, which, of course, completely rules out the
>> use of NULL DACLs in your product". [1]
>>
>>>
>>> [SNIP]
>>>
>>
>> Jeff
>>
>> [1] Howard and LeBlanc, 'Writing Secure Code', ISBN 0-7356-1722-8, p 195.
>> [2] http://www.mail-archive.com/openssl-users@openssl.org/msg61152.html
>
> __
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-us...@openssl.org
> Automated List Manager                           majord...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@op

Re: OpenSSL on Win => Thread Safety

[Jakob Bohm]

Read my post again,

I did not say that NULL DACLs are not obviously dangerous (they are
and have been deprecated since the mid 1990s).  I said that a
NULL SECURITY_ATTRIBUTES does not result in a NULL DACL but something
much less dangerous.

If you found a way to make the SRM assign a NULL DACL in response to
a NULL lpSecurityDescriptor, then you found yet another security bug in 
the SRM itself (congratulations).


PS: One small correction to my post: For at least some APIs, Windows 9x
will not object to a non-NULL lpSecurityDescriptor anyway.


On 25-06-2010 21:08, Jeffrey Walton wrote:

Hi Jakob,

Boy this is an argumentative list at times

As a Win32 guy, I understand your the finer points you are making.
Unfortunately, there are implicit assumptions that are being made
which are undermining your arguments. Put another way, its the attacks
which you *don't* know about which will burn you with these NULL
DACLs.

In the discussion with Patrick Eisenacher [2], I claimed a wilcard
cert violated principle of least privilege. Patrick pressed me for the
next attack using wildcard certs, which I did not have. In this case,
I have the next attacks. We have not released the paper yet, though
its been shared with those affected, including Microsoft.

The response to "This is plain wrong" is inlined. I did not claim a
NULL DACL violates Principle of Least Privilige this time around (I'm
trying to learn from my mistakes). I cited the guys who wrote the
proverbial security book at Microsoft. Hopefully their opinion will be
weighed more appropriately.

I could also cite Richter, but he usually offers Win32 best practices
(Richter will also tell you not to use NULL DACLs). But its fairly
obvious (to me) if one is going to discard a security related best
practice and the SDLC, one is probably not going to follow Win32 best
practices (is this 'too much' of a leap?).

On Fri, Jun 25, 2010 at 5:01 AM, Jakob Bohm  wrote:

On 24-06-2010 23:31, Jeffrey Walton wrote:


[SNIP]

Critical sections have the added benefit that you don't have to supply
a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
folks leave unspecified (NULL) so the net effect is "Everyone, Full
Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
security audit.



This is plain wrong, and I certainly hope nobody uses this misunderstanding
in security audits.



NULL DALCS and other Dangerous ACE Types: "A NULL DACL is a way of
granting all accessd to all users of an object, including attackers. I
sometimes quip that NULL DACL == No Defense. And its absolutely true.
If you don't care that anyone can do anything to your object -
including read from it, write to it, delete existing data, modify
existing data, and deny others access to the object - a NULL DACL is
fine. However, I have yet to see a product for which such a
requirement is of benefit, which, of course, completely rules out the
use of NULL DACLs in your product". [1]



[SNIP]



Jeff

[1] Howard and LeBlanc, 'Writing Secure Code', ISBN 0-7356-1722-8, p 195.
[2] http://www.mail-archive.com/openssl-users@openssl.org/msg61152.html


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL on Win => Thread Safety

[Jeffrey Walton]

Hi Jakob,

Boy this is an argumentative list at times

As a Win32 guy, I understand your the finer points you are making.
Unfortunately, there are implicit assumptions that are being made
which are undermining your arguments. Put another way, its the attacks
which you *don't* know about which will burn you with these NULL
DACLs.

In the discussion with Patrick Eisenacher [2], I claimed a wilcard
cert violated principle of least privilege. Patrick pressed me for the
next attack using wildcard certs, which I did not have. In this case,
I have the next attacks. We have not released the paper yet, though
its been shared with those affected, including Microsoft.

The response to "This is plain wrong" is inlined. I did not claim a
NULL DACL violates Principle of Least Privilige this time around (I'm
trying to learn from my mistakes). I cited the guys who wrote the
proverbial security book at Microsoft. Hopefully their opinion will be
weighed more appropriately.

I could also cite Richter, but he usually offers Win32 best practices
(Richter will also tell you not to use NULL DACLs). But its fairly
obvious (to me) if one is going to discard a security related best
practice and the SDLC, one is probably not going to follow Win32 best
practices (is this 'too much' of a leap?).

On Fri, Jun 25, 2010 at 5:01 AM, Jakob Bohm  wrote:
> On 24-06-2010 23:31, Jeffrey Walton wrote:
>>
>> [SNIP]
>>
>> Critical sections have the added benefit that you don't have to supply
>> a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
>> folks leave unspecified (NULL) so the net effect is "Everyone, Full
>> Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
>> security audit.
>>
>
> This is plain wrong, and I certainly hope nobody uses this misunderstanding
> in security audits.
>

NULL DALCS and other Dangerous ACE Types: "A NULL DACL is a way of
granting all accessd to all users of an object, including attackers. I
sometimes quip that NULL DACL == No Defense. And its absolutely true.
If you don't care that anyone can do anything to your object -
including read from it, write to it, delete existing data, modify
existing data, and deny others access to the object - a NULL DACL is
fine. However, I have yet to see a product for which such a
requirement is of benefit, which, of course, completely rules out the
use of NULL DACLs in your product". [1]

>
> [SNIP]
>

Jeff

[1] Howard and LeBlanc, 'Writing Secure Code', ISBN 0-7356-1722-8, p 195.
[2] http://www.mail-archive.com/openssl-users@openssl.org/msg61152.html
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL on Win => Thread Safety

[Jakob Bohm]

On 24-06-2010 23:31, Jeffrey Walton wrote:

Hi Massimiliano,

If the locks need to be shared across processes, use a Mutex (the
mutexes can be named for separate processes, or the mutex can be
unnamed if Object Handle Inheritance is used (a flag to CreateProcess,
which is similar to fork(2))).

Otherwise, use a CRITICAL_SECTION. The critical section is more
efficient when only threads of a single process will access shared
data. The efficiency comes from a user land spin, which side steps the
kernel transition if possible. If the spin fails, the thread will have
to transition (the CRITICAL_SECTION is *really* backed by an Event
Object).



Please note that Win32 locking is already built into openssl (see my
other post).


Critical sections have the added benefit that you don't have to supply
a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
folks leave unspecified (NULL) so the net effect is "Everyone, Full
Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
security audit.



This is plain wrong, and I certainly hope nobody uses this 
misunderstanding in security audits.


There are 4 levels of indirection for Win32 calls that take a 
SECURITY_ATTRIBUTES* as argument, and the (standard) implications

of passing NULL or non-NULL at each level differs.

1. If you pass NULL for the (SECURITY_ATTRIBUTES*) argument, the
handle will not be inherited across CreateProcess, and the object
created (if any) will get the context specific default (usually
good enough) security permissions.  For Files/Registry Keys/Active 
Directoy Objects etc. The default permissions are inherited from

the folder the new object is placed in.  For Events, Mutexes, Threads
and other such "parentless" objects, the default permissions are
specified in the log-in token of the calling thread/process.  Usually
this grants access to the user himself and to trusted operating system
processes, but you can change that if you know what you are doing.
Note that this is the exact same permissions which control the
ability to debug or otherwise manipulate your process in its entirety,
so unless you change those permissions first, changing the default
permissions is rather pointless.

2. If you pass NULL for the lpSecurityDescriptor member of a real
SECURITY_ATTRIBUTES structure, the handle may be inherited across
CreateProcess according to the boolean field in SECURITY_ATTRIBUTES,
but the permissions assigned are still the default as above.
Beware that if you pass non-NULL for lpSecurityDescriptor, your
call will fail on Windows 95/98/Me because the ACL features are
not implemented by those systems.

3. If you pass an actual SECURITY_DESCRIPTOR opaque object in the
lpSecutityDescriptor field, but do not set the "DACL" part of that
security descriptor, the DACL will still be set to the default value
as above, but you get a chance to override the 3 other pieces of
security information: Owning User (as in UNIX chown), Owning Group
(as in UNIX chown) and Audit Logging descriptor (SACL).

4. If you actually go to the trouble of setting up all the previous
structures, AND explicitly sets the DACL in it to NULL rather than
unassigned or a carefully written value, then you create an insecure
object accessible to all accounts, even the "null session" account which 
is not even a member of EveryOne.  This is highly depreciated,

and Microsoft has repeatedly hinted that this feature might one day
go away.


P.S.

Bizarrely, in many versions of Windows, unnamed Event and Mutex object 
do not store or enforce their security settings.  I guess the designers
thought that since such objects can only be passed around via 
inheritance and handle duplication, there can be no unauthorized access

attempts, but they kind of forgot about the permission changing options
in DuplicateHandle().
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL on Win => Thread Safety

[Jakob Bohm]

On 24-06-2010 19:25, Massimiliano Pala wrote:

Hi all,

I have a question for Win coders.. I am porting LibPKI, which is based on
OpenSSL, to Win OSes. On UNiX OSes we used pthread to initialize support
for threads in OpenSSL.

What is the best practice for Win OS ? Does anybody have some sample code
around ? In particular, I am referring to the code like:



It seams that the needed thread safety code is already part of openssl
itself (see crypto/threads/th-lock.c), and I certainly hope this is now
part of the standard build on Win32 as that platform uses threads a lot.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL on Win => Thread Safety

[Ger Hobbelt]

On Thu, Jun 24, 2010 at 7:25 PM, Massimiliano Pala <
massimiliano.p...@dartmouth.edu> wrote:

> Hi all,
>
> I have a question for Win coders.. I am porting LibPKI, which is based on
> OpenSSL, to Win OSes. On UNiX OSes we used pthread to initialize support
> for threads in OpenSSL.
>
> What is the best practice for Win OS ? Does anybody have some sample code
> around ? In particular, I am referring to the code like:
>

It depends. Usually, my work had to build on multiple platforms after I was
done, so it was handy to have as little platform-specific code in there as
possible (time restraints and all that), in which case there's a nice
pthreadsWin32 port around so the rest of your code can remain 'platform
agnostic' in a way.

If your final product has to run on Win32/64 only, I suggest going with
Jeffrey Walton's suggestion by going native.
If performance is an issue, you might consider his suggestion too, though
run-time gains will be superficial / political.

In the end it's weighting the maintenance costs versus current time
restraints and project [management] demands, plus your own preference/taste.
pthreadsWin32 is just a pthreads API built on top of those same Win32/64
native locking primitives, so in the end it's just a matter of more or less
transformation/call overhead with each run-time lock request
(pthreads:little or native:none).

When done the 'native' way, I've almost always used critical sections, due
to the reasoning already mentioned by Mr. Watson. Besides, they're faster
than mutexes.

-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
   http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--

Re: OpenSSL on Win => Thread Safety

[Jeffrey Walton]

Hi Massimiliano,

If the locks need to be shared across processes, use a Mutex (the
mutexes can be named for separate processes, or the mutex can be
unnamed if Object Handle Inheritance is used (a flag to CreateProcess,
which is similar to fork(2))).

Otherwise, use a CRITICAL_SECTION. The critical section is more
efficient when only threads of a single process will access shared
data. The efficiency comes from a user land spin, which side steps the
kernel transition if possible. If the spin fails, the thread will have
to transition (the CRITICAL_SECTION is *really* backed by an Event
Object).

Critical sections have the added benefit that you don't have to supply
a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
folks leave unspecified (NULL) so the net effect is "Everyone, Full
Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
security audit.

In Windows, both a Mutex and CRITICAL_SECTION are re-entrant by the
owning thread. Also, Condition Variables were recently introduced, so
they are not available on Windows 200, XP, or Server 2003.

Below are some MSDN resources and the boiler plated code I use to grab
a lock. Its not OpenSSL call back specific,

Jeff

"About Synchronization":
http://msdn.microsoft.com/en-us/library/ms681924%28v=VS.85%29.aspx
"Mutex Objects":
http://msdn.microsoft.com/en-us/library/ms684266%28v=VS.85%29.aspx
"Critical Section Objects":
http://msdn.microsoft.com/en-us/library/ms682530%28VS.85%29.aspx

CRITICAL_SECTION cs;
InitializeCriticalSection(&cs);

BOOL AcquireLock()
{
EnterCriticalSection(&cs);
return TRUE;
}

BOOL ReleaseLock()
{
LeaveCriticalSection(&cs);
return TRUE;
}

SECURITY_ATTRIBUTES sa;
sa = ...

HANDLE mtx;
mtx = CreateMutex(sa, FALSE, NULL);

BOOL AcquireLock()
{
if(!mtx) { return FALSE; }

// Pick a timeout. INIFINTE is not timeout.
DWORD dwWait = WaitForSingleObject(mtx, 5000);
DWORD dwError = GetLastError();
assert(WAIT_OBJECT_0 == dwWait || WAIT_ABANDONED_0 == dwWait);

return  WAIT_OBJECT_0 == dwWait || WAIT_ABANDONED_0 == dwWait;
}

BOOL ReleaseLock()
{
if(!mtx) { return FALSE; }

BOOL bResult = ReleaseMutex(mtx);
DWORD dwError = GetLastError();
assert(FALSE != bResult);

return bResult;
}

On Thu, Jun 24, 2010 at 1:25 PM, Massimiliano Pala
 wrote:
> Hi all,
>
> I have a question for Win coders.. I am porting LibPKI, which is based on
> OpenSSL, to Win OSes. On UNiX OSes we used pthread to initialize support
> for threads in OpenSSL.
>
> What is the best practice for Win OS ? Does anybody have some sample code
> around ? In particular, I am referring to the code like:
>
> void OpenSSL_pthread_init(void) {
>
>        int i;
>
>        lock_cs=OPENSSL_malloc((size_t) (((size_t)CRYPTO_num_locks()) *
>                                                sizeof(pthread_mutex_t)));
>        lock_count=OPENSSL_malloc(((size_t) (CRYPTO_num_locks()) *
>                                                sizeof(long)));
>        for (i=0; i                {
>                lock_count[i]=0;
>                pthread_mutex_init(&(lock_cs[i]),NULL);
>                }
>
>        CRYPTO_set_id_callback((unsigned long (*)())pthreads_thread_id);
>        CRYPTO_set_locking_callback((void (*)())pthreads_locking_callback);
>
>        /* Initializing the OpenSSL dynamic callbacks as well,
>           needed by the nCipher driver */
>        CRYPTO_set_dynlock_create_callback(_dyn_create_callback);
>        CRYPTO_set_dynlock_lock_callback(_dyn_lock_callback);
>        CRYPTO_set_dynlock_destroy_callback(_dyn_destroy_callback);
>
>        return;
> }
>
> One possibility would be to use the port of pthreads for Win.. but I was
> wondering if some of you already went through the process and know the
> best way to provide OpenSSL with thread safety (using native Win calls
> instead of pthread ones?)
>
>
> --
>
> Best Regards,
>
>        Massimiliano Pala
>
> --o
> Massimiliano Pala [OpenCA Project Manager]                   ope...@acm.org
>                                                 project.mana...@openca.org
>
> Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
> PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
> --o
> People who think they know everything are a great annoyance to those of us
> who do.
>                                                           -- Isaac Asimov
>
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL on Win => Thread Safety

[Massimiliano Pala]

Hi all,

I have a question for Win coders.. I am porting LibPKI, which is based on
OpenSSL, to Win OSes. On UNiX OSes we used pthread to initialize support
for threads in OpenSSL.

What is the best practice for Win OS ? Does anybody have some sample code
around ? In particular, I am referring to the code like:

void OpenSSL_pthread_init(void) {

int i;

lock_cs=OPENSSL_malloc((size_t) (((size_t)CRYPTO_num_locks()) *
sizeof(pthread_mutex_t)));
lock_count=OPENSSL_malloc(((size_t) (CRYPTO_num_locks()) *
sizeof(long)));
for (i=0; i

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Reagrding Thread safety in OpenSSL

[Kingston Smiler]

Hi,

I have implemented the static callbacks provided by OpenSSL for thread
safety issue.
After implementing the callback the performance of my program degraded
drartically
since this callback is issued from lot of places while accepting a new
connection.
This callback is issued nearly 200 times from files like ex_data.c ,
ssl_cert.c,md_rand.c,tasn_utl.c,
err.c, t1_srvr.c, ssl_sess.c, ssl_lib.c, s3_lib.c, rsa_eay.c,
rsa_lib.c, x509_vfy.c, x509_lu.c,
bio_lib.c, by_dir.c, x_pubkey.c, p_lib.c etc.

Can any body please confirm that these callbacks will be issued this
many times?  Also can any one please suggest a way to provide the
thread safety with out much impact in the performance.

regards,
S. Kingston Smiler.

On Sep 5, 2007 4:53 PM, Kyle Hamilton <[EMAIL PROTECTED]> wrote:
> Lock your app data separately from the lock that OpenSSL uses to
> protect its own stuff.  Don't manipulate the OpenSSL structures
> directly, though if you've got reason to lock your application data
> you can include the OpenSSL structures in your own locking.
>
> lock(appdata)
> (call into openssl)
> openssl->lock(ssldata)
> 
> openssl->unlock(ssldata)
> (return from openssl)
> unlock(appdata)
>
> But: don't give openssl's lock registration access to the same lock
> that your app will be using.  If it's a mutex (1-holder semaphore),
> the way most locks should be, then what will happen is this:
>
> lock(appdata)
> (call into openssl)
> openssl->lock(ssldata)
> /* lock already held, fails */
>
> If you do this, then semantically the locking will operate properly
> no matter what happens in the library or in your app.
>
> Give OpenSSL its locking.  This will ensure that later semantic
> changes to the library (as an example -- and note that I'm not on the
> devteam, so I have no information on whether this will happen or not
> -- an 'iterate over all connections' primitive that operates from any
> thread, or an inspector for the state of any given SSL structure)
> won't end up trying to access an application-locked but openssl-
> unlocked structure.
>
> -Kyle H
>
>
> On Sep 5, 2007, at 1:52 AM, Kingston Smiler wrote:
>
> > Hi,
> >
> > Thanks for your input. AFAIK registering these callbacks will result
> > in locking the SSL datastructures internally by the OpenSSL whenever
> > required. My question is since I've handled these in my application is
> > it necessay for me to register these callbacks once again to the
> > OpenSSL. I'm handling this in application becoz i've to save some more
> > datas in the application scope from multiple thread access. So I've
> > taken a lock and using the same lock I'm trying protect the SSL
> > datastructures also.
> > So I this case is it necessary to register once again into the
> > openSSL.
> >
> > regards,
> > S.Kingston Smiler.
> >
> > On 9/5/07, zhuxian <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >>
> >> I think you needn't lock the SSL_connect/SSL_accept. It's too low
> >> efficient.
> >>
> >>
> >> You just have to set the lock callback using:
> >>
> >> CRYPTO_set_locking_callback(pthread_lock_handler);
> >>
> >> CRYPTO_set_id_callback(id_handler);
> >>
> >> It works fine in linux. But it does not in WinXP.  I was  puzzled
> >> with it
> >> too.
> >>
> >> Regards,
> >> Kurt.
> >>
> >>> -Original Message-
> >>> From: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] On Behalf Of Kingston
> >>> Smiler
> >>> Sent: Wednesday, September 05, 2007 3:53 PM
> >>> To: openssl-users@openssl.org
> >>> Subject: Reagrding Thread safety in OpenSSL
> >>>
> >>> Hi,
> >>>   I'm having a small query regarding the thread safety of the
> >>> OpenSSL library.
> >>> OpenSSL provide some set of Static Locking Callbacks and
> >>> Dynamic locking callbacks to ensure the thread safety of the
> >>> OpenSSL data structures. But if the application using the
> >>> OpenSSL, implements its own locking mechanism while accessing
> >>> the SSL calls (SSL_Connect,SSL_Read e.t.c) then is it
> >>> necessary to implment those callbacks also?
> >>>
> >>> i.e
> >>>
> >>> code like this
> >>>
> >>> Thread1
> >>> {
> >>>
> >>> lock (a)
> >>> SSL_Connect(pSSL)
> >>> unlock(a)
> >>>
> >>

Re: Reagrding Thread safety in OpenSSL

[Kyle Hamilton]

Lock your app data separately from the lock that OpenSSL uses to  
protect its own stuff.  Don't manipulate the OpenSSL structures  
directly, though if you've got reason to lock your application data  
you can include the OpenSSL structures in your own locking.


lock(appdata)
(call into openssl)
openssl->lock(ssldata)

openssl->unlock(ssldata)
(return from openssl)
unlock(appdata)

But: don't give openssl's lock registration access to the same lock  
that your app will be using.  If it's a mutex (1-holder semaphore),  
the way most locks should be, then what will happen is this:


lock(appdata)
(call into openssl)
openssl->lock(ssldata)
/* lock already held, fails */

If you do this, then semantically the locking will operate properly  
no matter what happens in the library or in your app.


Give OpenSSL its locking.  This will ensure that later semantic  
changes to the library (as an example -- and note that I'm not on the  
devteam, so I have no information on whether this will happen or not  
-- an 'iterate over all connections' primitive that operates from any  
thread, or an inspector for the state of any given SSL structure)  
won't end up trying to access an application-locked but openssl- 
unlocked structure.


-Kyle H

On Sep 5, 2007, at 1:52 AM, Kingston Smiler wrote:


Hi,

Thanks for your input. AFAIK registering these callbacks will result
in locking the SSL datastructures internally by the OpenSSL whenever
required. My question is since I've handled these in my application is
it necessay for me to register these callbacks once again to the
OpenSSL. I'm handling this in application becoz i've to save some more
datas in the application scope from multiple thread access. So I've
taken a lock and using the same lock I'm trying protect the SSL
datastructures also.
So I this case is it necessary to register once again into the  
openSSL.


regards,
S.Kingston Smiler.

On 9/5/07, zhuxian <[EMAIL PROTECTED]> wrote:

Hi,

I think you needn't lock the SSL_connect/SSL_accept. It's too low  
efficient.



You just have to set the lock callback using:

CRYPTO_set_locking_callback(pthread_lock_handler);

CRYPTO_set_id_callback(id_handler);

It works fine in linux. But it does not in WinXP.  I was  puzzled  
with it

too.

Regards,
Kurt.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kingston  
Smiler

Sent: Wednesday, September 05, 2007 3:53 PM
To: openssl-users@openssl.org
Subject: Reagrding Thread safety in OpenSSL

Hi,
  I'm having a small query regarding the thread safety of the
OpenSSL library.
OpenSSL provide some set of Static Locking Callbacks and
Dynamic locking callbacks to ensure the thread safety of the
OpenSSL data structures. But if the application using the
OpenSSL, implements its own locking mechanism while accessing
the SSL calls (SSL_Connect,SSL_Read e.t.c) then is it
necessary to implment those callbacks also?

i.e

code like this

Thread1
{

lock (a)
SSL_Connect(pSSL)
unlock(a)

}

Thread2
{
lock (a);
SSL_accept(pSSL);
unlok(a);
}
 
__
OpenSSL Project http:// 
www.openssl.org
User Support Mailing Listopenssl- 
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]





_ 
_
OpenSSL Project http:// 
www.openssl.org
User Support Mailing Listopenssl- 
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Reagrding Thread safety in OpenSSL

[Kingston Smiler]

Hi,

Thanks for your input. AFAIK registering these callbacks will result
in locking the SSL datastructures internally by the OpenSSL whenever
required. My question is since I've handled these in my application is
it necessay for me to register these callbacks once again to the
OpenSSL. I'm handling this in application becoz i've to save some more
datas in the application scope from multiple thread access. So I've
taken a lock and using the same lock I'm trying protect the SSL
datastructures also.
So I this case is it necessary to register once again into the openSSL.

regards,
S.Kingston Smiler.

On 9/5/07, zhuxian <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think you needn't lock the SSL_connect/SSL_accept. It's too low efficient.
>
>
> You just have to set the lock callback using:
>
> CRYPTO_set_locking_callback(pthread_lock_handler);
>
> CRYPTO_set_id_callback(id_handler);
>
> It works fine in linux. But it does not in WinXP.  I was  puzzled with it
> too.
>
> Regards,
> Kurt.
>
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of Kingston Smiler
> >Sent: Wednesday, September 05, 2007 3:53 PM
> >To: openssl-users@openssl.org
> >Subject: Reagrding Thread safety in OpenSSL
> >
> >Hi,
> >   I'm having a small query regarding the thread safety of the
> >OpenSSL library.
> > OpenSSL provide some set of Static Locking Callbacks and
> >Dynamic locking callbacks to ensure the thread safety of the
> >OpenSSL data structures. But if the application using the
> >OpenSSL, implements its own locking mechanism while accessing
> >the SSL calls (SSL_Connect,SSL_Read e.t.c) then is it
> >necessary to implment those callbacks also?
> >
> > i.e
> >
> >code like this
> >
> >Thread1
> >{
> >
> >lock (a)
> >SSL_Connect(pSSL)
> >unlock(a)
> >
> >}
> >
> >Thread2
> >{
> >lock (a);
> >SSL_accept(pSSL);
> >unlok(a);
> >}
> >__
> >OpenSSL Project http://www.openssl.org
> >User Support Mailing Listopenssl-users@openssl.org
> >Automated List Manager   [EMAIL PROTECTED]
> >
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   [EMAIL PROTECTED]
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Reagrding Thread safety in OpenSSL

[zhuxian]

Hi,

I think you needn't lock the SSL_connect/SSL_accept. It's too low efficient.


You just have to set the lock callback using:

CRYPTO_set_locking_callback(pthread_lock_handler);

CRYPTO_set_id_callback(id_handler); 

It works fine in linux. But it does not in WinXP.  I was  puzzled with it
too.

Regards,
Kurt.

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of Kingston Smiler
>Sent: Wednesday, September 05, 2007 3:53 PM
>To: openssl-users@openssl.org
>Subject: Reagrding Thread safety in OpenSSL
>
>Hi,
>   I'm having a small query regarding the thread safety of the 
>OpenSSL library.
> OpenSSL provide some set of Static Locking Callbacks and 
>Dynamic locking callbacks to ensure the thread safety of the 
>OpenSSL data structures. But if the application using the 
>OpenSSL, implements its own locking mechanism while accessing 
>the SSL calls (SSL_Connect,SSL_Read e.t.c) then is it 
>necessary to implment those callbacks also?
>
> i.e
>
>code like this
>
>Thread1
>{
>
>lock (a)
>SSL_Connect(pSSL)
>unlock(a)
>
>}
>
>Thread2
>{
>lock (a);
>SSL_accept(pSSL);
>unlok(a);
>}
>__
>OpenSSL Project http://www.openssl.org
>User Support Mailing Listopenssl-users@openssl.org
>Automated List Manager   [EMAIL PROTECTED]
>


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Reagrding Thread safety in OpenSSL

[Kingston Smiler]

Hi,
   I'm having a small query regarding the thread safety of the OpenSSL library.
 OpenSSL provide some set of Static Locking Callbacks and Dynamic
locking callbacks to ensure the thread safety of the OpenSSL data
structures. But if the application using the OpenSSL, implements its
own locking mechanism while accessing the SSL calls
(SSL_Connect,SSL_Read e.t.c) then is it necessary to implment those
callbacks also?

 i.e

code like this

Thread1
{

lock (a)
SSL_Connect(pSSL)
unlock(a)

}

Thread2
{
lock (a);
SSL_accept(pSSL);
unlok(a);
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Are callbacks required for thread-safety when only encrypting and decrypting symmetric ciphers???

[Bennett, Tony]

Are   CRYPTO_set_locking_callback()   and   CRYPTO_set_id_callback()  
required  in a multi-threaded application that only encrypts and
decrypts with symmetric ciphers...
...and performs no other SSL functions...???

I am using openssl 0.9.7g.
The platform is AIX  (IBM's UNIX).

Here are the specifics:

A given thread, based upon info passed to it, "may" need to encrypt a
file.
Here's what it is doing (with error checking and other processing
removed for clarity):

EVP_CIPHER_CTX_init(&ctx);

rc = EVP_EncryptInit_ex(&ctx,
EVP_aes_128_cbc(),
NULL,
(const unsigned char *)key,
(const unsigned char *)iov);

rc = EVP_EncryptUpdate(&ctx, encryptd_buf, &chars_in_enc_buf,
curr_object_ptr, max_bytes);

rc = EVP_EncryptUpdate(&ctx, encryptd_buf, &chars_in_enc_buf,
curr_object_ptr, max_bytes);

EVP_CIPHER_CTX_cleanup(&ctx);

Another thread, based upon info passed to it, "may" need to decrypt a
file.
Here's what it is doing (with error checking and other processing
removed for clarity):

EVP_CIPHER_CTX_init(&ctx);
rc = EVP_DecryptInit_ex(&ctx,
EVP_aes_128_cbc(),
NULL,
(const unsigned char*)key,
(const unsigned char *)iov);

   rc = EVP_DecryptUpdate(&ctx, decrypted_buf, &chars_in_decr_buf,
curr_object_ptr, max_bytes);

   rc = EVP_DecryptFinal_ex(&ctx, decrypted_buf, &chars_in_decr_buf);

   EVP_CIPHER_CTX_cleanup(&ctx);


Thanks,
-tony

RE: Thread safety

[Mark]

Hi Alain, 

> >I would recommend you always watch the warnings.  Some C compilers
> >downgrade fairly major problems to "Warnings".
> 
> I'm not really familiar with handling void* pointers so I'm 
> not sure how alarming these should be.

The first warning seems to be about the callback function being cast
to a function pointer with a slightly different type. (char* vs
const char*).

The second one could be a problem since CRYPO_thread_cleanup() is
defined as a static function for WIN32.

The functions in th-lock.c seem to be very close to those described
in the O'Reilly Book. I was not aware that OpenSSL provided a
reference version of these callbacks.

> So this really isn't much of a problem for me, but I'm still curious 
> about the macros:
> OPENSSL_THREAD_DEFINES
> THREADS
> OPENSSL_THREADS

The latter seems to be used to select the thread safe version of a
system call.

> Is the note in http://www.openssl.org/docs/crypto/threads.html still 
> valid in 0.9.8a ?

I don't know about this.  The books I have refer to versions 0.9.4 and
0.9.6!

Mark.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety

[Usman Riaz]

Hello again and thank you for your replies



I'll probably do it that way too. My threads are defined in another 
language and I'm pretty sure there is no way for my C module to be aware of 
which user thread it is currently running in... so I have nothing

relevant to call CRYPTO_set_id_callback with.

Well, this "CRYPTO_set_id_callback" seems to me not relevant either incase 
of IOCP server (or asynch/non blocking IO), since the thread reading or 
writing the BIO will NOT be the same ALWAYS, may be it is useful when doing 
a blocking IO i.e something like a thread per socket senario. As I 
understand, OpenSSL maintains a per thread error queue (seems not very 
useful atleast in this case, or a better solution would be to maintain a 
error queue per SSL object (OpenSSL SSL object)). So I do set that callback, 
since it is advised :).


So this really isn't much of a problem for me, but I'm still curious about 
the macros:

OPENSSL_THREAD_DEFINES
THREADS
OPENSSL_THREADS



Probably this THREADS is defined in some build script. Do a text search in 
the OpenSSL dir with "-DTHREADS".


Is the note in http://www.openssl.org/docs/crypto/threads.html still valid 
in 0.9.8a ?


Well, I am just implementing the static callbacks, not the dynamic 
callbacks, probably the dynmic callbacks are under-dev.
One piece of advise, in the example in the "crypto\threads\th-locks.h" 
and also i think the code from the OpenSSL book uses "Mutex", probably its a 
good choice on *inx systems, but on Windows Mutex should be used to 
synchronise between "Processes" and they are SLOW compared to other options 
(even though Mutexs will work for threads also). The better and FASTER 
approach is to use "CRITICAL_SECTION", see MSDN for info.



Thanks again for your answers,

--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be


Hope this helps,
Regards,
Usman.

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety

[Alain Damiral]

Hello again and thank you for your replies


Mark wrote:



I would recommend you always watch the warnings.  Some C compilers
downgrade fairly major problems to "Warnings".
 

I'd recommend the same thing to myself actually. These warnings are 
generated by the code in th-lock.c (compiling under Win32), which as I 
understand it contains code defining the callbacks required for (a few 
platform specific) threads support:

../th-lock.h: In function `CRYPTO_thread_setup':
../th-lock.h:122: warning: passing arg 1 of 
`CRYPTO_set_locking_callback' from incompatible pointer type

../th-lock.h:124: warning: `return' with a value, in function returning void
../th-lock.h: At top level:
../th-lock.h:128: warning: static declaration of 'CRYPTO_thread_cleanup' 
follows non-static declaration
../th-lock.h:89: warning: previous declaration of 
'CRYPTO_thread_cleanup' was here


I'm not really familiar with handling void* pointers so I'm not sure how 
alarming these should be.



Usman Riaz wrote:

As to your second question, I am doing the IO on BIO atomically, dont 
know if its really required, :), But since my server's performance is 
quite resonable with it, so it's OK with me.

Regards,
Usman.


I'll probably do it that way too. My threads are defined in another 
language and I'm pretty sure there is no way for my C module to be aware 
of which user thread it is currently running in... so I have nothing

relevant to call CRYPTO_set_id_callback with.

So this really isn't much of a problem for me, but I'm still curious 
about the macros:

OPENSSL_THREAD_DEFINES
THREADS
OPENSSL_THREADS

Is the note in http://www.openssl.org/docs/crypto/threads.html still 
valid in 0.9.8a ?


Thanks again for your answers,

--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Thread safety

[Usman Riaz]

Hello,

I'm trying to write an interface to OpenSSL using BIO pairs. For testing 
purposes, I'm doing communication locally in two seperate threads (one 
accessing a server context, the other a client context) so I figured I 
should worry about thread safety. I read in the OpenSSL documentation that 
one could find out if thread support was enabled using this:


#define OPENSSL_THREAD_DEFINES
#include 
#if defined(THREADS)
  // thread support enabled
#else
  // no thread support
#endif

If I stick to this it appears that I have no thread support here on my 
system (Win32), but I see no mention of that OPENSSL_THREAD_DEFINES macro 
in opensslconf.h, or anywhere else. Also, I see that OPENSSL_THREADS is 
defined in opensslconf.h so I'm basically wondering if this part of the 
documentation is out of date and if this OPENSSL_THREADS means that thread 
support is enabled. If so, are the callbacks defined in th-lock.c still 
valid ? I get a few warnings when I compile those with my project, but C is 
like alcohol and cigarettes - you never watch the warnings.



Next question:
I'll probably do all the locking manually since the threads themselves 
aren't defined at the C code level for my app (I'm not sure if thread 
support will work transparently with OpenSSL for user level threads). So 
I'm wondering if just locking all access to the C module in which OpenSSL 
routines are called should be sufficient or are there particular sequences 
of calls that should be made atomically (that OpenSSL thread support would 
usually deal with) ?


Thanks for reading and eventually for answering.


--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be



Hello Alain,
  I think by default OpenSSL is build with multithread support 
i.e. it links to multi-threaded version of CRT. But still you have provide 
the locks and two callbacks (for locking and unlocking & for getting thread 
id) then you are all set to use it in your multithreaded enviourment, I 
guess the VS linker spits out warnings if there is a CRT mismatch between 
the app & lib. And probably this THREADS flag is defined something like -D 
for the compiler in either the make file or some compilation script so that 
editing the .h/.c file is not needed.
As to your second question, I am doing the IO on BIO atomically, dont know 
if its really required, :), But since my server's performance is quite 
resonable with it, so it's OK with me.

Regards,
Usman.

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Thread safety

[Mark]

Hi Alain, 

There is a good section in the O'Reilly Book about threading.  See
Chapter 4.

If you haven't got this book then I will summerize.  OpenSSL is thread
safe
only if you implement the static (and dynamic) locking callbacks. You
can find some examples from http://www.opensslbook.com/code.html

You should also call ERR_remove_state() when a thread terminates to
destroy
the error queue for that thread.

> I get a few warnings when I 
> compile those with my project, but C is like alcohol and cigarettes - 
> you never watch the warnings.

I would recommend you always watch the warnings.  Some C compilers
downgrade fairly major problems to "Warnings".

Mark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Thread safety

[Alain Damiral]

Hello,

I'm trying to write an interface to OpenSSL using BIO pairs. For testing 
purposes, I'm doing communication locally in two seperate threads (one 
accessing a server context, the other a client context) so I figured I 
should worry about thread safety. I read in the OpenSSL documentation 
that one could find out if thread support was enabled using this:


#define OPENSSL_THREAD_DEFINES
#include 
#if defined(THREADS)
  // thread support enabled
#else
  // no thread support
#endif

If I stick to this it appears that I have no thread support here on my 
system (Win32), but I see no mention of that OPENSSL_THREAD_DEFINES 
macro in opensslconf.h, or anywhere else. Also, I see that 
OPENSSL_THREADS is defined in opensslconf.h so I'm basically wondering 
if this part of the documentation is out of date and if this 
OPENSSL_THREADS means that thread support is enabled. If so, are the 
callbacks defined in th-lock.c still valid ? I get a few warnings when I 
compile those with my project, but C is like alcohol and cigarettes - 
you never watch the warnings.



Next question:
I'll probably do all the locking manually since the threads themselves 
aren't defined at the C code level for my app (I'm not sure if thread 
support will work transparently with OpenSSL for user level threads). So 
I'm wondering if just locking all access to the C module in which 
OpenSSL routines are called should be sufficient or are there particular 
sequences of calls that should be made atomically (that OpenSSL thread 
support would usually deal with) ?


Thanks for reading and eventually for answering.


--
Alain Damiral,

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

OpenSSL thread-safety callbacks on AIX

[Andrei Tarassov]

Hi!
 
I am setting the callback functions, which should make openssl stuff 
thread-safe as described by http://www.openssl.org/docs/crypto/threads.html, 
but these functions just do not seem to be called on AIX. At the same time, the 
same test program works correctly (i.e. the callbacks are called) on Linux.
 
Any ideas why this could happen?

Some details:
The program uses openssl 0.9.7g through curl 7.14.0. AIX version 4.3.3.
OpenSSL was built with the following configuration:
./config threads no-asm no-shared no-zlib no-idea no-mdc2 \
no-rc5 no-ec no-krb5 -D_THREAD_SAFE
 
Thanks,
 
ANDREI TARASSOV
Software Engineer III
Altiris OÜ
T >  +372 6507154
M >  +372 53403298
www.altiris.com  
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Thread safety of crypto library

[David Schwartz]

> >Why would you go out of your way to create fragile code when you
> >could fix
> >this the right way in three or four minutes?

> If you don't use a "thread per request" model, it's a lot more than
> three or four minutes.

I don't see why you think that is. None of my code uses a 'thread per
request' model and implementing OpenSSL locking was as simple as a few dozen
lines of code. It's only that long because of extra debug and tracking in
non-release builds.

> I'd rather there were a public API to do this "pre-calc" kind of thing.

I don't think it makes sense to try to support a multithreaded model
without locking. The code will inevitably be fragile. I do agree that it
makes sense to have a public API to do the "pre-calc" for other reasons,
however, trying to guarantee proper operation without locks leads to
madness.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Thread safety of crypto library

[David Schwartz]

> Can I force this precalculation (caching) to take place after creating
> an RSA structure and before multiple threads use it (without doing an
> actual dummy-decryption)? If yes, would this suffice to avoid the race
> condition so that no locking is required?

Why would you go out of your way to create fragile code when you could fix
this the right way in three or four minutes?

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety of crypto library

[Dr. Stephen Henson]

On Wed, Jun 02, 2004, Thomas Schuerger wrote:

> > > Hi,
> > > 
> > > I have problems using the RSA_private_decrypt() function of the crypto
> > > library in parallel with *the same* (RSA *) structure. When using a
> > > single thread, decryption works flawlessly, when using two or more
> > > threads in parallel, decryption mostly fails with PKCS errors.
> > > 
> > > I thought the RSA structure would be accessed read-only so that this
> > > should be thread-safe.
> > > 
> > 
> > There are some montgomery parameters that are cached in the RSA structure when
> > it is first used. You need to set the appropriate locking callbacks to avoid a
> > race condition in a multithreaded environment.
> 
> Can I force this precalculation (caching) to take place after creating
> an RSA structure and before multiple threads use it (without doing an
> actual dummy-decryption)? If yes, would this suffice to avoid the race
> condition so that no locking is required?
> 
> 

The only real way is a dummy enccrypt and decrypt, I'm also not sure the
blinding code will work properly in a multithreaded environment without locking.

Additionally other aspects of the library (such as the error code) require the
use of locks in a multithreaded environment.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety of crypto library

[Dr. Stephen Henson]

On Fri, May 28, 2004, Thomas Schuerger wrote:

> > > I have problems using the RSA_private_decrypt() function of the crypto
> > > library in parallel with *the same* (RSA *) structure. When using a
> > > single thread, decryption works flawlessly, when using two or more
> > > threads in parallel, decryption mostly fails with PKCS errors.
> > > 
> > > I thought the RSA structure would be accessed read-only so that this
> > > should be thread-safe.
> > > 
> > 
> > There are some montgomery parameters that are cached in the RSA structure when
> > it is first used. You need to set the appropriate locking callbacks to avoid a
> > race condition in a multithreaded environment.
> > 
> > > Any ideas how to solve this? Is there a function that duplicates an
> > > RSA structure so that I can duplicate it before using it?
> > > 
> > 
> > RSAPrivateKey_dup().
> 
> OK, thanks...
> 
> Are there any examples how the locking callbacks can be set and how
> they could be implemented in a Linux environment?
> 

See:

http://www.openssl.org/support/faq.html#PROG1
http://www.openssl.org/docs/crypto/threads.html

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety of crypto library

[Thomas Schuerger]

> > I have problems using the RSA_private_decrypt() function of the crypto
> > library in parallel with *the same* (RSA *) structure. When using a
> > single thread, decryption works flawlessly, when using two or more
> > threads in parallel, decryption mostly fails with PKCS errors.
> > 
> > I thought the RSA structure would be accessed read-only so that this
> > should be thread-safe.
> > 
> 
> There are some montgomery parameters that are cached in the RSA structure when
> it is first used. You need to set the appropriate locking callbacks to avoid a
> race condition in a multithreaded environment.
> 
> > Any ideas how to solve this? Is there a function that duplicates an
> > RSA structure so that I can duplicate it before using it?
> > 
> 
> RSAPrivateKey_dup().

OK, thanks...

Are there any examples how the locking callbacks can be set and how
they could be implemented in a Linux environment?


Greetings,
Thomas.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Thread safety of crypto library

[Dr. Stephen Henson]

On Fri, May 28, 2004, Thomas Schuerger wrote:

> Hi,
> 
> I have problems using the RSA_private_decrypt() function of the crypto
> library in parallel with *the same* (RSA *) structure. When using a
> single thread, decryption works flawlessly, when using two or more
> threads in parallel, decryption mostly fails with PKCS errors.
> 
> I thought the RSA structure would be accessed read-only so that this
> should be thread-safe.
> 

There are some montgomery parameters that are cached in the RSA structure when
it is first used. You need to set the appropriate locking callbacks to avoid a
race condition in a multithreaded environment.

> Any ideas how to solve this? Is there a function that duplicates an
> RSA structure so that I can duplicate it before using it?
> 

RSAPrivateKey_dup().

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Thread safety of crypto library

[Thomas Schuerger]

Hi,

I have problems using the RSA_private_decrypt() function of the crypto
library in parallel with *the same* (RSA *) structure. When using a
single thread, decryption works flawlessly, when using two or more
threads in parallel, decryption mostly fails with PKCS errors.

I thought the RSA structure would be accessed read-only so that this
should be thread-safe.

Any ideas how to solve this? Is there a function that duplicates an
RSA structure so that I can duplicate it before using it?

Is there a documentation on thread safety of the crypto library?


Greetings,
Thomas.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Thread safety using OpenSSL

[Sean McAlister]

Title: Thread safety using OpenSSL





Hi,


Just a question about thread safety:


Your FAQ states that OpenSSL is thread-safe with limititations: (... an SSL connection may not concurrently be used by multiple threads).

Does this mean you cannot have one thread reading from the ssl session while another thread is writing to the ssl session???

Or do you mean that you cannot have more than one thread reading from the same session?


TIA,


Sean.



Sean McAlister
Development
patsystems (UK) Limited
22 Shand Street
London  SE1 2ES
Registered in England and Wales under company number 3086310


Tel +44 (0)20 7940 0653
Fax +44 (0)20 7940 0499
www.patsystems.com



DISCLAIMER: This e-mail is confidential and may also be legally privileged.  If you are not the intended recipient, use of the information contained in this e-mail (including disclosure, copying or distribution) is prohibited and may be unlawful.  Please inform the sender and delete the message immediately from your system.  This e-mail is attributed to the sender and may not necessarily reflect the views of the patsystems Group and no member of the patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The patsystems Group comprises patsystems plc and its subsidiary group of companies.

Thread Safety

[Lance Paine]

I am only using the cryptographic and BIO parts of OpenSSL, nothing to do
with certificates, in a Win32 MFC multithreaded app. Several threads use the
crypto and BIO functions, but I have locks in place so that only one thread
can access a particular BIO at a time.
Is it still  necessary to call the
CRYPTO_num_locks()
 CRYPTO_set_locking_callback()
 CRYPTO_set_id_callback()
functions?
If so, can someone please point me to a C++ example as visual c++ doesn't
seem to like mttest.c as c++ at all.

Thanks,

Lance

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: thread safety and info callback

[Tony Rogvall]

Cory Winter wrote:

> Hi,
>
> On Tue, Jan 09, 2001 at 09:20:04AM -0800, Geoff Thorpe wrote:
> > On Tue, 9 Jan 2001, Cory Winter wrote:
> >
> > > Anyway, I'm wondering if users are also expected to make the info callbacks
> > > thread safe? Don't get me wrong, I realize that this may sound like a stupid
> > > question but really, are the callbacks themselve thread safe? I'm at my wits
> > > end over what the problem is.
> >
> > Generally speaking, OpenSSL's thread safety covers synchronising access to
> > OpenSSL-internal state, eg. internal tables, lists, etc (the error
> > stack(s), internal SSL_SESSION cache being good examples). Externally
> > however, a caller cannot expect all OpenSSL "objects" to be inherently
> > thread-safe ... to do so would require OpenSSL to put locking throughout
> > the library and would degrage performance significantly. In particular, if
> > you wish to use SSL objects across threads, you should synchronise access
> > to them yourself. Perhaps this is the problem?
>
> I realize this. I had already done this. Actually I think I may have found
> the source of the problem but not the reason. After searching the mailing
> list I found someone who was experiencing a similar problem. ie. heavy load,
> resulting in "bad mac decode" and "invalid parameter" messages in the error
> queue. The work-around was to not use SSL_SESSION_CACHE_BOTH but just
> SSL_SESSION_CACHE_SERVER. (the default I believe) Anyway, after doing this,
> my app seems to be fine once more.
>
> Does anyone know why this fixes the problem?
>

No I don't know how to fix the problem but I am looking REALLY hard to fix some
problem that
may very well be related. We have some kind of problem, when using threads, that
occur after running steady for 50 minutes (30 sometimes) during 100% load. Suddenly
everything just breaks down (SEGV etc.)
Without threads we have never observed any problems.

I have seen code that may explain why your code is running better with
SSL_SESSION_CACHE_SERVER, it is in the routine ssl_update_cache.

There is a test for when to call SSL_CTX_flush_session that checks if a counter for
"good" session has
reach 255. But the problem is that if you are using CACHE_BOTH then the client
sess_connect_god is
used even if you are not using any SSL_connect's at all. This implies that
SSL_CTX_flush_session
will not be called (at least not from that point) if you use SSL_SESS_CACH_BOTH and
not use SSL_connect.

Correct me if i am wrong:

void ssl_update_cache(SSL *s,int mode)

...

   /* auto flush every 255 connections */
i=s->ctx->session_cache_mode;
if ((!(i & SSL_SESS_CACHE_NO_AUTO_CLEAR)) &&
((i & mode) == mode))
{
if (  (((mode & SSL_SESS_CACHE_CLIENT)
?s->ctx->stats.sess_connect_good
:s->ctx->stats.sess_accept_good) & 0xff) == 0xff)
{
SSL_CTX_flush_sessions(s->ctx,time(NULL));
}
}
}


/Tony



begin:vcard 
n:Rogvall;Tony
tel;cell:+46 709 390 183
tel;home:+46 8 574 00 306
tel;work:+46 8 545 55 027
x-mozilla-html:FALSE
url:http://www.bluetail.com
org:Alteon WebSystems
adr:;;S:t Eiksgatan 44;Stockholm;;SE-112 34;Sweden
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;29952
fn:Tony Rogvall
end:vcard

Re: thread safety

[Edson E. Watanabe]

I've written some ATL COM classes using OpenSSL (not a complete COM wrapper for 
OpenSSL!) and want to share the following recomendations:
1) Use ATL if possible. MFC COM objects require a lot of tweaking for working 
correctly with ASP. If you want to use ATL, choose the Simple Object, not the ASP 
Object in the wizard.
2) Memory leaks - please check them carefully (using some tool like NuMega DevPartner 
Studio). Some huge memory leaks will be left if your program creates a PKCS#7 object, 
for instance, and forgets to destroy it. So design a wrapper that destroy all these 
structures automatically if possible. Remember, COM wrappers are for VB/ASP (maybe 
Delphi) programmers, and must be easy to use.
3) Please don't forget to call CRYPTO_set_locking_callback
(an example is given in crypto\threads\th-lock.c). It helps to alleviate threading 
issues.
4) Put some code in DllMain /DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH, DLL_THREAD_ATTACH 
and DLL_THREAD_DETACH that handles the correct initialization/finalization of OpenSSL 
for processes and threads. Remove the DisableThreadLibraryCalls that is generated by 
the ATL COM Wizard.
5) From the ATL 101 classes: ASP is VBScript/JScript (maybe PerlScript ;-) and ByRef 
parameters for your parameters must be Variant. Binary data is better handled as a 
Byte Array, not a String (Unicode issues etc.). 

- Original Message - 
From: Colin Chalmers 
To: [EMAIL PROTECTED] 
Sent: Tuesday, December 19, 2000 4:56 AM
Subject: Re: thread safety


jinwon,

I too was considering making a COM wrapper for openssl but have not got round to 
starting it yet (and I believe I'm not the only one).
Would you be willing to share your code when finished or that we perhaps share some 
tasks/work to even the load?

/colin chalmers 
- Original Message - 
From: jinwon jang 
To: [EMAIL PROTECTED] 
Sent: Tuesday, December 19, 2000 1:20 AM
Subject: thread safety


Hello,

I'm planning to use openssl as a library that will be used with other application such 
as COM object on windows NT4.0 and windows 2000 platforms. And the COM object is 
called from ASP(Active Server Page) pages. 
 
I'd like to confirm whether openssl is thread safe with MS windows NT and windows2000. 
Since ASP is multi-threaded environment, it is not good enough to use thread-safe COM 
object without thread safety of openssl.

Thanks,

jinwon jang


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: thread safety of lib methods

[Bodo Moeller]

[EMAIL PROTECTED] (Colin Bradley):

>   May I ask someone who is familiar with the degree of thread
>   safety of the OpenSSL libraries to comment on it? I have been 
>   unable to find clear documentation on this aspect of the 
>   implementation, but noted that some of the libraries 
>   appear to contain several calls to pthread_*,

But surely only in one of the example files (which unfortunately are
not marked as such, but the non-existance of a corresponding .o file
after a library build should give a good indication)?

> while
>   others do not, and still others contain comments that 
>   suggest thread-safety is not that reliable.. 

>   Specifically, can one use one SSL context across multiple
>   threads, each of which handles an outgoing client connection
>   on a non-synchronized basis? 

The intension is that this should be possible, and it appears to work
in practice; but unfortunately there is a bug in the handling of
certain library-internal data structures that can cause some problems.
(I never noticed a problem while running my multi-threaded
application, but when reading the library source code I found that a
certain shared data structure can be used be multiple threads as if it
were private.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

thread safety of lib methods

[Colin Bradley]

Hello,

  May I ask someone who is familiar with the degree of thread
  safety of the OpenSSL libraries to comment on it? I have been 
  unable to find clear documentation on this aspect of the 
  implementation, but noted that some of the libraries 
  appear to contain several calls to pthread_*, while
  others do not, and still others contain comments that 
  suggest thread-safety is not that reliable.. 

  Specifically, can one use one SSL context across multiple
  threads, each of which handles an outgoing client connection
  on a non-synchronized basis? 

  Thank you for any comments or pointers you can provide. 


-- 

   Colin Bradley
   hutchison avenue software corporation
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]