Are you sure this happens with openssl-1.0.1e-16.el6_5.x86_64?

[antti@XXXXX ~]$ ./test.pm
IO::Socket::SSL: SSL connect attempt failed with unknown errorerror:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group
[antti@XXXXX ~]$ yum info openssl
Loaded plugins: product-id, rhnplugin, security, subscription-manager
*Note* Red Hat Network repositories are not listed below. You must run this command as root to access RHN repositories.
Installed Packages
Name        : openssl
Arch        : x86_64
Version     : 1.0.1e
Release     : 16.el6_5.1
Size        : 4.0 M
Repo        : installed
From repo   : rhel-x86_64-server-6
Summary     : A general purpose cryptography library with TLS implementation
URL         : http://www.openssl.org/
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool
            : and shared libraries which provide various cryptographic
            : algorithms and protocols.

Can you attach the LDAPS server certificates? Both CA and server.

Here is the list of SSL ciphers supported by the remote server. Does this answer your question or do you need the actual certificates?

  Low Strength Ciphers (< 56-bit key)
    SSLv3
      EXP-RC2-CBC-MD5              Kx=RSA(512)    Au=RSA      Enc=RC2(40)              Mac=MD5    export     
      EXP-RC4-MD5                  Kx=RSA(512)    Au=RSA      Enc=RC4(40)              Mac=MD5    export     

    TLSv1
      EXP-RC2-CBC-MD5              Kx=RSA(512)    Au=RSA      Enc=RC2-CBC(40)          Mac=MD5    export     
      EXP-RC4-MD5                  Kx=RSA(512)    Au=RSA      Enc=RC4(40)              Mac=MD5    export     

  Medium Strength Ciphers (>= 56-bit and < 112-bit key)
    SSLv3
      DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-CBC(56)          Mac=SHA1   

    TLSv1
      EXP1024-DES-CBC-SHA          Kx=RSA(1024)   Au=RSA      Enc=DES-CBC(56)          Mac=SHA1   export     
      EXP1024-RC4-SHA              Kx=RSA(1024)   Au=RSA      Enc=RC4(56)              Mac=SHA1   export     
      DES-CBC-SHA                  Kx=RSA         Au=RSA      Enc=DES-CBC(56)          Mac=SHA1   

  High Strength Ciphers (>= 112-bit key)
    SSLv3
      DES-CBC3-SHA                 Kx=RSA         Au=RSA      Enc=3DES(168)            Mac=SHA1   
      RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(128)             Mac=MD5    
      RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(128)             Mac=SHA1   

    TLSv1
      ECDHE-RSA-DES-CBC3-SHA       Kx=ECDH        Au=RSA      Enc=3DES-CBC(168)        Mac=SHA1   
      ECDHE-RSA-AES128-SHA         Kx=ECDH        Au=RSA      Enc=AES-CBC(128)         Mac=SHA1   
      ECDHE-RSA-AES256-SHA         Kx=ECDH        Au=RSA      Enc=AES-CBC(256)         Mac=SHA1   
      ECDHE-RSA-RC4-SHA            Kx=ECDH        Au=RSA      Enc=RC4(128)             Mac=SHA1   
      DES-CBC3-SHA                 Kx=RSA         Au=RSA      Enc=3DES-CBC(168)        Mac=SHA1   
      AES128-SHA                   Kx=RSA         Au=RSA      Enc=AES-CBC(128)         Mac=SHA1   
      AES256-SHA                   Kx=RSA         Au=RSA      Enc=AES-CBC(256)         Mac=SHA1   
      CAMELLIA128-SHA              Kx=RSA         Au=RSA      Enc=Camellia-CBC(128)    Mac=SHA1   
      CAMELLIA256-SHA              Kx=RSA         Au=RSA      Enc=Camellia-CBC(256)    Mac=SHA1   
      RC4-MD5                      Kx=RSA         Au=RSA      Enc=RC4(128)             Mac=MD5    
      RC4-SHA                      Kx=RSA         Au=RSA      Enc=RC4(128)             Mac=SHA1   
      SEED-SHA                     Kx=RSA         Au=RSA      Enc=SEED-CBC(128)        Mac=SHA1

I need to know if the server uses ECDSA in the certificate. But according to the list above it does not seem so because the authentication is RSA based. Does any connection attempt happen at all, or does it break later after the TLS Client hello is sent? Can you investigate it with wireshark?

I compared the attempts with current openssl and with downgraded openssl.

The downgraded (functioning) openssl:
C: Client Hello
S: Server Hello, Certificate, Certificate Request, Server Hello Done
C: Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
S: Change Cipher Spec, Encrypted Handshake Message

The current (malfunctioning) openssl:
C: Ignored Unknown Record
S: Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done

Anything further on this?  Having same results.

IO::Socket::SSL: SSL connect attempt failed with unknown errorerror:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group at ./m3.pl line 67, <DATA> line 522.

Downgraded to the 6.4 rpm and it works.

Unfortunately I am still unable to reproduce the problem. There must be something peculiar with the server.

I'm using ODSEE 11.1.1.7.0 (which for this case is running on same sandbox)
Sun-Directory-Server/11.1.1.7.0 B2013.0109.2015 (64-bit) 

The connection error:

[06/Jan/2014:08:08:34 -0700] conn=56 op=-1 msgId=-1 - fd=33 slot=33 LDAPS connection from 10.0.0.211:58117 to 10.0.0.211
[06/Jan/2014:08:08:34 -0700] conn=56 op=0 msgId=-1 - closing from 10.0.0.211:58117 - B4 - Server failed to flush BER data back to client -
[06/Jan/2014:08:08:34 -0700] conn=56 op=-1 msgId=-1 - closed.
[06/Jan/2014:08:08:43 -0700] conn=57 op=-1 msgId=-1 - fd=33 slot=33 LDAPS connection from 10.0.0.211:40940 to 10.0.0.211
[06/Jan/2014:08:08:43 -0700] conn=57 op=0 msgId=-1 - closing from 10.0.0.211:40940 - B4 - Server failed to flush BER data back to client -
[06/Jan/2014:08:08:43 -0700] conn=57 op=-1 msgId=-1 - closed.

I've tried with both self-signed certs and our company certs/ca chain and get same error.

I did just attempt a quick test to OpenDJ (OpenDJ 2.7.0-20140102 (build 20140102010058Z, R10055) with just self-signed certs and it appeared to work.

Which DS server did you try to reproduce to?

It will take some time/work to test against other Directory Servers (older ODSEE on Solaris) as for now this is in a self-contained sandbox.

Reproduced the error connecting to Solaris running ODSEE 11.1.1.5.1 and 11.1.1.7.0.

The error doesn't appear going to a Solaris system running Sun One 5.2.

Looking at other possibily related causes, it appears to stem from 319901 where they have enabled ECDHE, but did so only partially or that perl-ldap needs to be recompiled to use that support.  Seems to be some very heated debates...

Reproduced this error on Scientific Linux 6.4.

IO::Socket::SSL: SSL connect attempt failed with unknown errorerror:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group	...propagated
 
Installed Packages
Name        : openssl
Arch        : x86_64
Version     : 1.0.1e
Release     : 16.el6_5
Size        : 4.0 M
Repo        : installed
From repo   : updates
Summary     : A general purpose cryptography library with TLS implementation
URL         : http://www.openssl.org/
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

This issue should be reported through regular support channels (http://www.redhat.com/support) so we can properly investigate and prioritize a fix.

Also I have to say that this looks like a bug on the server side that it does not respect the list of EC curves that the client supports. It could be found out if a SSL handshake was captured in a tcp dump.

The issue is not from openssl end. The issue seems to be on perl side. 

During ssl handshake "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA" cipher was selected. It seems perl shipped with RHEL 6.5 does not have support to handle ECDHE based connection.

When following cpan modules were installed in perl the issue got resolved.

  1) cpan  Net::SSLeay

  2) cpan  IO::Socket::SSL

This is fairly strange as the TLS client side should not require any code changes for ECDHE support. Perhaps just rebuild of these perl packages would help?
Reassigning.

Rebuild is not enough. One has to add the support to the binding and upper layers.

Support for ECDH has been added by upstream in IO-Socket-SSL-1.955 and Net-SSLeay-1.56.

RHEL-6 delivers perl-IO-Socket-SSL-1.31-2.el6 and perl-Net-SSLeay-1.35-9.el6.

For support on the TLS server side you need the bindings however the client side should be fully transparent.

I don't know. Isn't it then the same problem as discussed in bug #1019390 comment #2?

(In reply to Petr Pisar from comment #21)
> bug #1019390 comment #2

This is equivalent to RHEL bug #1022468 an bug #1025598 which should have already been fixed in openssl-1.0.1e-16.el6_5.

It is not equivalent as otherwise with the current openssl packages in RHEL-6 it would work which it apparently doesn't.

It would work. Can you reproduce it? I tried simple IO::Socket:SSL client against openssl s_server and I cannot. I have:

openssl-1.0.1e-16.el6_5.x86_64
perl-IO-Socket-SSL-1.31-2.el6.noarch
perl-Net-SSLeay-1.35-9.el6.x86_64

I get the same results with openssl-1.0.1e-15.el6.x86_64.

Do I need to tweak the TLS server specifically?

You need to have a TLS server which supports EC curves we do not support. For this concrete Perl LDAPS issue we do not have internal reproducer at all. I've asked GSS to provide it.

Created attachment 868558 [details]
Template for the reproducer

One need add such `-named_curve' argument to openssl s_server command that `openssl ecparam -list_curves' will list it on the server host, but will not not the client host.

There is definitely the problem that Perl TLS libraries as delivered by Red Hat Enterprise Linux 6 now do not support ECDHE. We will focus on this issue first.

We need to port the support available from latest version as described in comment #19.

Created attachment 876322 [details]
Upstream ECDHE support ported to 1.35

Note that this is a purely server-side change. The TLS client side should work completely fine without these bindings.

Created attachment 876352 [details]
OBJ_txt2nid export ported to 1.35

This is needed to be able to select curve prime field by name.

Any ETA on when this would pushed?  After creating a ticket with Oracle on the issue they came to the same determination.  The the client is saying it supported a cipher/method that it didn't.

These patches for Perl packages will add support for Perl ECDHE server and for tuning ECDHE parameters of Perl client.

But they alone will not fix the incompatibility with Oracle server. This a matter of OpenSSL library and server implementation by the Oracle.

Oracle did a sniff of the packets and determined that it was a client issue as it was announcing support for something it (the client) didn't actually support.

Are you saying that is not correct?

(In reply to John Wagner from comment #40)
> Oracle did a sniff of the packets and determined that it was a client issue
> as it was announcing support for something it (the client) didn't actually
> support.
> 
> Are you saying that is not correct?

I don't say anything. I've never seen the sniffs. It would be very helpful if somebody showed us them.

Exactly. Also I suspect they tested against old OpenSSL build not the latest from RHEL-6. This should not happen with openssl-16.el6_5 and newer packages.

I still get the issue with openssl-1.0.1e-16.el6_5.4.x86_64...

Here is a clip of what they sent me...

>11 3.130107 167.138.123.144 10.28.165.215 TLSv1 Server Hello, Certificate, >Server Key Exchange, Certificate Request, Server Hello Done 
>Handshake Protocol: Server Hello 
>Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 
>
>But I think the client should not expose this cipher in the first place if it >doesn't support it.

(In reply to John Wagner from comment #43)
> I still get the issue with openssl-1.0.1e-16.el6_5.4.x86_64...
> 
> Here is a clip of what they sent me...
> 
> >11 3.130107 167.138.123.144 10.28.165.215 TLSv1 Server Hello, Certificate, >Server Key Exchange, Certificate Request, Server Hello Done 
> >Handshake Protocol: Server Hello 
> >Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) 
> >

This is a server hello. That means an offer from the server. There is nothing about the client.

I'm sorry, this is not a dump of the network traffic. Use tcpdump tool to capture unsuccessful TLS between the client and the server and provide us the pcap dump.

> >But I think the client should not expose this cipher in the first place if it >doesn't support it.

$ rpm -q openssl
openssl-1.0.1e-16.el6_5.4.x86_64
$ openssl ciphers -V |grep -E 'ECDHE.RSA.AES.?256'
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
          0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
          0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1

As you can see, the 0xc014 cipher-suite is declared by the openssl-1.0.1e-16.el6_5.4 as supported.

If I run the test case here attached, I can see it's possible to use the cipher-suite between openssl server and Perl client:

$ ./server
Using default temp DH parameters
Setting temp ECDH parameters
ACCEPT

$ ./test-iss
DEBUG: .../IO/Socket/SSL.pm:1471: new ctx 33991056
DEBUG: .../IO/Socket/SSL.pm:332: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:334: socket connected
DEBUG: .../IO/Socket/SSL.pm:347: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:390: Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:445: ssl handshake done
  write_all VM at entry=vm_unknown
  written so far 5:5 bytes (VM=vm_unknown)
Cipher: ECDHE-RSA-AES256-SHA
DEBUG: .../IO/Socket/SSL.pm:1507: free ctx 33991056 open=33991056
DEBUG: .../IO/Socket/SSL.pm:1515: OK free ctx 33991056

And the server continues with:

-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMDBALAFAQABDDOAey0DxMV2dx4HAb69QWREZqqDAHd6x/Mg6NOv0gR
0I7cvSoJVEdiYUPX5uwUYsehBgIEU0T2LqIEAgIBLKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
Shared ciphers:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
CIPHER is ECDHE-RSA-AES256-SHA
Secure Renegotiation IS supported
ping
DONE
shutting down SSL
CONNECTION CLOSED
ACCEPT
^C

So Perl TLS client is able to use 0xc014 cipher-suite against openssl-1.0.1e-16.el6_5.4.x86_64 server.

Apparently the server ignores the list of EC curves supported by the client and chooses the ECDH ciphersuite with an EC curve the client does not support. I think it is clearly a third party server bug.

I updated my Oracle ticket with the information... But as I understand it the problem as they are saying the client IS presenting support but when used it fails.

>
>I think paste the following from the client to the thread might help. 
>
>The Client Hello from 10.28.165.215 lists the following on the top of the >cipher suite. 
>Cipher Spec: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0x00c030) 
>Cipher Spec: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0x00c02c) 
>Cipher Spec: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0x00c028) 
>Cipher Spec: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0x00c024) 
>Cipher Spec: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0x00c014) 
>Cipher Spec: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0x00c00a)

They do not say that correctly. The client advertises support for these crypto algorithms (namely ECDHE and ECDSA) because it really supports them but there is additional thing that the client according to the RFCs sends and that is a supported EC curves TLS extension. Citing RFC-4492: "If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite."

Oracle ODSEE11 DOES support that algorithm.  The client just does not work when it tries to use it.

Using the CPAN Net::SSLeay/Net::LDAP/IO::Socket::SSL instead of the ones provided by RedHat in the rpms: perl-Net-SSLeay-1.35-9.el6.x86_64/perl-LDAP-0.40-1.el6.noarch/perl-IO-Socket-SSL-1.31-2.el6.noarch does not present the issue.  And I verified it is using the ECDHE-RSA-AES256-SHA cipher as in a I only enabled that cipher on one of the ODSEE11 instances.

(In reply to John Wagner from comment #48)
> Oracle ODSEE11 DOES support that algorithm.  The client just does not work
> when it tries to use it.
> 
We need the network dump. Or the Oracle ODSEE11 server we can play with.

> Using the CPAN Net::SSLeay/Net::LDAP/IO::Socket::SSL instead of the ones
> provided by RedHat in the rpms:
> perl-Net-SSLeay-1.35-9.el6.x86_64/perl-LDAP-0.40-1.el6.noarch/perl-IO-Socket-
> SSL-1.31-2.el6.noarch does not present the issue.

No news. See comment #17. If you at least specify which versions. There are tens of versions on the CPAN.

> And I verified it is
> using the ECDHE-RSA-AES256-SHA cipher as in a I only enabled that cipher on
> one of the ODSEE11 instances.

So do the current OpenSSL and Perl SSL bindings if the server is RHEL OpenSSL. See comment #44.

I'm sorry, but without more details, I cannot do much.

(In reply to John Wagner from comment #48)
> Oracle ODSEE11 DOES support that algorithm.  The client just does not work
> when it tries to use it.
> 
> Using the CPAN Net::SSLeay/Net::LDAP/IO::Socket::SSL instead of the ones
> provided by RedHat in the rpms:
> perl-Net-SSLeay-1.35-9.el6.x86_64/perl-LDAP-0.40-1.el6.noarch/perl-IO-Socket-
> SSL-1.31-2.el6.noarch does not present the issue.  And I verified it is
> using the ECDHE-RSA-AES256-SHA cipher as in a I only enabled that cipher on
> one of the ODSEE11 instances.

This does not invalidate my comment 47. The oracle server probably supports the ECDHE algorithm but insists on using a curve that our client clearly and in conformance with the RFC does not advertise to support. It is a bug in the Oracle server if it choses to use ECDHE algorithm with a curve unsupported by the client. End of discussion unless you prove that the Oracle server either uses a curve supported by our client or that our client with openssl >= 16.el6_5 advertises support for curve that it really does not support.

(In reply to Petr Pisar from comment #49)
> (In reply to John Wagner from comment #48)
> Oracle ODSEE11 DOES support
> that algorithm.  The client just does not work
> when it tries to use it.
> 
> We need the network dump. Or the Oracle ODSEE11 server we can play with.

An evaluation download of Oracle Directory Server Enterprise Edition (11.1.1.7.0) for is at http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

>
> Using the CPAN Net::SSLeay/Net::LDAP/IO::Socket::SSL instead of the ones
>
> provided by RedHat in the rpms:
>
> perl-Net-SSLeay-1.35-9.el6.x86_64/perl-LDAP-0.40-1.el6.noarch/perl-IO-Socket-
> > SSL-1.31-2.el6.noarch does not present the issue.

No news. See comment
> #17. If you at least specify which versions. There are tens of versions on
> the CPAN.

Just pointing it out that the issue doesn't appear in "newer" versions.  Again I was hoping that the issue that you said was ported in #32 also resolved this issue.

The current version of cpan modules I've tried
Net::SSLeay 1.58
IO::SOCKET::SSL 1.981
NET::LDAP 0.62

> And I verified it is
> using the ECDHE-RSA-AES256-SHA cipher as
> in a I only enabled that cipher on
> one of the ODSEE11 instances.

So do
> the current OpenSSL and Perl SSL bindings if the server is RHEL OpenSSL. See
> comment #44.

But that is the issue.  Both say it is supported.  However when using the provided RH6 rpm's it does not work.  Oracle just updated the ticket I have with them to see if more info can be gathered.

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.

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.

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.

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.

This bug report will be used for enabling perl server to set elliptic curve parameters.

The wrong setting cipher list in perl-LDAP what is the root cause if the initial comment will be solved in bug report #1090966.

How to test:

Use perl-IO-Socket-SSL test described in bug #1078084.

Or just verify following 4 subroutines are defined in Net::SSLeay name space:

  EC_KEY_free()
  EC_KEY_new_by_curve_name()
  OBJ_txt2nid()
  SSL_CTX_set_tmp_ecdh()

I have some yum-specific confusion about this update (perl-Net-SSLeay-1.35-10.el6).

My RHEL 6.7 system says (according to yum) that this package (along with several others that I cannot account for) is available in rhel-6-server-rpms and has been since last Thursday (3/17/2016). Yet, I do not see any errata listed for it at https://rhn.redhat.com/errata/rhel-server-6-errata.html, and have not seen any errata sent to me. 

Additionally, when I go to https://rhn.redhat.com/rhn/channels/software/Search.do and search for perl-Net-SSLeay I was able to find a page pointing to errata RHEA-2015:21919-1, but when I clicked through to that errata I got the message "We're sorry, but the erratum could not be found". 

I did finally find the changelog for this version at https://rhn.redhat.com/network/software/packages/change_log.pxt?pid=1134280 that pointed to this bug, but it (the change log entry) is dated 3/19, while I've seen this package as being available in the repo since 3/17. 

Is there something I'm missing here? Primarily I'm just wanting to make sure the package is genuinely intended for the main 6.7 repos.

(In reply to Dan Ragle from comment #69)
> I have some yum-specific confusion about this update
> (perl-Net-SSLeay-1.35-10.el6).
> 
> My RHEL 6.7 system says (according to yum) that this package (along with
> several others that I cannot account for) is available in rhel-6-server-rpms
> and has been since last Thursday (3/17/2016). Yet, I do not see any errata
> listed for it at https://rhn.redhat.com/errata/rhel-server-6-errata.html,
> and have not seen any errata sent to me. 
> 
I'm sorry for this inconvenience. It was a mistake in publishing metadata about updates and the mistake should be fixed now. The perl-Net-SSLeay-1.35-10.el6 package with erratum text will be published on RHEL 6.8 release.

If you have more questions, please contact Red Hat Support.

Thank you for the quick response. I will take up the rest with Red Hat support.

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://rhn.redhat.com/errata/RHEA-2016-0766.html