Hi, who may be concerned ...
after the Heartbleed bug, it is now the Poolde bug which impacts SSL
encryption using Cipher Block Chaining (CBC).
UCSPI-SSL and qmail/spamcontrol depend on OpenSSL and are vulnerable by
this bug. However, unlike the Heartbleed, which was a programming but,
Poodle can be avoided by disabling SSLv2/v3 upon setting up the
communication, thus only TLS is used.
This behavior is now enforded in Spamcontrol 2.7.32 for qmail-remote. Also
this version fixes a potential communication problem in case the server
only offers TSLv1(.0).
So please update to the new version. No configuration changes are required.
<http://www.fehcom.de/qmail/spamcontrol.html>
A new version of UCSPI-SSL is not necessary now, though I prepare one.
Best regards.
--eh.
PS: qmail-smtpd and qmail-pop3d MAY be impacted by the Shellshock bug in
addition.
Make sure, that you use '/bin/sh' and not the bash invoking the service in
the run scripts. Unfortunately, on some systems the 'sh' is symlinked to
'bash'.
You can use the following command sequence to test it:
env x='() { :;}; echo vulnerable' bash -c "echo test"
Exchange 'bash' with your shell and test it!
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE
after the Heartbleed bug, it is now the Poolde bug which impacts SSL
encryption using Cipher Block Chaining (CBC).
UCSPI-SSL and qmail/spamcontrol depend on OpenSSL and are vulnerable by
this bug. However, unlike the Heartbleed, which was a programming but,
Poodle can be avoided by disabling SSLv2/v3 upon setting up the
communication, thus only TLS is used.
This behavior is now enforded in Spamcontrol 2.7.32 for qmail-remote. Also
this version fixes a potential communication problem in case the server
only offers TSLv1(.0).
So please update to the new version. No configuration changes are required.
<http://www.fehcom.de/qmail/spamcontrol.html>
A new version of UCSPI-SSL is not necessary now, though I prepare one.
Best regards.
--eh.
PS: qmail-smtpd and qmail-pop3d MAY be impacted by the Shellshock bug in
addition.
Make sure, that you use '/bin/sh' and not the bash invoking the service in
the run scripts. Unfortunately, on some systems the 'sh' is symlinked to
'bash'.
You can use the following command sequence to test it:
env x='() { :;}; echo vulnerable' bash -c "echo test"
Exchange 'bash' with your shell and test it!
--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ | PGP-Key-Id: 7E4034BE