Bug 1775167

I confirm this issue.

A chain of libraries used is: Net::LDAPS → IO::Socket::SSL → Net::SSLeay → libssl.so. I observe the same behavior on IO::Socket::SSL level:

#!/usr/bin/perl
use IO::Socket::SSL;
my $conn = IO::Socket::SSL->new(
        'PeerHost' => 'localhost',
        'PeerPort' => 2000,
        SSL_verify_mode => SSL_VERIFY_NONE,
) or die "error=$!, ssl_error=$SSL_ERROR\n";
$conn->close();

(I also noticed that Net::LDAPS does not verify the server certificate by default and the default behavior is not documented. I raised a question to the upstream <https://rt.cpan.org/Ticket/Display.html?id=131045>).

And this is a Net:SSLay client:

#!/usr/bin/perl                                                                 
use IO::Socket::IP;
use Net::SSLeay 1.82;

my $tcp = IO::Socket::IP->new(
        PeerHost=>'localhost',
        PeerPort=>2000,
        Type => SOCK_STREAM,
) or die "creating socket failed: $@";

$tcp->connect or die "TCP connect() failed: $!";

Net::SSLeay::initialize();
my $method = Net::SSLeay::TLS_client_method() or
        die "TLS_client_method() failed";

my $ctx = Net::SSLeay::CTX_new_with_method($method) or
        die "CTX_tlsv1_new() failed";

Net::SSLeay::CTX_set_options($ctx, &Net::SSLeay::OP_ALL) or
        die "CTX_set_options() failed";

my $ssl = Net::SSLeay::new($ctx) or
        die "new() failed";
Net::SSLeay::set_verify($ssl, Net::SSLeay::VERIFY_NONE, undef);
Net::SSLeay::set_fd($ssl, fileno($tcp)) or
        die "set_fd() failed";

if (1 != Net::SSLeay::connect($ssl)) {
        Net::SSLeay::die_now "connect() failed, errno=$!";
}
print "Used cipher: ", Net::SSLeay::get_cipher($ssl), "\n";

if (0 == Net::SSLeay::shutdown($ssl)) {
        Net::SSLeay::read($ssl)
}

Net::SSLeay::free($ssl);
Net::SSLeay::CTX_free($ctx);

$tcp->close;


that does not suffer from the issue. Thus the culprit is IO::Socket::SSL.

IO::Socket::SSL passes "DEFAULT" string to Net::SSLeay::CTX_set_cipher_list() that
is passed to OpenSSL SSL_CTX_set_cipher_list(). OpenSSL manual reads:

    SSL_CTX_set_cipher_list() sets the list of available ciphers (TLSv1.2
    and below) for ctx using the control string str. The format of the
    string is described in ciphers(1). The list of ciphers is inherited by
    all ssl objects created from ctx. This function does not impact TLSv1.3
    ciphersuites. Use SSL_CTX_set_ciphersuites() to configure those.

SSL_CTX_set_ciphersuites() is documented as:

    SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3
    ciphersuites for ctx. This is a simple colon (":") separated list of
    TLSv1.3 ciphersuite names in order of preference.

IO::Socket::SSL does not call Net::SSLeay::CTX_set_ciphersuites() at all.
Only Net::SSLeay::CTX_set_cipher_list(). I tried connecting
with "openssl s_client -connect localhost:2000 -cipher DEFAULT" and it exhibits
exactly the same change in advertised ciphersuites as IO::Socket::SSL.

So I can see to problems:

(1) "DEFAULT" is not the same as a default cryptopolicy.
(2) Setting TLsv1.2 ciphers affects TLSv1.3 contrary to to documentation.

(In reply to Petr Pisar from comment #4)
> (1) "DEFAULT" is not the same as a default cryptopolicy.
Correct identifier for the system-wide cipher list for OpenSSL is "PROFILE=SYSTEM".
See <https://fedoraproject.org/wiki/Packaging:CryptoPolicies#C.2FC.2B.2B_applications>.

> (2) Setting TLsv1.2 ciphers affects TLSv1.3 contrary to to documentation.
This is OpenSSL issue.

Proposed fix is correcting aIO-Socket-SSL-2.066-use-system-default-cipher-list.patch patch:

--- a/IO-Socket-SSL-2.066-use-system-default-cipher-list.patch
+++ b/IO-Socket-SSL-2.066-use-system-default-cipher-list.patch
@@ -12,7 +12,7 @@
 +    # Use system-wide default cipher list to support use of system-wide
 +    # crypto policy (#1076390, #1127577, CPAN RT#97816)
 +    # https://fedoraproject.org/wiki/Changes/CryptoPolicy
-+    SSL_cipher_list => 'DEFAULT',
++    SSL_cipher_list => 'PROFILE=SYSTEM',
  );
  
  my %DEFAULT_SSL_CLIENT_ARGS = (

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1673