[Pkg-openssl-devel] Bug#789245: Bug#789245: libssl1.0.0:amd64: libssl-1.0.1k-3+deb8u1 breaks stunnel4 STARTTLS connections

[Kurt Roeckx]

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