ukhovni
> wrote:
>
>> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale wrote:
>>
>> The SSL sessions are not thread safe. It is up to the calling application
>> to ensure that this race condition does not occur.
>
> Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).
>
> --
> Viktor.
>
> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale wrote:
>
> The SSL sessions are not thread safe. It is up to the calling application to
> ensure that this race condition does not occur.
Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).
--
Viktor.
The SSL sessions are not thread safe. It is up to the calling application to
ensure that this race condition does not occur.
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 14 Jun 2019, at 8:09 pm, Serti Ayoub
O_TICKET in TLSv1.3. The default behaviour is to use
stateless tickets which aren't shared between threads, so no race condition is
possible. However, with SSL_OP_NO_TICKET we use stateful tickets which means the
session objects *are* shared.
Session objects are supposed to be immutable after the
to a race condition in openssl, exactly when 2
threads use the same SSL_SESSION*.
Some t
We don't install any session management callback and we keep session
caching mode to 2 ( SSL_SESS_CACHE_SERVER).
I made some debugging/tracing and I found that SSL_OP_NO_TICKET force
openssl to
Hello
Steve,
Thanks for your reply but a few doubts still
exist,
> 1. Suppose we request for
the revocation status of many certificates in a
> single request >
> eg
(openssl verify -crl_check -CAfile demoCA/crl/chain cert1 cert2
Dr. Stephen Henson wrote:
You need to mark the stored encoding as invalid if you want to do that. You
can do that with:
crl->crl->enc.modified = 1;
As long as you do that before signing the CRL it should then work.
This works fine. Thanks for your help,
Thorsten
On Thu, Dec 09, 2004, prakash babu wrote:
> Hello Steve,
>
> Thanks for your explanation. It was very informative,
>
> In OpenSSL 0.9.7e while doing the CRL checking, the following steps are
> performed
>
> a. Caching the original CRL list into cache
> b. Sorting the CRL list.
On Thu, Dec 09, 2004, Thorsten Müller wrote:
> Dr. Stephen Henson wrote:
>
> >
> >The second option, which I implemented, is to cache the original encoding
> >and
> >use the cached form to verify signatures. This makes signature verification
> >much quicker since no reordering is necessary.
>
Hello Steve,
Thanks for your explanation. It
was very informative,
In OpenSSL 0.9.7e while
doing the CRL checking, the following steps are
performed a. Caching the original CRL list
into cache b. Sorting the CRL
list. c. Searching the given certificate in the
sorted CRL
Dr. Stephen Henson wrote:
The second option, which I implemented, is to cache the original encoding and
use the cached form to verify signatures. This makes signature verification
much quicker since no reordering is necessary.
This still requires lock when the revoked entries are sorted but they
On Wed, Dec 08, 2004, prakash babu wrote:
> Hello all,
>
>There has been a tremendous performance during CRL check between
> 0.9.7d and 0.9.7e
>
> I measured the time for checking the crl with 1,00,000 entries
> using the following command
>
>
Hello all,
There has
been a tremendous performance during CRL check between 0.9.7d and
0.9.7e
I measured the time
for checking the crl with 1,00,000 entries using the following
command
time openssl
verify -crl_check -CAfile $ssl_crl_dir/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andrew Mann
Sent: Monday, September 08, 2003 9:35 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: SSL_CTX_new race condition
I appologize if this comes through twice. I haven't seen the first
come through
IL PROTECTED] Behalf Of Andrew Mann
Sent: Monday, September 08, 2003 9:35 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: SSL_CTX_new race condition
I appologize if this comes through twice. I haven't seen the first
come through the list yet and it was sent Friday, so
15 matches
Mail list logo
