[stunnel-users] DH not working, although initialized correctly

Mon Apr 14 12:51:36 CEST 2014

Hello, 

I'm trying to enable Forward Secrecy. have an stunnel 4.56 instance compiled with authpriv and xforwardedfor patches, configured as follows: 

sslVersion = all 
options = NO_SSLv2 
ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 
renegotiation = no 
setuid = nobody 
setgid = nobody 
socket = l:TCP_NODELAY=1 
socket = r:TCP_NODELAY=1 
libwrap = no 
TIMEOUTbusy = 120 
xforwardedfor = yes 

[domain.com] 
accept  = X.X.X.X:443 
connect = 127.0.0.1:91 
cert = /etc/pki/tls/certs/domain.pem 
key = /etc/pki/tls/private/domain.key 

domain.pem contains both the SSL certificate and the DH parameters (generated with "openssl dhparams 2048"). 

stunnel initializes the DH parameters correctly: 

2014.04.14 12:08:18 LOG6[16629:140355580176320]: Initializing service [domain.com] 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: Certificate: /etc/pki/tls/certs/domain.pem 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: Certificate loaded 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: Key file: /etc/pki/tls/private/domain.key 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: Private key loaded 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: Using DH parameters from /etc/pki/tls/certs/domain.pem 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: DH initialized with 2048-bit key 
2014.04.14 12:08:18 LOG7[16629:140355580176320]: SSL options set: 0x01000004 

When I try to connect using openssl s_client, the connections fails with it unable to negotiate a cipher. 
On the client side: 

# openssl s_client -cipher ECDH -tls1 -connect www.domain.com:443 
CONNECTED(00000003) 
140735113126752:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 
140735113126752:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: 
--- 
no peer certificate available 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 7 bytes and written 0 bytes 
--- 
New, (NONE), Cipher is (NONE) 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
    Protocol  : TLSv1 
    Cipher    : 0000 
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None 
    PSK identity: None 
    PSK identity hint: None 
    SRP username: None 
    Start Time: 1397471905 
    Timeout   : 7200 (sec) 
    Verify return code: 0 (ok) 
--- 

On the server side: 

2014.04.14 11:57:10 LOG5[9647:140038728394496]: Service [domain.com] accepted connection from X.X.X.X:56678 
2014.04.14 11:57:10 LOG7[9647:140038728394496]: SSL state (accept): before/accept initialization 
2014.04.14 11:57:10 LOG7[9647:140038728394496]: SNI: no virtual services defined 
2014.04.14 11:57:10 LOG7[9647:140038728394496]: SSL alert (write): fatal: handshake failure 
2014.04.14 11:57:10 LOG3[9647:140038728394496]: SSL_accept: 1408A0C1: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher 
2014.04.14 11:57:10 LOG5[9647:140038728394496]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket 

The client and the server have the same openssl version (1.0.1e), with the same supported ciphers. 

I tried different cipher combinations (i.e. "HIGH:!aNULL:!MD5"), but no lock. FWIW, the initial DH cipher list in the stunnel config file works correctly in an SSL nginx instance and openssl s_client negotiates "ECDHE-RSA-AES256-SHA". 

Any idea what may be wrong with stunnel? 

Thanks, 
Ovidiu 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20140414/220ce5a1/attachment.html>