[
https://issues.apache.org/jira/browse/KUDU-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225772#comment-17225772
]
ASF subversion and git services commented on KUDU-3210:
-------------------------------------------------------
Commit f9f3189a6dbe0636d578d80b1d8e60cf7b2e6686 in kudu's branch
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=f9f3189 ]
KUDU-3210 Add lock before verifying signature
It seems there is a race condition somewhere in OpenSSL FIPS Object
Module 2.0, or at least in SafeLogic CryptoComply for Servers
1.0.2v-fips, as a certificate can get corrupted when multiple
certificates are being verified in the same time, throwing an error
during TLS handshake similar to this:
error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not
01:rsa_pk1.c:102 error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding
check failed:rsa_eay.c:786 error:1408D07B:SSL
routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2038
This means OpenSSL is trying to verify a signature with a public key
that doesn't match the private key, resulting in an invalid message.
According to a mailing list thread[1] this can happen in multi-threaded
applications, such as ours, even though we seem to have proper locking
in our verify signature function and the OpenSSL locking callbacks are
properly registered too.
Unfortunately, OpenSSL 1.0.2 doesn't guarantee complete thread
safety[2]:
"OpenSSL can generally be used safely in multi-threaded applications
provided that at least two callback functions are set, the
locking_function and threadid_func. Note that OpenSSL is not completely
thread-safe, and unfortunately not all global resources have the
necessary locks. Further, the thread-safety does not extend to things
like multiple threads using the same SSL object at the same time."
In addition to the TLS negotiation this can also get triggered when
verifying authn token signatures, further suggesting a race condition in
the underlying OpenSSL library.
This commit adds additional locking conditionally depending on a hidden
runtime flag "openssl_defensive_locking" to crypto and TLS
context/handshake which seems to prevent this from happening in both
places.
[1] https://groups.google.com/u/1/g/mailing.openssl.users/c/u0JyAuogrc0
[2] https://www.openssl.org/docs/man1.0.2/man3/threads.html
Change-Id: Ifafc7dcf91db910123276b657515e410bb7f6fcd
Reviewed-on: http://gerrit.cloudera.org:8080/16659
Reviewed-by: Wenzhe Zhou <wz...@cloudera.com>
Reviewed-by: Alexey Serbin <aser...@cloudera.com>
Reviewed-by: Grant Henke <granthe...@apache.org>
Tested-by: Grant Henke <granthe...@apache.org>
> Support FIPS approved mode
> --------------------------
>
> Key: KUDU-3210
> URL: https://issues.apache.org/jira/browse/KUDU-3210
> Project: Kudu
> Issue Type: Improvement
> Reporter: Attila Bukor
> Assignee: Attila Bukor
> Priority: Major
>
> FIPS 140-2 is a standard used to approve cryptographic modules. Some versions
> of OpenSSL support a "FIPS mode" where only approved algorithms and key sizes
> are enabled. Kudu should be able to run when FIPS mode is enabled and should
> provide a way for admins to require that FIPS mode is enabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
