On Thu, Jun 18, 2015 at 11:08:31PM -0700, Christian Kujau wrote:
Package: libssl1.0.0
Version: 1.0.1k-3+deb8u1
Severity: normal
Dear Maintainer,
the last update for openssl/libssl has the following in its changelog:
openssl (1.0.1k-3+deb8u1) jessie-security; urgency=medium
* CVE-2015-4000: Have minimum of 768 bit for DH
Which is probably The Right Thing to do, but it breaks a stunnel4 client
connection to a STARTTLS SMTP server (that I have no control over):
=
LOG5[28161]: Service [mailhost] accepted connection from ::1:58363
LOG6[28161]: s_connect: connecting mailhost:25
LOG5[28161]: s_connect: connected mailhost:25
LOG5[28161]: Service [mailhost] connected remote server from 127.0.0.1:54733
LOG6[28161]: SNI: sending servername: localhost
LOG3[28161]: SSL_connect: 14082174: error:14082174:SSL
routines:ssl3_check_cert_and_algorithm:dh key too small
LOG5[28161]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
=
The stunnel configuration can be found below. I was about to report this as a
bug against the stunnel4 package, but since the last libssl update broke it,
I decided to report it against libssl - feel free to re-assign.
Is the other side also stunnel, or is it directly using the SMTP
server?
In any case there is nothing I can (or want to) do in OpenSSL.
The other side needs to be fixed to use a stronger group. If the
other side is using software in some default configuration it
would be helpful to know that so we can get that fixed.
Some more notes on the stunnel4 package, from its manpage:
DH PARAMETERS
Stunnel 4.40 and later contains hardcoded 2048-bit DH parameters.
It is also possible to specify DH parameters in the certificate file:
openssl dhparam 2048 stunnel.pem
But this is only possible when running stunnel4 in *server* mode - in client
mode
(and without client certificates involved), I don't have any stunnel.pem
configured and thus cannot add any DH parameters. Or maybe it's possible, but
I
could not find it documented.
It's the server that decides the which group to use, so it's
configured at that side.
4.40 should already be in oldstable.
Workaround:
1) Don't upgrade to 1.0.1k-3+deb8u1 :-)
2) Extract an older version of libssl, then use
LD_LIBRARY_PATH=/path/to/older/version stunnel4 stunnel.conf
3) Use a non-DH cipher, if the server supports any. In my case, the
following ciphers were supported by the server:
AES128-SHA ***
AES256-SHA ***
DES-CBC3-SHA
DES-CBC-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
EDH-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC-SHA
EXP-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-RC4-MD5
EXP-RC4-MD5
RC4-MD5
RC4-MD5
RC4-SHA
I went with AES128-SHA resp. AES256-SHA, I wanted to avoid RC4, DH
(unusable),
EXP (export) and DES. So, for stunnel, I added the following service-level
option to the configuration file:
ciphers = AES256-SHA
Those ciphers look like they're from an OpenSSL 0.9.8 version, so
if the other side is running Debian it would be squeeze based,
using AES128-SHA or AES256-SHA would be your best choice if you
can't get the other side to use a stronger DH group.
So it at least looks like the other side is running some older
software.
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
