We use dh2048_ffdhe2048.pem file (DH 2048 bits) instead of dh1024.pem file in
both non-FIPS and FIPS cases. Because the following command fails to generate
the pem file with 1024 bits. And the OpenSSL FIPS 140-2 security policy
document explains the DH public keys are allowed from 2048 bits.[1]
```
$ OPENSSL_CONF=/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/ssl/openssl_fips.cnf \
/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/bin/openssl \
dhparam -out dh1024.pem 1024
Generating DH parameters, 1024 bit long safe prime
dhparam: Generating DH key parameters failed
```
The dh2048_ffdhe2048.pem file was created by the following command with the
OpenSSL FIPS configuration file. The logic to generate the DH pem file is
different between non-FIPS and FIPS cases. In FIPS, it seems that the command
always returns the text defined as ffdhe2048 in the FFDHE groups in RFC 7919
unlike non-FIPS.[2]
As the generated pem file is a normal and valid PKCS#3-style group parameter, we
use the file for the non-FIPS case too.
```
$ OPENSSL_CONF=/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/ssl/openssl_fips.cnf \
/home/jaruga/.local/openssl-3.3.0-dev-fips-debug-1aa08644ec/bin/openssl \
dhparam -out dh2048_ffdhe2048.pem 2048
```
Note that the hard-coded PEM-encoded string in the `test_DHparams` is
intentional to avoid modifying the content unintentionally.
* [1] https://www.openssl.org/source/ - OpenSSL 3.0.8 FIPS 140-2 security
policy document page 25, Table 10 – Public Keys - DH Public
- DH (2048/3072/4096/6144/8192) public key agreement key
* [2] RFC7919 - Appendix A.1: ffdhe2048
https://www.rfc-editor.org/rfc/rfc7919#appendix-A.1
Check that OpenSSL::PKey::EC.builtin_curves returns an array in the
expected format.
Similarly to OpenSSL::Cipher.ciphers, OpenSSL::PKey::EC.builtin_curves
returns a list of known named curves rather than actually usable ones.
https://github.com/ruby/openssl/issues/671 found that the list may
include unapproved (and thus unusable) curves when the FIPS module is
loaded.
https://github.com/ruby/openssl/commit/c53cbabe00
The test case test_error_data utilizes the error message generated by
X509V3_EXT_nconf_nid(). The next commit will use X509V3_EXT_nconf(),
which generates a slightly different error message. Let's adapt the
check to it.
https://github.com/ruby/openssl/commit/9cdfa3a4d1
instead of looking of NIDs and then using X509V3_EXT_nconf_nid,
instead just pass strings to X509V3_EXT_nconf, which has all the logic for
processing dealing with generic extensions
also process the oid through ln2nid() to retain compatibility.
[rhe: tweaked commit message and added a test case]
https://github.com/ruby/openssl/commit/9f15741331
OpenSSL::X509::ExtensionFactory#create_ext and #create_extensions
accepts both sn (short names) and ln (long names) for registered OIDs.
This is different from the behavior of the openssl command-line utility
which accepts only sn in openssl.cnf keys.
Add a test case to check this.
https://github.com/ruby/openssl/commit/91ae46c8d7
Remove the OSSL_DEBUG flag and OpenSSL.mem_check_start which is only
compiled when the flag is given. They are meant purely for development
of Ruby/OpenSSL.
OpenSSL.mem_check_start helped us find memory leak bugs in past, but
it is no longer working with the recent OpenSSL versions. Let's just
remove it now.
https://github.com/ruby/openssl/commit/8c7a6a17e2
Error entries in the OpenSSL error queue may contain additional
contextual information associated with the error, which can be helpful
when debugging.
This "additional data" is currently only printed to stderr when
OpenSSL.debug is enabled. Let's include this in the exception messages
raised with ossl_raise(), too.
$ ruby -Ilib -ropenssl -e'OpenSSL.debug=true; OpenSSL::SSL::SSLContext.new.ecdh_curves="P-256:not-a-curve"'
-e:1: warning: error on stack: error:0A080106:SSL routines:gid_cb:passed invalid argument (group 'not-a-curve' cannot be set)
-e:1:in `ecdh_curves=': passed invalid argument (group 'not-a-curve' cannot be set) (OpenSSL::SSL::SSLError)
from -e:1:in `<main>'
https://github.com/ruby/openssl/commit/1c5bbdd68e
Test that the error message contains the necessary text instead of the
exact match. Exceptions raised by ossl_raise() may carry additional
context information in the message.
https://github.com/ruby/openssl/commit/fd6f76c0d3
When compiled with OpenSSL <= 1.1.1, OpenSSL::SSL::SSLContext#setup
does not raise an exception on an error return from
SSL_CTX_load_verify_locations(), but instead only prints a verbose-mode
warning. This is not helpful since it very likely indicates an actual
error, such as the specified file not being readable.
Also, OpenSSL's error queue is not correctly cleared:
$ ruby -w -ropenssl -e'OpenSSL.debug=true; ctx=OpenSSL::SSL::SSLContext.new; ctx.ca_file="bad-path"; ctx.setup; pp OpenSSL.errors'
-e:1: warning: can't set verify locations
["error:02001002:system library:fopen:No such file or directory",
"error:2006D080:BIO routines:BIO_new_file:no such file",
"error:0B084002:x509 certificate routines:X509_load_cert_crl_file: system lib"]
The behavior is currently different when compiled with OpenSSL >= 3.0:
SSLError is raised if SSL_CTX_load_verify_file() or
SSL_CTX_load_verify_dir() fails.
This inconsistency was unintentionally introduced by commit https://github.com/ruby/openssl/commit/5375a55ffc35
("ssl: use SSL_CTX_load_verify_{file,dir}() if available", 2020-02-22).
However, raising SSLError seems more appropriate in this situation.
Let's adjust the OpenSSL <= 1.1.1 code so that it behaves the same way
as the OpenSSL >= 3.0 code currently does.
Fixes: https://github.com/ruby/openssl/issues/649https://github.com/ruby/openssl/commit/7eb10f7b75
(https://github.com/ruby/openssl/pull/646)
Add OpenSSL::PKey.new_raw_private_key, #raw_private_key and public
equivalents. These methods are useful for importing and exporting keys
that support "raw private/public key". Currently, OpenSSL implements
X25519/X448 and Ed25519/Ed448 keys.
[rhe: rewrote commit message]
https://github.com/ruby/openssl/commit/3f29525618
Co-authored-by: Bart de Water <bartdewater@gmail.com>
If x is a modular square root of a (mod p) then so is (p - x). Both
answers are valid. In particular, both 2 and 3 are valid square roots
of 4 (mod 5). Do not assume that a particular square root is chosen by
the algorithm. Indeed, the algorithm in OpenSSL and LibreSSL <= 3.7
returns a non-deterministic answer in many cases. LibreSSL 3.8 and
later will always return the smaller of the two possible answers. This
breaks the current test case.
Instead of checking for a particular square root, check that the square
of the claimed square root is the given value. This is always true. Add
the simplest test case where the answer is indeed non-deterministic.
https://github.com/ruby/openssl/commit/93548ae959
It's to test the `OpenSSL::PKey.read` in the `test/openssl/test_pkey.rb`.
I added the pending status to the following tests failing on the FIPS mode
case in the `test/openssl/test_pkey.rb`.
* `test_ed25519`
* `test_x25519`
* `test_compare?`
https://github.com/ruby/openssl/commit/8149cdf6e8
This commit is to implement the `OpenSSL::OPENSSL_FIPS`, `ossl_fips_mode_get`
and `ossl_fips_mode_set` to pass the test `test/openssl/test_fips.rb`.
It seems that the `OPENSSL_FIPS` macro is not used on the FIPS mode case any
more, and some FIPS related APIs also were removed in OpenSSL 3.
See the document <https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod#removed-fips_mode-and-fips_mode_set>
the section OPENSSL 3.0 > Main Changes from OpenSSL 1.1.1 >
Other notable deprecations and changes - Removed FIPS_mode() and FIPS_mode_set() .
The `OpenSSL::OPENSSL_FIPS` returns always true in OpenSSL 3 because the used
functions `EVP_default_properties_enable_fips` and `EVP_default_properties_is_fips_enabled`
works with the OpenSSL installed without FIPS option.
The `TEST_RUBY_OPENSSL_FIPS_ENABLED` is set on the FIPS mode case on the CI.
Because I want to test that the `OpenSSL.fips_mode` returns the `true` or
'false' surely in the CI. You can test the FIPS mode case by setting
`TEST_RUBY_OPENSSL_FIPS_ENABLED` on local too. Right now I don't find a better
way to get the status of the FIPS mode enabled or disabled for this purpose. I
am afraid of the possibility that the FIPS test case is unintentionally skipped.
I also replaced the ambiguous "returns" with "should return" in the tests.
https://github.com/ruby/openssl/commit/c5b2bc1268
test/openssl/fixtures/ssl/openssl_fips.cnf.tmpl:
I referred to the following document for the openssl config file for FIPS mode.
<https://www.openssl.org/docs/manmaster/man7/fips_module.html>
- Making all applications use the FIPS module by default
It seems that the `.include` syntax only requires the absolute path.
So, the placeholder OPENSSL_DIR in the template file is replaced with the
actual OpenSSL directory.
.github/workflows/test.yml:
The `TEST_RUBY_OPENSSL_FIPS_ENABLED` environment variable is set
in the FIPS mode CI case. It can be used in the unit tests.
https://github.com/ruby/openssl/commit/18b017218c
The behavior of EVP_PKEY_public_check changed between OpenSSL 1.1.1
and 3.0 so that it no longer validates the private key. Instead, private
keys can be validated through EVP_PKEY_private_check and
EVP_PKEY_pairwise_check.
[ky: simplified condition to use either EVP_PKEY_check() or
EVP_PKEY_public_check().]
https://github.com/ruby/openssl/commit/e38a63ab3d
As noted in commit https://github.com/ruby/openssl/commit/a2ed156cc9f1 ("test/test_ssl: do not run NPN tests
for LibreSSL >= 2.6.1", 2017-08-13), NPN is known not to work properly
on LibreSSL.
Disable NPN support on LibreSSL, whether OPENSSL_NO_NEXTPROTONEG is
defined or not.
NPN is less relevant today anyway. Let's also silence test suite when
it's not available.
https://github.com/ruby/openssl/commit/289f6e0e1f
- 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)
https://github.com/ruby/openssl/commit/3b63232cf1
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/535https://github.com/ruby/openssl/commit/d486c82833
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-1224912710https://github.com/ruby/openssl/commit/4293f18b1f
Jun Aruga
Nobuyoshi Nakada
Kazuki Yamaguchi
Michael Richardson
Mau Magnaguagno
Ryo Kajiwara
qwyng
Theo Buehler
Hiroshi SHIBATA
Andrew Konchin
Joe Truba
Yusuke Nakamura
Jarek Prokop
Ben Toews
Christophe De La Fuente
madblobfish
Nobuhiro IMAI