Bug 1090952 - Do not send ECC ciphersuites in SSLv2 client hello
Summary: Do not send ECC ciphersuites in SSLv2 client hello
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssl
Version: 6.5
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Hubert Kario
URL: http://cpansearch.perl.org/src/MIKEM/...
Depends On:
TreeView+ depends on / blocked
Reported: 2014-04-24 12:59 UTC by Tomas Mraz
Modified: 2018-12-04 17:52 UTC (History)
6 users (show)

Fixed In Version: openssl-1.0.1e-26.el6
Doc Type: Bug Fix
Doc Text:
In TLS client applications that use SSLv2 ClientHello requests, the support for Elliptic Curve Cryptography (ECC)-based cipher suites was previously advertised, but the TLS extension giving the list of supported elliptic curves could not be sent. This caused a TLS connection to a server which used an elliptic curve not supported by the OpenSSL client to abort. With this update, the ECC-based cipher suites are not sent in the SSLv2 ClientHello request, and TLS connections are no longer aborted in the above circumstances.
Clone Of: 1044401
: 1090955 (view as bug list)
Last Closed: 2014-10-14 07:19:52 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1525 normal SHIPPED_LIVE openssl bug fix and enhancement update 2014-10-14 01:22:05 UTC

Description Tomas Mraz 2014-04-24 12:59:17 UTC
+++ 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):

How reproducible:

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";

        return 0;

my $test = ldap_query();

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

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 
@ .. 
@ } 
@ 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.

Comment 1 Tomas Mraz 2014-04-24 13:01:24 UTC
Also I am currently evaluating the possibility of removing SSLv2 cipher suites from the ALL list. But this should be probably rather RHEL-7 change.

Comment 5 errata-xmlrpc 2014-10-14 07:19:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.