> I will just grab master then. Will this change be in the next 1.0.2 release?
No. Released branches only get bug-fixes.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
I will just grab master then. Will this change be in the next 1.0.2 release?
-Bryan
> On May 8, 2015, at 10:12 AM, Salz, Rich wrote:
>
>
>> You can private message me the patch and I can benchmark it for you.
>> Please let me know what release version or hash on git that it will cleanly
>>
> You can private message me the patch and I can benchmark it for you.
> Please let me know what release version or hash on git that it will cleanly
> apply. Do you know what release this will be going in?
It is this commit 3e47caff4830d2a117eda15b57a5feab89b846ae on master. A quick
check sho
You can private message me the patch and I can benchmark it for you. Please
let me know what release version or hash on git that it will cleanly apply. Do
you know what release this will be going in?
-Bryan
> On May 1, 2015, at 6:49 AM, Salz, Rich wrote:
>
>> Lock #1 is CRYPTO_LOCK_ERR,
It is in non-blocking mode.
After removing the call to SSL_get_error for the SSL_read case (0 return value)
I discovered we call SSL_get_error in a couple more places. Here is a simple
request and the return codes on SSL_accept, SSL_read, and SSL_write and the
return codes from SSL_get_error.
Not sure.
Are you using blocking or non-blocking IO?
Have you tried SSL_MODE_AUTO_RETRY?
Do you notice a different return value from SSL_read() after a zero byte
read compared to other errors?
On 05/06/2015 07:12 PM, Bryan Call wrote:
> Do you know if there is a way from preventing a call to
Do you know if there is a way from preventing a call to SSL_get_error() after
getting a 0 byte read from SSL_read()? This is the main issue I am facing with
the OpenSSL error locking right now.
-Bryan
> On May 1, 2015, at 6:49 AM, Salz, Rich wrote:
>
>> Lock #1 is CRYPTO_LOCK_ERR, which I
Yes, if you never call FIPS_mode_set(), the POST will never run. I'll
defer to the experts on your other questions.
On 05/01/2015 05:10 PM, Bryan Call wrote:
> So can I assume the FIPS POST has completed if I never call FIPS_mode_set()
> in the code? I was confused about that.
>
> When we call
So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in
the code? I was confused about that.
When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see
if there was an error not not. Maybe there is a more efficient handle this,
like looking at the sh
>Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It
>appears your application is generating a lot of errors for some reason. Never
>tried it myself, but you probably can't disable this lock with multiple
>threads running. You should take a look at the error log to iden
The changes to SSL_locking_callback() look good. But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much.
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.
On 04/30/2015 09:49 PM, Bryan Call wrote:
> (plai
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.
It appears your application is generating a lot of errors for some
reason. Never tried it myself, but you probably can't disable this lock
with multiple threads running. You should take a look at the error log
to identify th
(plain text and removed most of the history)
John if you don’t mind reviewing my change to Apache Traffic Server. It seems
to be working very well. Thank you again!
https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=iocore/net/SSLUtils.cc;h=0b732440636ab4e9eaedf237a5674bd
This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.
I am thinking about always disabling FIPS right now and that would happen
before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes you
recommend (Big Thanks!). The big
Correct. Locks 39/40 are only useful while the POST is running. Once
the POST completes, the POST status never changes again unless the POST
runs again. The only way to run the POST is by invoking
FIPS_mode_set(1). But there should be no reason to invoke
FIPS_mode_set(1) more than once unless y
Can I safely assume that if I call FIPS_mode_set(0) and get a successful return
value then I don’t need to lock when there are callbacks for type 39 and 40
locks (for OpenSSL 1.0.1 and 1.0.2)?
-Bryan
> On Apr 28, 2015, at 10:22 AM, John Foley wrote:
>
> In the context of OpenSSL 1.0.1 or 1
> In the future, this may change if/when OpenSSL does another FIPS validation.
> CMVP has changed the implementation guidance that requires the POST to run
> automatically without user intervention. Any future FIPS validations would
> be subject to the new rules. Hence, the behavior of FIPS_mode_
In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1)
has returned with a successful return value.
In the future, this may change if/when OpenSSL does another FIPS
validation. CMVP has changed the implementation guidance that requires
the POST to run automatically without user in
What do you mean by “FIPS POST has completed”?
-Bryan
> On Apr 24, 2015, at 4:17 PM, John Foley wrote:
>
> Some of the algorithms still invoke the FIPS flavor of the algorithm even
> when FIPS is disabled. For example, this code is from EVP_DigestUpdate().
>
> int EVP_DigestUpdate(EVP_MD_
Some of the algorithms still invoke the FIPS flavor of the algorithm
even when FIPS is disabled. For example, this code is from
EVP_DigestUpdate().
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
In my last email I ran the benchmark on Fedora 21 (big mistake). Here are the
results when running it back on the 28/56 core RHEL 6.5 server showing
contention in a different place (fips). Is there a reason it would be calling
into the FIPS code to get a lock of FIPS is not enabled?
Contenti
When you create the private key given to SSL_CTX, be sure to instantiate
a private key for each thread as well. If you share the same key across
all threads, this can introduce contention.
Here are the type 1 & 2 locks:
# define CRYPTO_LOCK_ERR 1
# define CRYPTO_LOCK_EX_DATA
We are using a single SSL_CTX across all the threads, so I will create multiple
SSL_CTX per thread. I implemented dynlock callbacks yesterday, but I didn’t
see them being used in the tests I did. I also added atomic counters to see
what type of locks are having contention (see logs below):
Mo
Looking at your call stack, it appears you're testing with FIPS mode
enabled. There's a lock in FIPS_selftest_failed() that's used to ensure
the crypto algorithms inside the FIPS boundary are not utilized until
after the POST has completed and passed. Unfortunately this lock remains
installed for
24 matches
Mail list logo
