- This callback is invoked when TLS key material is generated or
received, in order to allow applications to store this keying material
for debugging purposes.
- It is invoked with an `SSLSocket` and a string containing the key
material in the format used by NSS for its SSLKEYLOGFILE debugging
output.
- This commit adds the Ruby binding `keylog_cb` and the related tests
- It is only compatible with OpenSSL >= 1.1.1. Even if LibreSSL implements
`SSL_CTX_set_keylog_callback()` from v3.4.2, it does nothing (see
648d39f0f0)
3b63232cf1
The code was introduced by 65530b887e ("ssl: enable generating keying
material from SSL sessions", 2022-08-03).
This is harmless, but we should avoid it.
f5b82e814b
Scan through the input for a private key, then fallback to generic
decoder.
OpenSSL 3.0's OSSL_DECODER supports encoded key parameters. The PEM
header "-----BEGIN EC PARAMETERS-----" is used by one of such encoding
formats. While this is useful for OpenSSL::PKey::PKey, an edge case has
been discovered.
The openssl CLI command line "openssl ecparam -genkey" prints two PEM
blocks in a row, one for EC parameters and another for the private key.
Feeding the whole output into OSSL_DECODER results in only the first PEM
block, the key parameters, being decoded. Previously, ruby/openssl did
not support decoding key parameters and it would decode the private key
PEM block instead.
While the new behavior is technically correct, "openssl ecparam -genkey"
is so widely used that ruby/openssl does not want to break existing
applications.
Fixes https://github.com/ruby/openssl/pull/535d486c82833
DSA parameters generation via EVP_PKEY_paramgen() will not automatically
adjust the size of q value but uses 224 bits by default unless specified
explicitly. This behavior is different from the now-deprecated
DSA_generate_parameters_ex(), which PKey::DSA.generate used to call.
Fixes https://github.com/ruby/openssl/issues/483
Fixes: 1800a8d5eb ("pkey/dsa: use high level EVP interface to generate parameters and keys", 2020-05-17)
0105975a0b
Current OpenSSL 3.0.x release has a regression with zero-length MAC
keys. While this issue should be fixed in a future release of OpenSSL,
we can use EVP_PKEY_new_raw_private_key() in place of the problematic
EVP_PKEY_new_mac_key() to avoid the issue. OpenSSL 3.0's man page
recommends using it regardless:
> EVP_PKEY_new_mac_key() works in the same way as
> EVP_PKEY_new_raw_private_key(). New applications should use
> EVP_PKEY_new_raw_private_key() instead.
Fixes https://github.com/ruby/openssl/issues/369#issuecomment-12249127104293f18b1f
X509at_delete_attr() in OpenSSL master puts an error queue entry if
there is no attribute left to delete. We must either clear the error
queue, or try not to call it when the list is already empty.
a0c878481f
X509_STORE_get_ex_new_index() is a macro, so passing just its name to
have_func() doesn't detect it. Pass an example call instead.
8d264d3e60
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
While building with a custom build of OpenSSL, I noticed in mkmf.log
that all the feature detection checks are done using a program lacking
an OpenSSL header include. `mkmf` retries using a fallback program when
this fails, but that means all the `have_func` calls compile twice when
compiling once should suffice. Example log without this commit:
have_func: checking for X509_STORE_CTX_get0_cert()... -------------------- yes
DYLD_FALLBACK_LIBRARY_PATH=.:../.. "clang -o conftest ...
conftest.c:14:57: error: use of undeclared identifier 'X509_STORE_CTX_get0_cert'
int t(void) { void ((*volatile p)()); p = (void ((*)()))X509_STORE_CTX_get0_cert; return !p; }
^
1 error generated.
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: /*top*/
4: extern int t(void);
5: int main(int argc, char **argv)
6: {
7: if (argc > 1000000) {
8: int (* volatile tp)(void)=(int (*)(void))&t;
9: printf("%d", (*tp)());
10: }
11:
12: return !!argv[argc];
13: }
14: int t(void) { void ((*volatile p)()); p = (void ((*)()))X509_STORE_CTX_get0_cert; return !p; }
/* end */
DYLD_FALLBACK_LIBRARY_PATH=.:../.. "clang -o conftest ...
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: /*top*/
4: extern int t(void);
5: int main(int argc, char **argv)
6: {
7: if (argc > 1000000) {
8: int (* volatile tp)(void)=(int (*)(void))&t;
9: printf("%d", (*tp)());
10: }
11:
12: return !!argv[argc];
13: }
14: extern void X509_STORE_CTX_get0_cert();
15: int t(void) { X509_STORE_CTX_get0_cert(); return 0; }
/* end */
The second compilation succeeds.
Specify the header for each checked function.
34ae7d92d0
openssl has to support older versions of Ruby. Undo the change in
ext/openssl/ossl_pkey_ec.c by commit efb91ff19b ("Rename
rb_ary_tmp_new to rb_ary_hidden_new", 2022-07-25).
rb_ary_tmp_new suggests that the array is temporary in some way, but
that's not true, it just creates an array that's hidden and not on the
transient heap. This commit renames it to rb_ary_hidden_new.
On Windows with OpenSSL 3, the gem fails to compile with the following
error message:
ruby/src/ext/openssl/extconf.rb:188: undefined method \`sub!' for nil:NilClass
This is because $warnflags is nil.
OpenSSL 3.0's EVP_PKEY_get0() returns NULL for provider-backed pkeys.
This causes segfault because it was supposed to never return NULL
before.
We can't check the existence of public key components in this way on
OpenSSL 3.0. Let's just skip it for now.
ccdb6f7bfa
The entire ENGINE API is deprecated in OpenSSL 3.0 in favor of the new
"Provider" concept.
OpenSSL::Engine will not be defined when compiled with OpenSSL 3.0.
We would need a way to interact with providers from Ruby programs, but
since the concept is completely different from the ENGINE API, it will
not be through the current OpenSSL::Engine interface.
69a27d8de4
OpenSSL 3.0 made EVP_PKEY immutable. This means we can only have a const
pointer of the low level struct and the following methods can no longer
be provided when linked against OpenSSL 3.0:
- OpenSSL::PKey::RSA#set_key
- OpenSSL::PKey::RSA#set_factors
- OpenSSL::PKey::RSA#set_crt_params
- OpenSSL::PKey::DSA#set_pqg
- OpenSSL::PKey::DSA#set_key
- OpenSSL::PKey::DH#set_pqg
- OpenSSL::PKey::DH#set_key
- OpenSSL::PKey::EC#group=
- OpenSSL::PKey::EC#private_key=
- OpenSSL::PKey::EC#public_key=
There is no direct replacement for this functionality at the moment.
I plan to introduce a wrapper around EVP_PKEY_fromdata(), which takes
all key components at once to construct an EVP_PKEY.
6848d2d969
OpenSSL::PKey::EC#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
5e2e66cce8
OpenSSL::PKey::DH#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
8ee6a582c7
Similarly to DH#compute_key, work around it by constructing a
SubjectPublicKeyInfo. This should be considered as a temporary
implementation.
fc9aabc18d
DH#set_key will not work on OpenSSL 3.0 because keys are immutable.
For now, let's reimplement DH#compute_key by manually constructing a
DER-encoded SubjectPublicKeyInfo structure and feeding it to
OpenSSL::PKey.read.
Eventually, we should implement a new method around EVP_PKEY_fromdata()
and use it instead.
46ca47060c
Allocate an EVP_PKEY when the content is ready: when #initialize
or #initialize_copy is called, rather than when a T_DATA is allocated.
This is more natural because the lower level API has been deprecated
and an EVP_PKEY is becoming the minimum unit of handling keys.
74f6c61756
