Only set min_version on OpenSSL < 1.1.0 #710

ekohl · 2024-01-05T15:10:14Z

Both Red Hat and Debian-like systems configure the minimum TLS version to be 1.2 by default, but allow users to change this via configs.

On Red Hat and derivatives this happens via crypto-policies, which in writes settings in /etc/crypto-policies/back-ends/opensslcnf.config. Most notably, it sets TLS.MinProtocol there. For Debian there's MinProtocol in /etc/ssl/openssl.cnf. Both default to TLSv1.2, which is considered a secure default.

In constrast, the SSLContext has a hard coded OpenSSL::SSL::TLS1_VERSION for min_version. TLS 1.0 and 1.1 are considered insecure. By always setting this in the default parameters, the system wide default can't be respected, even if a developer wants to.

This takes the approach that's also done for ciphers: it's only set for OpenSSL < 1.1.0.

Fixes #709

ekohl · 2024-01-08T11:48:21Z

I don't know if the Windows test failure is related.

For the record, this is how I verified this. I first created some self signed certificates and an Apache config on CentOS Stream 8 that provided a vhost with only a single TLS version enabled:

<VirtualHost *:443>
    ServerName tls-10.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLProtocol -all +TLSv1
    SSLCertificateFile      "/etc/ssl/certs/host.crt"
    SSLCertificateKeyFile   "/etc/ssl/certs/host.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-11.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLProtocol -all +TLSv1.1
    SSLCertificateFile      "/etc/ssl/certs/host.crt"
    SSLCertificateKeyFile   "/etc/ssl/certs/host.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-12.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLProtocol -all +TLSv1.2
    SSLCertificateFile      "/etc/ssl/certs/host.crt"
    SSLCertificateKeyFile   "/etc/ssl/certs/host.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-13.example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLProtocol -all +TLSv1.3
    SSLCertificateFile      "/etc/ssl/certs/host.crt"
    SSLCertificateKeyFile   "/etc/ssl/certs/host.key"
</VirtualHost>

Then I used a minimal script to retrieve the content:

require 'net/http'

domains = [
        'tls-10.example.com',
        'tls-11.example.com',
        'tls-12.example.com',
        'tls-13.example.com',
]

ca_file = '/etc/ssl/certs/cacert.crt'

domains.each do |domain|
        uri = URI("https://#{domain}")
        begin
                Net::HTTP.start(domain, 443, use_ssl: true, ca_file: ca_file) do |http|
                        http.get(uri)
                end
        rescue StandardError => e
                puts "Failed to load from #{domain}: #{e}"
        else
                puts "Loaded from #{domain}"
        end
end

By default this loads from all 4 domains. When I manually patched /usr/share/ruby/openssl/ssl.rb it only loaded TLS 1.2+, just like /etc/crypto-policies/back-ends/opensslcnf.config says. I then modified /etc/crypto-policies/back-ends/opensslcnf.config and observed it matched.

# grep '^TLS.Min' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.2
# ruby test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 state=error: tlsv1 alert protocol version
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 state=error: tlsv1 alert protocol version
Loaded from tls-12.example.com
Loaded from tls-13.example.com
# vi /etc/crypto-policies/back-ends/opensslcnf.config
# grep '^TLS.Min' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.0
# ruby test.rb
Loaded from tls-10.example.com
Loaded from tls-11.example.com
Loaded from tls-12.example.com
Loaded from tls-13.example.com
# vi /etc/crypto-policies/back-ends/opensslcnf.config
# ruby test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 state=error: tlsv1 alert protocol version
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 state=error: tlsv1 alert protocol version
Failed to load from tls-12.example.com: SSL_connect returned=1 errno=0 state=error: tlsv1 alert protocol version
Loaded from tls-13.example.com

rhenium

Seems good to me. This shouldn't re-enable SSL 3.0 since

OpenSSL 1.1.0 is compiled without SSL 3.0 support by default (openssl/openssl@9829b5a).
LibreSSL 2.3.0 (2015-09-23) removed SSL 3.0 support (https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.3.0-relnotes.txt).

junaruga · 2024-01-08T20:34:14Z

Is it better for us to write a unit test for this change?

ekohl · 2024-01-09T13:56:34Z

@rhenium thanks for that context. I hadn't considered that, but glad to see my implementation works with those in mind.

@junaruga how would you write such a unit test? Test out set_params? I can add something like this:

diff --git a/test/openssl/test_ssl.rb b/test/openssl/test_ssl.rb
index 07dc9a343cef..8efc48ad6dc9 100644
--- a/test/openssl/test_ssl.rb
+++ b/test/openssl/test_ssl.rb
@@ -554,6 +554,15 @@ class OpenSSL::TestSSL < OpenSSL::SSLTestCase
     assert_equal 0, ctx.options & OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
     assert_equal OpenSSL::SSL::OP_NO_COMPRESSION,
                  ctx.options & OpenSSL::SSL::OP_NO_COMPRESSION
+
+    if (OpenSSL::OPENSSL_VERSION.start_with?("OpenSSL") &&
+         OpenSSL::OPENSSL_VERSION_NUMBER >= 0x10100000)
+      # The cached value should not exist
+      assert_raise(NoMethodError) { ctx.send(:@min_proto_version) }
+    else
+      # This is not publicly exposed, but read the cached version
+      assert_equal OpenSSL::SSL::TLS1_VERSION, ctx.send(:@min_proto_version)
+    end
   end
 
   def test_post_connect_check_with_anon_ciphers

Would that address your concerns? I always question reusing the same version detection logic, because it's so fragile.

junaruga · 2024-01-09T14:53:07Z

@ekohl good question!

Nowadays we tend to separate the tests to small bits rater than adding the conditional assertions in one test. I wished that we could find a better way rater than checking the @min_proto_version. But yeah, as you suggested, I see that using the @min_proto_version seems the best way for now.

Below is my suggestion. @rhenium is the decision maker. What do you think?

diff --git a/test/openssl/test_ssl.rb b/test/openssl/test_ssl.rb
index 07dc9a3..0f0b557 100644
--- a/test/openssl/test_ssl.rb
+++ b/test/openssl/test_ssl.rb
@@ -556,6 +556,29 @@ class OpenSSL::TestSSL < OpenSSL::SSLTestCase
                  ctx.options & OpenSSL::SSL::OP_NO_COMPRESSION
   end

+  def test_sslctx_set_params_no_min_version_on_greater_than_equal_openssl_11
+    omit 'Omit in OpenSSL 1.0 or eariler versions' unless openssl?(1, 1, 0)
+    omit 'Omit in LibreSSL' if libressl?
+
+    ctx = OpenSSL::SSL::SSLContext.new
+    ctx.set_params
+
+    # The cached value should not exist.
+    assert_raise(NoMethodError) { ctx.send(:@min_proto_version) }
+  end
+
+  def test_sslctx_set_params_min_version_on_less_than_openssl_11_or_libressl
+    if openssl?(1, 1, 0)
+      omit 'Omit in OpenSSL 1.1 or later versions'
+    end
+
+    ctx = OpenSSL::SSL::SSLContext.new
+    ctx.set_params
+
+    # This is not publicly exposed, but read the cached version.
+    assert_equal OpenSSL::SSL::TLS1_VERSION, ctx.send(:@min_proto_version)
+  end
+
   def test_post_connect_check_with_anon_ciphers
     ctx_proc = -> ctx {
       ctx.ssl_version = :TLSv1_2

ekohl · 2024-01-09T17:02:52Z

Nowadays we tend to separate the tests to small bits rater than adding the conditional assertions in one test.

Actually a very good practice and I completely understand you don't immediately refactor your entire test suite.

I've pushed your tests as an additional commit.

junaruga · 2024-01-10T15:44:57Z

@ekohl Sorry. Seeing the CI result: https://github.com/ruby/openssl/actions/runs/7464356851?pr=710, I forget considering the LibreSSL cases. I updated my proposed patch above adding the logic. I don't know why the OpenSSL 1.0.2u case is failing with NoMethodError.

And windows-latest (ruby) 3.3 case, it seems the OpenSSL::Provider.load("legacy") failing to load the legacy provider. I don't why it only happens in the case.
https://github.com/ruby/openssl/actions/runs/7464356851/job/20331465606?pr=710#step:9:637

junaruga · 2024-01-10T16:04:52Z

I filed the windows-latest (ruby) 3.3 case's issue on #711. We can ignore the issue on this PR as it is not related to this PR.

ekohl · 2024-01-10T16:39:06Z

I'm looking at the code and test logic.

I assume that OpenSSL::OPENSSL_VERSION doesn't start with OpenSSL so based on that I'd think it sets min_version (and ciphers) for LibreSSL. But then why does the test results say it doesn't set min_version for LibreSSL?

junaruga · 2024-01-10T16:53:06Z

I'm looking at the code and test logic.

I assume that OpenSSL::OPENSSL_VERSION doesn't start with OpenSSL so based on that I'd think it sets min_version (and ciphers) for LibreSSL. But then why does the test results say it doesn't set min_version for LibreSSL?

We are printing some constant values before running the tests. It seems the OpenSSL::OPENSSL_VERSION created from the OPENSSL_VERSION macro starts with OpenSSL in my impression.

https://github.com/ruby/openssl/actions/runs/7464356851/job/20331455533?pr=710#step:12:34

OpenSSL::OPENSSL_VERSION: OpenSSL 1.0.2u  20 Dec 2019
OpenSSL::OPENSSL_LIBRARY_VERSION: OpenSSL 1.0.2u  20 Dec 2019
OpenSSL::OPENSSL_VERSION_NUMBER: 1000215f

junaruga · 2024-01-10T17:15:47Z

Sorry I updated my proposal again.
And in OpenSSL 1.0 and Libre cases, the tests are failing with "NoMethodError: undefined method `@min_proto_version'".

The CI result is below as a refernece.
https://github.com/junaruga/ruby-openssl/actions/runs/7478375171/job/20353212727

junaruga · 2024-01-11T15:37:12Z

@ekohl Could you check this issue by installing OpenSSL 1.0 or LibreSSL on your environment?

A document to build the Ruby OpenSSL with different version's OpenSSL or LibreSSL is here.

If you want to compile and install OpenSSL 1.0 on Linux, it can be like this.

$ ./config \
  --prefix="/path/to/your_openssl_dir" \
  --libdir=lib \
  shared \
  '-Wl,-rpath,$(LIBRPATH)' \
  -O0 -g3 -ggdb3 -gdwarf-5
$ make -j4
$ make install

junaruga · 2024-01-11T21:18:11Z

You can rebase this PR on the latest master branch. The CI windows-latest 3.3 case's failures were fixed by a workaround.

test/openssl/test_ssl.rb

Both Red Hat and Debian-like systems configure the minimum TLS version to be 1.2 by default, but allow users to change this via configs. On Red Hat and derivatives this happens via crypto-policies[1], which in writes settings in /etc/crypto-policies/back-ends/opensslcnf.config. Most notably, it sets TLS.MinProtocol there. For Debian there's MinProtocol in /etc/ssl/openssl.cnf. Both default to TLSv1.2, which is considered a secure default. In constrast, the SSLContext has a hard coded OpenSSL::SSL::TLS1_VERSION for min_version. TLS 1.0 and 1.1 are considered insecure. By always setting this in the default parameters, the system wide default can't be respected, even if a developer wants to. This takes the approach that's also done for ciphers: it's only set for OpenSSL < 1.1.0. [1]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

ekohl · 2024-01-12T11:16:19Z

I've only applied the typo fix and omit statements. I haven't installed OpenSSL 1.0 myself yet to see what it does, but perhaps I can find some time for that later.

rhenium · 2024-01-13T10:22:11Z

We already have a test case for this, that #set_params won't allow connecting to SSL 3.0-only server:

openssl/test/openssl/test_ssl.rb

Lines 1159 to 1175 in 69384ac

    
           def test_set_params_min_version 
        
             supported = check_supported_protocol_versions 
        
             store = OpenSSL::X509::Store.new 
        
             store.add_cert(@ca_cert) 
        
             if supported.include?(OpenSSL::SSL::SSL3_VERSION) 
        
               # SSLContext#set_params properly disables SSL 3.0 by default 
        
               ctx_proc = proc { |ctx| 
        
                 ctx.min_version = ctx.max_version = OpenSSL::SSL::SSL3_VERSION 
        
               } 
        
               start_server(ctx_proc: ctx_proc, ignore_listener_error: true) { |port| 
        
                 ctx = OpenSSL::SSL::SSLContext.new 
        
                 ctx.set_params(cert_store: store, verify_hostname: false) 
        
                 assert_handshake_error { server_connect(port, ctx) { } } 
        
               } 
        
             end 
        
           end

Honestly I think this is enough. I could have pushed the merge button already, but I wanted to see what was causing the failure on Windows (you have figured it out - #711).

ekohl · 2024-01-13T10:52:16Z

Since this is now causing test failures, should I drop that commit then?

junaruga · 2024-01-13T10:56:15Z

Since this is now causing test failures, should I drop that commit then?

Yes, I think that you can drop the 2nd commit! As I don't understand the logic of testing this PR, I may check it later with OpenSSL 3 and 1.0 on my local. But it doesn't block the PR!

ekohl · 2024-01-13T22:29:30Z

Done

rhenium · 2024-01-17T16:42:40Z

Merged, thank you for the PR!

junaruga · 2024-04-03T16:16:14Z

I have investigated a bit about this PR because I may need to backport this PR's commit to downstream OpenSSL packages. Below is the summary. I am sure you guys already know about the information. But just in case for someone who is interested in the topic.

Fixed openssl gem versions

First, the actual merged commit on the master branch is ae215a4. This commit is not included in any released openssl gem versions yet. while the openssl gem current latest released version is 3.2.0. So, there are no fixed openssl gem versions yet.

Affected cases

This issue is that calling the OpenSSL::SSL::SSLContext#set_params would override the value of the TLS.MinProtocol in the OpenSSL config file. This issue can happen on the OpenSSL with the setting such as a Fedora's downstream OpenSSL RPM package referring to the setting (/etc/crypto-policies/back-ends/opensslcnf.config - TLS.MinProtocol = TLSv1.2) included in the RPM package named "crypto-policies". Below is an example on my local machine Fedora 39.

$ rpm -qf /etc/crypto-policies/back-ends/opensslcnf.config
crypto-policies-20231204-1.git1e3a2e4.fc39.noarch

$ grep '^TLS\.MinProtocol' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.2

Reproducing the issue

If we confirm the value of the set min_version, we need to run a HTTPS (SSL) server as this example. Because Ruby OpenSSL doesn't provide the readable attributes to check the actual values. I assume that this is due to a better security.

However, if we just check if a Ruby OpenSSL includes this commit in the code level, the reproducing script is as follows. the script refers to the cached variable @min_proto_version at the Ruby language level, as it was mentioned somewhere,

$ cat test.rb
require 'openssl'

ctx = OpenSSL::SSL::SSLContext.new
ctx.set_params
min_version = ctx.instance_variable_get(:@min_proto_version)
p min_version
puts "min_version hex=#{min_version&.to_s(16)}"

If a Ruby OpenSSL doesn't include this commit, the result is below. The 769 is the decimal number value of the OpenSSL::SSL::TLS1_VERSION. The 301 is the hexdecimal number value of it.

$ ruby -I lib test.rb
769
min_version hex=301

If a Ruby OpenSSL includes this commit, the result is below. The min_version to be propagated to a SSL server is empty. That means the TLS.MinProtocol in the OpenSSL's config file is used if it is set.

$ ruby -I lib test.rb
nil
min_version hex=

Note that OpenSSL::SSL::TLS1_VERSION and other OpenSSL::SSL::SOMETHING_VERSION constants are to get the name's macro value defined in OpenSSL.

openssl/ext/openssl/ossl_ssl.c

Lines 3111 to 3128 in d3d857c

    
               /* 
        
                * SSL/TLS version constants. Used by SSLContext#min_version= and 
        
                * #max_version= 
        
                */ 
        
               /* SSL 2.0 */ 
        
               rb_define_const(mSSL, "SSL2_VERSION", INT2NUM(SSL2_VERSION)); 
        
               /* SSL 3.0 */ 
        
               rb_define_const(mSSL, "SSL3_VERSION", INT2NUM(SSL3_VERSION)); 
        
               /* TLS 1.0 */ 
        
               rb_define_const(mSSL, "TLS1_VERSION", INT2NUM(TLS1_VERSION)); 
        
               /* TLS 1.1 */ 
        
               rb_define_const(mSSL, "TLS1_1_VERSION", INT2NUM(TLS1_1_VERSION)); 
        
               /* TLS 1.2 */ 
        
               rb_define_const(mSSL, "TLS1_2_VERSION", INT2NUM(TLS1_2_VERSION)); 
        
           #ifdef TLS1_3_VERSION /* OpenSSL 1.1.1 */ 
        
               /* TLS 1.3 */ 
        
               rb_define_const(mSSL, "TLS1_3_VERSION", INT2NUM(TLS1_3_VERSION)); 
        
           #endif

And the macros are defined in the OpenSSL's code below.

https://github.com/openssl/openssl/blob/882a387d0dc12afe8612c4d3f6b9cae5c04611d7/include/openssl/prov_ssl.h#L22-L30

junaruga · 2024-06-05T10:11:09Z

Hello @ekohl, I am trying to reproduce this issue with your HTTPD virtual host config and ruby script.

I prepared the script below.
https://github.com/junaruga/ruby-openssl-tls-min-version-test

When running the ruby script for this repository's master branch, the "tls-12" and "tls-13" cases that should pass, failed with "certificate verify failed (hostname mismatch)" instead of "Loaded from ...". Could you tell me how you did setup the SSL cert keys and etc?

+ ruby -I /home/jaruga/git/ruby/openssl/lib tmp/test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Failed to load from tls-12.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: certificate verify failed (hostname mismatch)
Failed to load from tls-13.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: certificate verify failed (hostname mismatch)

As a reference, the cert config file used to generate the SSL cert keys is below.

$ cat tmp/cert.conf
[ req ]
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
countryName_default            = CZ
stateOrProvinceName_default    = Brno
# The openssl command fails with "error, no objects specified in config file"
# without this item.
commonName = Common Name (hostname, IP, or your name)
commonName_default = example.com
localityName_default = Brno
organizationName_default = Test Organization
emailAddress_default = [email protected]

ekohl · 2024-06-05T11:42:54Z

It's been a while since I did that, but pretty sure I generated a certificate with the *.example.com subjectAltName. You can also generate a certificate per vhost, but for testing a wildcard was easier.

junaruga · 2024-06-05T16:10:17Z

@ekohl thanks for your quick reply!

I tried to set the subjectAltName as *.example.com in the cert config file. However, I didn't succeeded with it. Eventually I did set the commonName_default as *.example.com, and it worked!

As a reference, the commit for the change is the junaruga/ruby-openssl-tls-min-version-test@27524f1 .

diff --git a/assets/cert.conf.tmpl b/assets/cert.conf.tmpl
index 49e255c..0410cf4 100644
--- a/assets/cert.conf.tmpl
+++ b/assets/cert.conf.tmpl
@@ -7,7 +7,8 @@ stateOrProvinceName_default    = Brno
 # The openssl command fails with "error, no objects specified in config file"
 # without this item.
 commonName = Common Name (hostname, IP, or your name)
-commonName_default = @DOMAIN@
+# Enable all the sub-domains of the domain.
+commonName_default = *.@DOMAIN@
 localityName_default = Brno
 organizationName_default = Test Organization
 emailAddress_default = test@@DOMAIN@

Here is the generated SSL cert config file by my script.

$ cat tmp/cert.conf
[ req ]
distinguished_name = req_distinguished_name

[ req_distinguished_name ]
countryName_default            = CZ
stateOrProvinceName_default    = Brno
# The openssl command fails with "error, no objects specified in config file"
# without this item.
commonName = Common Name (hostname, IP, or your name)
# Enable all the sub-domains of the domain.
commonName_default = *.example.com
localityName_default = Brno
organizationName_default = Test Organization
emailAddress_default = [email protected]

Here is the local environment (Fedora 39) security policy setting.

$ update-crypto-policies --show
DEFAULT

$ grep '^TLS.Min' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.2

And the ruby script only refused the first 2 servers, the server with the protocol +TLSv1 and the server with the protocol +TLSv1.1 as expected in the environment.

$ ./test.sh
+ ruby -I /home/jaruga/git/ruby/openssl/lib tmp/test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Loaded from tls-12.example.com
Loaded from tls-13.example.com

junaruga · 2024-06-07T10:43:02Z

@ekohl I am seeing an unexpected behavior on my environment with the Ruby OpenSSL the latest master branch 818aa9f including this fix. I am using Fedora 39, and the following HTTPD and mod_ssl RPM packages. Do you have any idea about why this unexpected behavior happened?

$ rpm -q httpd mod_ssl
httpd-2.4.59-2.fc39.x86_64
mod_ssl-2.4.59-2.fc39.x86_64

I tested with the legacy security policy including TLS.MinProtocol = TLSv1.

$ sudo update-crypto-policies --set LEGACY

$ sudo reboot

$ update-crypto-policies --show
LEGACY

$ grep '^TLS.Min' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1

But the result showed the tls-10 and tls-11 servers still rejected the access unexpectedly.

$ ./test.sh
+ ruby -I /home/jaruga/git/ruby/openssl/lib tmp/test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Loaded from tls-12.example.com
Loaded from tls-13.example.com

I edited to change the TLSv1 to TLSv1.0 to test with TLS.MinProtocol = TLSv1.0 as you reported just in case.

$ sudo vi /etc/crypto-policies/back-ends/opensslcnf.config

$ grep '^TLS.Min' /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.0

$ sudo systemctl stop httpd.service

$ sudo systemctl start httpd.service

But I still saw the same unexpected result that the tls-10 and tls-11 servers rejected the access.

$ ./test.sh
+ ruby -I /home/jaruga/git/ruby/openssl/lib tmp/test.rb
Failed to load from tls-10.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Failed to load from tls-11.example.com: SSL_connect returned=1 errno=0 peeraddr=127.0.0.1:443 state=error: tlsv1 alert protocol version (SSL alert number 70)
Loaded from tls-12.example.com
Loaded from tls-13.example.com

I am using the same httpd config like you.

$ cat /etc/httpd/conf.d/z-ssl-tls-test.conf
<VirtualHost *:443>
    ServerName tls-10.example.com
    DocumentRoot /var/www/html
    SSLEngine on
    SSLProtocol -all +TLSv1
    SSLCertificateFile "/etc/pki/tls/certs/test.crt"
    SSLCertificateKeyFile "/etc/pki/tls/private/test.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-11.example.com
    DocumentRoot /var/www/html
    SSLEngine on
    SSLProtocol -all +TLSv1.1
    SSLCertificateFile "/etc/pki/tls/certs/test.crt"
    SSLCertificateKeyFile "/etc/pki/tls/private/test.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-12.example.com
    DocumentRoot /var/www/html
    SSLEngine on
    SSLProtocol -all +TLSv1.2
    SSLCertificateFile "/etc/pki/tls/certs/test.crt"
    SSLCertificateKeyFile   "/etc/pki/tls/private/test.key"
</VirtualHost>

<VirtualHost *:443>
    ServerName tls-13.example.com
    DocumentRoot /var/www/html
    SSLEngine on
    SSLProtocol -all +TLSv1.3
    SSLCertificateFile "/etc/pki/tls/certs/test.crt"
    SSLCertificateKeyFile   "/etc/pki/tls/private/test.key"
</VirtualHost>

And the test.rb is the same with you. I just adjusted the indents.

$ cat tmp/test.rb
require 'net/http'

domains = [
  'tls-10.example.com',
  'tls-11.example.com',
  'tls-12.example.com',
  'tls-13.example.com',
]

ca_file = 'tmp/test.crt'

domains.each do |domain|
  uri = URI("https://#{domain}")
  begin
    Net::HTTP.start(domain, 443, use_ssl: true, ca_file: ca_file) do |http|
      http.get(uri)
    end
  rescue StandardError => e
    puts "Failed to load from #{domain}: #{e}"
  else
    puts "Loaded from #{domain}"
  end
end

junaruga · 2024-06-07T14:03:41Z

Maybe I was able to reproduce the issue the tls-10 and tls-11 servers rejecting a SSL client access in the environment where the OS security policy is TLS.MinProtocol = TLSv1 by using openssl s_client command printing the detailed information.

The Bash script is below.

$ cat tmp/test_with_openssl_s_client.sh
#!/bin/bash

set -euxo pipefail

DOMAINS='
    tls-10.example.com
    tls-11.example.com
    tls-12.example.com
    tls-13.example.com
'
CA_FILE='tmp/test.crt'
LOG_DIR="log/openssl-s_client"

rm -rf "${LOG_DIR}"
mkdir -p "${LOG_DIR}"

for domain in ${DOMAINS}; do
    if ! openssl s_client -connect "${domain}:443" -CAfile "${CA_FILE}" \
        > "${LOG_DIR}/${domain}.stdout.log" \
        2> "${LOG_DIR}/${domain}.stderr.log"; then
        echo "Failed from ${domain}"
    else
        echo "Passed from ${domain}"
    fi
done

The executing result is below. You can see the messages about the failing for "tls-10.example.com" and "tls-11.example.com", and the messages about passing for "tls-12.example.com" and "tls-13.example.com".

$ ./tmp/test_with_openssl_s_client.sh
+ DOMAINS='
    tls-10.example.com
    tls-11.example.com
    tls-12.example.com
    tls-13.example.com
'
+ CA_FILE=tmp/test.crt
+ LOG_DIR=log/openssl-s_client
+ rm -rf log/openssl-s_client
+ mkdir -p log/openssl-s_client
+ for domain in ${DOMAINS}
+ openssl s_client -connect tls-10.example.com:443 -CAfile tmp/test.crt
+ echo 'Failed from tls-10.example.com'
Failed from tls-10.example.com
+ for domain in ${DOMAINS}
+ openssl s_client -connect tls-11.example.com:443 -CAfile tmp/test.crt
+ echo 'Failed from tls-11.example.com'
Failed from tls-11.example.com
+ for domain in ${DOMAINS}
+ openssl s_client -connect tls-12.example.com:443 -CAfile tmp/test.crt

+ echo 'Passed from tls-12.example.com'
Passed from tls-12.example.com
+ for domain in ${DOMAINS}
+ openssl s_client -connect tls-13.example.com:443 -CAfile tmp/test.crt

+ echo 'Passed from tls-13.example.com'
Passed from tls-13.example.com

As a reference, you can check the stdout and stderr logs by the openssl s_client command for each TLS server.
https://github.com/junaruga/ruby-openssl-tls-min-version-test/tree/main/log/openssl-s_client

junaruga · 2024-06-07T17:18:13Z

Just quick update. I asked the issue above which I faced to my colleagues, and it seems that they found the cause and how to fix. I will share it here later next week.

ekohl · 2024-06-07T18:30:50Z

I appreciate writing proper tests for this. I'm back in the office on Wednesday, I'll try to find time for a proper review then.

junaruga · 2024-06-07T19:22:16Z

All right!

In my understanding of my colleague's message so far, the issue I reported above is that the virtual hosts config file which we use doesn't work in OpenSSL 3. And you confirmed your reproducer in CentOS Stream 8 where the OpenSSL version is 1.1.1 series. So, maybe you didn't see the issue. In my case, I need to modify the virtual hosts config file to work in OpenSSL 3. So far I don't see any other issues in Ruby OpenSSL.

junaruga · 2024-06-14T15:27:10Z

@ekohl Let me explain my working status to reproduce the fix with your script. I was able to reproduce the fix on my Fedora Linux with the OpenSSL RPM referring to the OS's crypto policy config files.

You can see the test results in the README.md on https://github.com/junaruga/ruby-openssl-tls-min-version-test . The above issue I commented was not related to my script's failures.

There were 3 issues for my testings. And the junaruga/ruby-openssl-tls-min-version-test@35d9bd4 fixed the 2 issues.

The 1st issue was the assets/test_with_openssl_s_client.sh.tmpl, in the Bash testing script, I needed to openssl s_client command's stdin to the /dev/null for the command to finish the connection's waiting status.

The 2nd issue was the setup.sh script. I needed to replace the SECLEVEL=1 with SECLEVEL=0 in the /etc/crypto-policies/back-ends/opensslcnf.config. Maybe the SECLEVEL is equivalent with the security level at the SSL_CTX_set_security_level (https://www.openssl.org/docs/man3.1/man3/SSL_CTX_set_security_level.html).

Fixing the 2 issues made the testing with the openssl s_client worked as expected.

And the 3rd issue was I was building the Ruby OpenSSL with the upstream OpenSSL Ruby not with the downstream OpenSSL RPM. And the behavior showed the SSL servers only allowed TLS 1.2 and 1.3 connection, and rejected TLS 1.0 and 1.1 connection. Perhaps the upstream OpenSSL may have the own limitation about the supported TLS versions. I plan to ask this question to the upstream OpenSSL project.

I was also told by my colleague that there was openssl s_server command to run a SSL server instead of HTTPD. I think it is better than HTTPD for testing purpose. Because it's simple, and it's easy to run by regular user. So, we may be able to use it in our unit tests for example.

ekohl · 2024-06-15T11:46:37Z

And the 3rd issue was I was building the Ruby OpenSSL with the upstream OpenSSL Ruby not with the downstream OpenSSL RPM. And the behavior showed the SSL servers only allowed TLS 1.2 and 1.3 connection, and rejected TLS 1.0 and 1.1 connection. Perhaps the upstream OpenSSL may have the own limitation about the supported TLS versions. I plan to ask this question to the upstream OpenSSL project.

The PROFILE=SYSTEM option is a Red Hat patch that's not in upstream: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0007-Add-support-for-PROFILE-SYSTEM-system-default-cipher.patch

Additionally, loading from crypto-policies is also patched in RPM packaging: https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0004-Override-default-paths-for-the-CA-directory-tree.patch

I was also looking at Debian. In bullseye (Debian 11) there https://sources.debian.org/patches/openssl/1.1.1w-0%2Bdeb11u1/Set-systemwide-default-settings-for-libssl-users.patch/ but I can't see a similar patch for bookworm (Debian 12). Though https://www.openssl.org/news/openssl-3.1-notes.html mentions that SSL 3, TLS 1.0 and TLS 1.1 only work at security level 0 starting OpenSSL 3.1 (included in Debian 12) while I think the default security level is 2 (could also be 1).

junaruga · 2024-09-20T09:52:01Z

Sorry for my late response.

Yes, I learned the difference between the upstream OpenSSL and downstream OpenSSL (Fedora OpenSSL RPM, Debian OpenSSL deb package). It seems to me that the upstream OpenSSL doesn't have a logic like Fedora's crypto-policies which overrides TLS minimal version setting. We need to think both upstream and downstream OpenSSL cases separately.

I was also told by my colleague that there was openssl s_server command to run a SSL server instead of HTTPD. I think it is better than HTTPD for testing purpose. Because it's simple, and it's easy to run by regular user. So, we may be able to use it in our unit tests for example.

I updated my reproducing script: https://github.com/junaruga/ruby-openssl-tls-min-version-test, implementing the openssl s_server instead of HTTPD to run SSL server. The script covers both upstream and downstream (Fedora/CentOS Stream/RHEL OpenSSL RPM) cases.

Initially I wanted to contribute the tests into this Ruby OpenSSL project based on my reproducing script's tests. However, I think that this project's scope is only the cases with the upstream OpenSSL versions. See the CI file: .github/workflows/test.yml. And if I contribute the tests into this project, I have to prepare a Fedora container to test with Fedora's OpenSSL RPM that overrides the TLS minimal version setting by the OS's crypto-policies to test this patch. And I don't want to do it. Because this is out of this project's scope. So, I plan to contribute the tests into Fedora's Ruby.

rhenium mentioned this pull request Jan 8, 2024

Respect system wide minimum TLS version #709

Closed

rhenium approved these changes Jan 8, 2024

View reviewed changes

ekohl mentioned this pull request Jan 8, 2024

Fixes #36979 - Change cdn_ssl_version setting to cdn_min_tls_version Katello/katello#10824

Closed

olleolleolle reviewed Jan 12, 2024

View reviewed changes

test/openssl/test_ssl.rb Outdated Show resolved Hide resolved

ekohl force-pushed the dont-set-min_version-by-default branch from 9836dbc to 104d68f Compare January 12, 2024 11:14

ekohl force-pushed the dont-set-min_version-by-default branch from 104d68f to ae215a4 Compare January 13, 2024 22:28

rhenium merged commit 559b8ed into ruby:master Jan 17, 2024
49 checks passed

ekohl deleted the dont-set-min_version-by-default branch January 17, 2024 17:11

junaruga mentioned this pull request Feb 3, 2025

test_ssl.rb: Test respecting system default min. #851

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Only set min_version on OpenSSL < 1.1.0 #710

Only set min_version on OpenSSL < 1.1.0 #710

ekohl commented Jan 5, 2024

ekohl commented Jan 8, 2024

rhenium left a comment

junaruga commented Jan 8, 2024

ekohl commented Jan 9, 2024

junaruga commented Jan 9, 2024 •

edited

Loading

ekohl commented Jan 9, 2024

junaruga commented Jan 10, 2024

junaruga commented Jan 10, 2024

ekohl commented Jan 10, 2024

junaruga commented Jan 10, 2024

junaruga commented Jan 10, 2024 •

edited

Loading

junaruga commented Jan 11, 2024 •

edited

Loading

junaruga commented Jan 11, 2024 •

edited

Loading

ekohl commented Jan 12, 2024

rhenium commented Jan 13, 2024

ekohl commented Jan 13, 2024

junaruga commented Jan 13, 2024 •

edited

Loading

ekohl commented Jan 13, 2024

rhenium commented Jan 17, 2024

junaruga commented Apr 3, 2024 •

edited

Loading

junaruga commented Jun 5, 2024 •

edited

Loading

ekohl commented Jun 5, 2024

junaruga commented Jun 5, 2024 •

edited

Loading

junaruga commented Jun 7, 2024 •

edited

Loading

junaruga commented Jun 7, 2024 •

edited

Loading

junaruga commented Jun 7, 2024

ekohl commented Jun 7, 2024

junaruga commented Jun 7, 2024 •

edited

Loading

junaruga commented Jun 14, 2024

ekohl commented Jun 15, 2024

junaruga commented Sep 20, 2024

Only set min_version on OpenSSL < 1.1.0 #710

Only set min_version on OpenSSL < 1.1.0 #710

Conversation

ekohl commented Jan 5, 2024

ekohl commented Jan 8, 2024

rhenium left a comment

Choose a reason for hiding this comment

junaruga commented Jan 8, 2024

ekohl commented Jan 9, 2024

junaruga commented Jan 9, 2024 • edited Loading

ekohl commented Jan 9, 2024

junaruga commented Jan 10, 2024

junaruga commented Jan 10, 2024

ekohl commented Jan 10, 2024

junaruga commented Jan 10, 2024

junaruga commented Jan 10, 2024 • edited Loading

junaruga commented Jan 11, 2024 • edited Loading

junaruga commented Jan 11, 2024 • edited Loading

ekohl commented Jan 12, 2024

rhenium commented Jan 13, 2024

ekohl commented Jan 13, 2024

junaruga commented Jan 13, 2024 • edited Loading

ekohl commented Jan 13, 2024

rhenium commented Jan 17, 2024

junaruga commented Apr 3, 2024 • edited Loading

Fixed openssl gem versions

Affected cases

Reproducing the issue

junaruga commented Jun 5, 2024 • edited Loading

ekohl commented Jun 5, 2024

junaruga commented Jun 5, 2024 • edited Loading

junaruga commented Jun 7, 2024 • edited Loading

junaruga commented Jun 7, 2024 • edited Loading

junaruga commented Jun 7, 2024

ekohl commented Jun 7, 2024

junaruga commented Jun 7, 2024 • edited Loading

junaruga commented Jun 14, 2024

ekohl commented Jun 15, 2024

junaruga commented Sep 20, 2024

junaruga commented Jan 9, 2024 •

edited

Loading

junaruga commented Jan 10, 2024 •

edited

Loading

junaruga commented Jan 11, 2024 •

edited

Loading

junaruga commented Jan 11, 2024 •

edited

Loading

junaruga commented Jan 13, 2024 •

edited

Loading

junaruga commented Apr 3, 2024 •

edited

Loading

junaruga commented Jun 5, 2024 •

edited

Loading

junaruga commented Jun 5, 2024 •

edited

Loading

junaruga commented Jun 7, 2024 •

edited

Loading

junaruga commented Jun 7, 2024 •

edited

Loading

junaruga commented Jun 7, 2024 •

edited

Loading