Bug #2255
some troubles with SSL: no shared ciphers
| Status: | Need Feedback | Start date: | 2010-09-11 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | 1.4.x | |||
| Missing in 1.5.x: | No |
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).
History
#1 Updated by nitrox almost 3 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.
#2 Updated by c0da almost 3 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.
#3 Updated by c0da almost 3 years ago
- File strace.lighttpd.txt
added
#4 Updated by c0da almost 3 years ago
- File strace.lighttpd-starting.txt
added
#5 Updated by c0da almost 3 years ago
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html# - it seems that is related somehow to the issue.
#6 Updated by c0da almost 3 years ago
- File dh.patch
added
Indeed. The trouble was with DH parametrs. Here i attach silly (but working) patch, with compiled in SKIP DH parametrs from openssl distribution.
#7 Updated by c0da almost 3 years ago
- File 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
#8 Updated by stbuehler about 2 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?
#9 Updated by stbuehler about 2 years ago
- Target version changed from 1.4.29 to 1.4.x
Also available in: Atom