Bug #2255
closedsome troubles with SSL: no shared ciphers (export ciphers needing 512-bit DH parameters)
Description
I try to use SSL in lighttpd-1.4.28 on ArchLinux with openssl-1.0.0a. The sequence of my actions follows.
I create the DSA key and certificate (it is not self-signed), and put them both into single file. I add following to the /etc/lighttpd/lighttpd.conf
:
$SERVER["socket"] == ":443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/tls/certpair.pem" ssl.cipher-list = "SSLv3+HIGH" }
I check the certificate:
# openssl verify < /etc/lighttpd/tls/certpair.pem stdin: OK
and restart lighttpd. Everything should be fine, but when i try to connect to the server with openssl s_client i get:
$ openssl s_client -connect localhost:443 CONNECTED(00000003) 140340795717288:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:658: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 211 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
Ok. 'Something is wrong' - i think. And try to clear things with ssldump, but that:
# ssldump -i lo port 443 New TCP connection #1: 0x01.imm.uran.ru(53425) <-> 195.19.144.11(443) 1 1 0.0008 (0.0008) C>S Handshake ClientHello Version 3.1 cipher suites Unknown value 0xc014 Unknown value 0xc00a Unknown value 0x39 Unknown value 0x38 Unknown value 0x88 Unknown value 0x87 Unknown value 0xc019 Unknown value 0x3a Unknown value 0x89 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x35 Unknown value 0x84 Unknown value 0xc012 Unknown value 0xc008 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc017 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xc013 Unknown value 0xc009 Unknown value 0x33 Unknown value 0x32 Unknown value 0x45 Unknown value 0x44 Unknown value 0xc018 Unknown value 0x34 Unknown value 0x46 Unknown value 0xc00e Unknown value 0xc004 Unknown value 0x2f Unknown value 0x41 Unknown value 0xff compression methods unknown value NULL 1 2 0.0019 (0.0011) S>C Alert level fatal value handshake_failure 1 0.0024 (0.0005) C>S TCP FIN 1 0.0026 (0.0002) S>C TCP FIN
does not help. lighttpd just disconnects, logging the message:
2010-08-26 17:06:30: (connections.c.294) SSL: 1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
That's it, i do not know what to do next. The same result i get in both cases (1) without ssl.cipher-list
option and (2) with s_client -cipher 'the-same-cipher-list-as-above'
:
$ openssl s_client -connect localhost:443 -cipher 'SSLv3+HIGH' CONNECTED(00000003) 3075466888:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:658: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 161 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
The s_client/s_server with that certpair.pem
is operational. The openssl library seems working correctly, on the box, where i try to run lighty Postfix, Dovecot and ejabberd are successfully exchanges data over ssl connections with many hosts on the net.
So. It should be some bug in the light :). I've checked also lighttpd-1.5.0 (ssl) and lighttpd/1.4.29-devel-2769M (ssl), and encountered the same bug.
I would like to help to fix the things, because i need ssl working badly, if you are interested in the subject, and may somehow help to speed up the process, please, contact me on #lighttpd FreeNode irc-channel (my nick is limeride).
Files
Updated by nitrox over 14 years ago
- Status changed from New to Need Feedback
Duplicate from forums post at http://redmine.lighttpd.net/boards/2/topics/3515 - tho missing all the comments and suggestions from there. Seriously, we don´t like that!
As there are no new hints on where lighty might be buggy its just an assumption atm. Please add the missing logs and backtraces.
Never seen you at the irc-chan, atleast not with that nick.
Updated by c0da over 14 years ago
nitrox wrote:
Duplicate from forums post at http://redmine.lighttpd.net/boards/2/topics/3515 - tho missing all the comments and suggestions from there. Seriously, we don´t like that!
But there are nothing helpfull in comments. I've added info about s_client/s_server, so everything from forum is mentioned above.
As there are no new hints on where lighty might be buggy its just an assumption atm. Please add the missing logs and backtraces.
But the log does not contain any other messages (except one saying, that server is starting). Backtrace is what i am trying to make now.
Updated by c0da over 14 years ago
- File strace.lighttpd.txt strace.lighttpd.txt added
Updated by c0da over 14 years ago
Updated by c0da over 14 years ago
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html# - it seems that is related somehow to the issue.
Updated by c0da over 14 years ago
- File dh.correct.patch dh.correct.patch added
c0da wrote:
Indeed. The trouble was with DH parametrs. Here i attach silly (but working) patch, with compiled in SKIP DH parametrs from openssl distribution.
UPS. The correct patch is here
Updated by stbuehler almost 14 years ago
- Target version set to 1.4.29
You could try to load the dh parameters with ssl.dh-file - i guess you should use the same as you did to generate your key.
I'm not quite sure what the right approach is here - should we prepare parameters for 512, 1024, 2048? what is the right way to do that, shouldn't we "parse" them in setup phase? are 512 bit parameters still acceptable?
Updated by stbuehler almost 14 years ago
- Target version changed from 1.4.29 to 1.4.x
Updated by stbuehler over 11 years ago
- Subject changed from some troubles with SSL: no shared ciphers to some troubles with SSL: no shared ciphers (export ciphers needing 512-bit DH parameters)
- Status changed from Need Feedback to Invalid
- Target version deleted (
1.4.x)
http://security.stackexchange.com/a/42260/11107 explains it a little bit:
Usually the server can pick any DH parameters it wants (and clients should abort the connection if they are too small. Anything less than 768 bits is way to small, you should probably start with 1024).
In the special case of "Export" ciphers you have to use 512-bit DH parameters. But using export ciphers is basically like not using SSL at all, and there is no reason to support those in any way.
So we don't need SSL_CTX_set_tmp_dh_callback
; if you want larger DH parameters just generate them and configure them, no need to dynamically pick them.
Also available in: Atom