+++ This bug was initially created as a clone of Bug #1090966 +++

+++ This bug was initially created as a clone of Bug #1044401 +++

Description of problem:
LDAPS connection fails with error: "IO::Socket::SSL: SSL connect attempt failed with unknown errorerror:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group"

Version-Release number of selected component (if applicable):
openssl-1.0.1e-15.el6.x86_64
openssl-1.0.1e-16.el6_5.x86_64

How reproducible:
#!/usr/bin/perl                                                                 

sub ldap_query {
        use Net::LDAPS;

        my $conn = Net::LDAPS->new('ldap.example.com',
                                 version => 3,
                                 port => 636,
                                 capath => '/etc/openldap/cacerts/',
                                 raw => qr/^$/
                               ) || die "$@\n";

        $conn->disconnect();
        return 0;
}

my $test = ldap_query();

Steps to Reproduce:
1. Run above script against suitable ldap-server
2.
3.

Actual results:
IO::Socket::SSL: SSL connect attempt failed with unknown errorerror:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group

Expected results:
Empty output

Additional info:
Downgrade to openssl-1.0.0-27.el6_4.2.x86_64 solves the issue.

[...]
--- Additional comment from Tomas Mraz on 2014-04-24 09:03:10 GMT ---

Now when I finally got a readable packet dump I have to agree that the message the client is sending is incorrect. I really wonder though why the SSLv2 client hello message format is used as the default is set such that OpenSSL uses the SSLv3 client hello format.

Petr, does the perl layer set some non-default SSL cipher list string? The SSLv2 client hello is used because there are SSL2_.... ciphers in the cipher list although they are not supposed to be there unless explicitly configured so by user.

Nevertheless sending the ECC cipher suites in the SSLv2 client hello can be seen as openssl bug as well because there is no way to indicate the supported curve list in the SSLv2 client hello. So this report should be split to two bugs.

--- Additional comment from Petr Pisar on 2014-04-24 12:40:14 GMT ---

There many perl layers above OpenSSL, but the one which changes protocol version and cipher list from the OpenSSL default is Net::LDAP itself (package perl-LDAP).

Net::LDAP sets in case of implicit SSL (ldaps scheme):

  'SSL_version' => 'sslv2/3',
  'SSL_cipher_list' => 'ALL',

while in case of explicit SSL (STARTTLS inside LDAP protocol):

  'SSL_version' => 'tlsv1',
  'SSL_cipher_list' => 'ALL',

This test case is about the first case. And it can be reproduced with openssl(1) tool:

$ openssl s_client -connect 127.0.0.1:2000 -cipher ALL

Please note the current upstream perl-ldap still does that. Except the 'sslv2/3' spelling has been updated to 'sslv23'.

I guess there is no OpenSSL cipher list string for the-default-one, because the perl code looks like:

  SSL_cipher_list     => defined $arg->{ciphers} ? $arg->{ciphers} : 'ALL'

which is the reason why the default Net::LDAPS behavior is enabling all ciphers.

--- Additional comment from Tomas Mraz on 2014-04-24 12:55:23 GMT ---

The SSL_version setting is probably no problem. However the ALL cipher list string really should not be used. Either the cipher list should not be set at all or the 'DEFAULT' string could be used.
-----

I believe not setting SSL_cipher_list if ciphers argument not passed by Net::LDAPS application is the best option.

--- Additional comment from Petr Pisar on 2014-04-24 14:40:58 GMT ---

This fix has been proposed to the perl-ldap upstream.

--- Additional comment from Petr Pisar on 2014-04-25 07:08:43 GMT ---

How to test:

(1) Start an SSL server.
(2) Run a simple Net::LDAPS client without `ciphers' option against the server.
(3) Compare list of ciphers advertised by the client to the server against DEFAULT OpenSSL list (see `openssl ciphers DEFAULT' command output).
Before:
  The lists differ.
After:
  The lists are identical.
-----

perl-LDAP-0.56-2.el7.noarch (with openssl-libs-1.0.1e-34.el7.x86_64) is affected too.