+++ 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 Deepak Das on 2014-04-23 08:52:57 CEST ---

Hi Tomas,

I have attached the file "tcpdump.txt" showing all the fields of all protocols in the packets from the tcpdump. It also has the "Client Hello" section.

Please check and confirm if it is useful.

--- Additional comment from John Wagner on 2014-04-24 01:29:03 CEST ---

Response from the ticket I have with Oracle:

@ when looking at the provided ssltap output it clearly shows that the perl 
@ client (and the underlying openssl libs) does not offer any extension and 
@ that our server does not use any extension in this case: 
@ . 
@ [Fri Apr 18 15:33:55 2014] [ssl2] ClientHelloV2 { 
@ version = {0x03, 0x03} 
@ cipher-specs-length = 297 (0x129) 
@ sid-length = 0 (0x00) 
@ challenge-length = 16 (0x10) 
@ cipher-suites = { 
@ .. 
@ (0x00c014) TLS/ECDHE-RSA/AES256-CBC/SHA 
@ .. 
@ (0x0000ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
@ } 
@ session-id = { } 
@ challenge = { 0x771a 0x2919 0x3fec 0x68a6 0xda7b 0xd3c7 0xdc17 
@ 0xfab6 } 
@ } 
@ ] 
@ .. 
@ SSLRecord { [Fri Apr 18 15:33:55 2014] 
@ type = 22 (handshake) 
@ version = { 3,1 } 
@ length = 4368 (0x1110) 
@ handshake { 
@ type = 2 (server_hello) 
@ length = 77 (0x00004d) 
@ ServerHello { 
@ server_version = {3, 1} 
@ random = {...} 
@ session ID = { 
@ length = 32 
@ contents = {...} 
@ } 
@ cipher_suite = (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA 
@ compression method = (00) NULL 
@ extensions[5] = { 
@ extension type renegotiation_info, length [1] = { 
@ 0: 00 | . 
@ } 
@ } 
@ } 
@ type = 12 (server_key_exchange) 
@ length = 319 (0x00013f) 
@ type = 14 (server_hello_done) 
@ length = 0 (0x000000) 
@ } 
@ } 
@ ] 
@ . 
@ other than "renegotiation_info" whose length field is set to zero when 
@ receiving a TLS_EMPTY_RENEGOTIATION_INFO_SCSV "cipher-suite" in the SSL 
@ Client Hello packet, which is in accordance to RFC 5746 Section 3.4 
@ . 
@ The server chooses the SSL3/DHE-RSA/DES40-CBC/SHA cipher-suite as offered by 
@ the client w/o choosing any specific "elliptic_curves" extension (as claimed 
@ by RedHat) and replies with that to the client. 
@ . 
@ By the way, the same works when using an openSSL 1.0.1g client as shown in my 
@ example. The "renegotiation_info" related handshake packets are exactly the 
@ same as with the failing perl client - the client sends a 
@ "TLS_EMPTY_RENEGOTIATION_INFO_SCSV" cipher-suite and the server replies with: 
@ . 
@ . 
@ extension type renegotiation_info, length [1] = { 
@ 0: 00 | . 
@ } 
@ . 
@ so this cannot be the reason of the failing handshake. The 1.0.1g client 
@ offers some additional extensions like "ec_point_formats", "elliptic_curves", 
@ etc. which our server then uses accordingly. 
@ . 
@ So to me this clearly looks like a bug in the specific openSSL version that 
@ the customer is using. 
@ . 
@ Feel free to forward both ssltap outputs to RedHat and let them elaborate why 
@ the eventfully still think that our server is misbehaving. 

-----


@ To add on the above: 
@ . 
@ RFC 4492 Section 4 (TLS Extensions for ECC) defines: 
@ . 
@ " 
@ A TLS client that proposes ECC cipher suites in its ClientHello 
@ message SHOULD include these extensions. Servers implementing ECC 
@ cipher suites MUST support these extensions, and when a client uses 
@ these extensions, servers MUST NOT negotiate the use of an ECC cipher 
@ suite unless they can complete the handshake while respecting the 
@ choice of curves and compression techniques specified by the client. 
@ This eliminates the possibility that a negotiated ECC handshake will 
@ be subsequently aborted due to a client's inability to deal with the 
@ server's EC key. 
@ . 
@ The client MUST NOT include these extensions in the ClientHello 
@ message if it does not propose any ECC cipher suites. A client that 
@ proposes ECC cipher suites may choose not to include these 
@ extensions. In this case, the server is free to choose any one of 
@ the elliptic curves or point formats listed in Section 5. That 
@ section also describes the structure and processing of these 
@ extensions in greater detail. 
@ " 
@ . 
@ In our specific case of the failing perl client the client DOES propose ECC 
@ cipher suites (TLS/ECDHE-RSA/AES256-CBC/SHA) but DOES NOT (although it 
@ SHOULD) include the "elliptic_curves" extension to indicate the set of 
@ elliptic curves supported by the client. In this case "the server is free to 
@ choose any one of the elliptic curves or point formats listed in Section 5." 
@ . 
@ So this is what our server does: it chooses a curve that the client is 
@ apparently unable to handle. But this is in accordance with RFC 4492 since 
@ the client did not include the "elliptic_curves" extension in the Client 
@ Hello handshake packet. So imo the client is misbehaving - if it cannot 
@ handle all curves it should include the "elliptic_curves" extension and 
@ specify what curves it is able to handle.

--- Additional comment from Tomas Mraz on 2014-04-24 11:03:10 CEST ---

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.