Project

General

Profile

Actions

Bug #2255

closed

some troubles with SSL: no shared ciphers (export ciphers needing 512-bit DH parameters)

Added by c0da over 13 years ago. Updated over 10 years ago.

Status:
Invalid
Priority:
Normal
Category:
-
Target version:
-
ASK QUESTIONS IN Forums:

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

strace.lighttpd.txt (2.63 KB) strace.lighttpd.txt strace -fF -s 1024 of lighttpd process during s_client connection c0da, 2010-09-12 13:37
strace.lighttpd-starting.txt (43.7 KB) strace.lighttpd-starting.txt strace -fF -s 1024 lighttpd -Df ... from start till s_client connection failure c0da, 2010-09-12 14:36
dh.patch (1.61 KB) dh.patch silly patch, which sets DH parameters c0da, 2010-09-17 16:58
dh.correct.patch (4.26 KB) dh.correct.patch c0da, 2010-09-17 17:11
Actions #1

Updated by nitrox over 13 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.

Actions #2

Updated by c0da over 13 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.

Actions #5

Updated by c0da over 13 years ago

http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html# - it seems that is related somehow to the issue.

Actions #6

Updated by c0da over 13 years ago

Indeed. The trouble was with DH parametrs. Here i attach silly (but working) patch, with compiled in SKIP DH parametrs from openssl distribution.

Actions #7

Updated by c0da over 13 years ago

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

Actions #8

Updated by stbuehler about 13 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?

Actions #9

Updated by stbuehler almost 13 years ago

  • Target version changed from 1.4.29 to 1.4.x
Actions #10

Updated by stbuehler over 10 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.

Actions

Also available in: Atom