> 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
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 fi
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
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 Open
Hi
Is OpenSSL function RAND_bytes () thread safe?
Thanks
Rahul
Hi
Is the OpenSSL function RAND_bytes() thread safe? I do not find any mention
about thread safety in its man page.
Thanks
Rahul
[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 acces
> 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.
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 t
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:
> H
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
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
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
t;
> 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_loc
us.
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(
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 i
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 i
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 w
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))).
Ot
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
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
reate_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
>
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 t
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
l 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 libra
] 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.
s 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
>
&g
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 lo
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 specif
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 b
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_cal
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
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 doc
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.ht
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 doc
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
> >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 'threa
> 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 you
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
> > > threa
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, d
> > 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 tho
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, decrypti
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
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
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 t
et 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 acc
ubject: 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?
[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
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_
49 matches
Mail list logo
