Hello ngIRCd'ers! »We proudly present … ngIRCd 21!« After two release candidates, here it is, the shiny new release: most prominent new features are our included help system documenting all supported IRC commands (try „/QUOTE HELP <command>“ in your IRC client), far better support for „server target masks“ for a lot of commands (for example try something like „/ADMIN nickname“ or „/LUSERS *.de“), the new configuration variable „IncludeDir“ that allows to split the server configuration across multiple files, and support for SSL certificate fingerprints. But there is even more! Please see the full NEWS and ChangeLog files for all changes, you can read them here: • <http://ngircd.barton.de/doc/NEWS> • <http://ngircd.barton.de/doc/ChangeLog> And even more information can be found here: • Homepage: <http://ngircd.barton.de/> (<http://ngircd.berlios.de/>) • Bug tracker: <http://ngircd.barton.de/bugzilla/> • Downloads: - FTP: <ftp://ftp.berlios.de/pub/ngircd/> - HTTP: <http://ngircd.barton.de/pub/ngircd/> Thanks to all users, bug reporters, contributors, packagers, and supporters! Regards Alex
Alexander Barton wrote...
»We proudly present … ngIRCd 21!«
... and there's a problem in s2s connections using GnuTLS. Handshake fails with Target: | SSL error: Could not negotiate a supported cipher suite. [gnutls_handshake]. and subsequently initiator: | SSL error: A TLS packet with unexpected length was received. [gnutls_handshake]. As far as I understand the code and captured traffic, setting the cipher list using gnutls_priority_set in ConnSSL_Init_SSL has no effect. The ciphers offered in the TLS "Client Hello" packet are weak and appearently it's to late for cipher negotiation. Workarounds: * Disable "SSLConnect". Know the drawbacks. * Lower the cipher strength by e.g. "CipherList = EXPORT". Probably even worse. * Re-compile using OpenSSL. Christoph
Christoph Biedl wrote...
As far as I understand the code and captured traffic, setting the cipher list using gnutls_priority_set in ConnSSL_Init_SSL has no effect. The ciphers offered in the TLS "Client Hello" packet are weak and appearently it's to late for cipher negotiation.
Since even connection manually using "gnutls-cli --priority SECURE128" fails I assume "SECURE128" might be a good choice for a server but a terrible idea for a client. So I'd suggest to revert the last hunk of b9006ace that applied the CipherList settings to outgoing connections, too. Instead, leave it to NORMAL and let the remote side pick the ciphers it considers usable. Christoph
Christoph Biedl wrote...
Since even connection manually using "gnutls-cli --priority SECURE128" fails I assume "SECURE128" might be a good choice for a server but a terrible idea for a client.
Not that easy, after some experiments in IRC we found this is related to the gnutls version. Debian wheezy uses 2.12.x, that causes trouble. My initial reports were indeed from a machine running wheezy. However, 3.2.4 from Debian jessie just does fine. Reproducer (certs provided by the ssl-cert package): Server: gnutls-serv --priority SECURE128 \ --x509certfile /etc/ssl/certs/ssl-cert-snakeoil.pem \ --x509keyfile /etc/ssl/private/ssl-cert-snakeoil.key \ --port 9999 Client: gnutls-cli --port 9999 localhost --priority SECURE128 Connecting to a server running wheezy: Connecting to '127.0.0.1:9999'... *** Fatal error: A TLS fatal alert has been received. *** Received alert [40]: Handshake failed *** Handshake has failed GnuTLS error: A TLS fatal alert has been received. Connecting to a server running jessie: Connecting to '127.0.0.1:9999'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: (...) As also reported in <http://bugs.debian.org/708174>, SECURE256 works too. Christoph
Teilnehmer (2)
-
Alexander Barton -
Christoph Biedl