Zarafa Collaboration Platform vs. SSLv3/POODLE vulnerability
by Robert Scheck
Good evening,
the press already wrote about it: Bodo Möller, Thai Duong and Krzysztof
Kotowicz from the Google Security Team discovered a design vulnerability
in SSLv3 also known as "POODLE". Technical details are e.g. available at
https://www.openssl.org/~bodo/ssl-poodle.pdf. In this e-mail I will try
to answer some questions that popped up today regarding Zarafa and POODLE.
Important: Even the vulnerability seems to only affect HTTPS, it might (!)
apply to other protocols/services as well (if an attacker has control over
the packets that also contain secret data), thus Zarafa might be affected
in the future as well. As of writing Zarafa itself should be not affected
through, nevertheless I do not take any responsibility for this statement.
Given the most common attack vendor is HTTPS...it makes sense to disable
SSLv3 support in the Apache web server configuration in the first step. A
second step is to also disable SSLv3 for all Zarafa services (to be safe
for the future). Practical details are available at the end of this mail.
Disabling SSLv3 support in the Apache web server is easy - but not really
for Zarafa: The built-in SSLv3 support in Zarafa can not be turned off
using a configuration option. Zarafa supports from SSLv2 up to TLSv1.2 in
its daemons and the whole SSL/TLS support can be either completely enabled
or completely turned off. The only thing that can be separately disabled is
the (weak) SSLv2 support that is fortunately anyway turned off by default.
In case you are using separate TLS accelerators/gateways or reverse proxies
the SSL/TLS support in Zarafa is usually disabled and configuration changes
need to be applied at these TLS accelerators/gateways or reverse proxies.
The feature request to have configurable SSL/TLS protocols and ciphers in
Zarafa is not that new, I raised it via ZCP-11781 on 2013-09-24. And then I
developed exactly such a patch 7 months ago in my free time - and proposed
it to Zarafa; see https://jira.zarafa.com/browse/ZCP-11781 for my initial
patch and a re-merged version. Unfortunately this patch has not yet been
included into any regular Zarafa release (for different reasons) but it is
likely included in the upcoming Zarafa 7.2.
Nevertheless my patch has one caveat: If you disable SSLv3 for the Zarafa
server daemon (in /etc/zarafa/server.cfg) and you are using zarafa-licensed
for the (proprietary) Zarafa Outlook Client you will exclude these users as
my tests turned out that (as of writing) the Zarafa Outlook Client support
SSLv3 only; https://jira.zarafa.com/browse/ZCP-12366 requests some changes.
Fortunately the important Zarafa components are Open Source and thus I now
simply added my patches to the Fedora packages so that really each Zarafa
administrator can decide her-/himself if (s)he wants to disable SSLv3 also
in Zarafa or not (and if so for which of the the Zarafa daemons). And thus
my patch allows to follow various security recommendations out there that
suggest to disable SSLv3 as soon as possible simply for all services.
On top of that I added my patch proposal from 2014-04-16 for ECDHE support
(Elliptic curve Diffie-Hellman); https://jira.zarafa.com/browse/ZCP-12237
contains the patch proposal itself (not yet part of any Zarafa release).
My patched Zarafa packages are available since last night, details are at
https://lists.fedoraproject.org/pipermail/zarafa-announce/2014-October/00...
available. If you can not wait to disable SSLv3, get the packages manually
from the Fedora buildsystem (linked under "builds" section):
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc21
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc20
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.fc19
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el7
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el6
- https://admin.fedoraproject.org/updates/zarafa-7.1.11-1.el5,php53-mapi-7....
Once you updated Zarafa you have to configure the settings you would like
to have. Here is a fast walk through with the settings I would use on
systems that need to be accessed by multiple users (= different clients),
but please do not blame me if these settings are too strong/weak for your
specific usecase:
In /etc/zarafa/server.cfg change the following settings e.g. to this:
server_ssl_protocols = !SSLv2 !SSLv3
server_ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
server_ssl_prefer_server_ciphers = yes
In /etc/zarafa/gateway.cfg change the following settings e.g. to this:
ssl_protocols = !SSLv2 !SSLv3
ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes
In /etc/zarafa/ical.cfg change the following settings e.g. to this:
ssl_protocols = !SSLv2 !SSLv3
ssl_ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes
In /etc/httpd/conf.d/ssl.conf change the following settings e.g. to
this:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
Restart all affected services afterwards and don't forget to test if
all clients can still connect. If a client fails you maybe run that
client on an old operating system or the client requires ciphers that
are questionable or weak (or you maybe just broke your configuration).
https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
provides a good set of example ciphers. Above examples are done using
"Intermediate compatibility". If you want more security switch ciphers
to "Modern compatibility" (or to something even more stronger).
How to test if your services support SSLv3 or whether it is disabled?
Red Hat provides at https://access.redhat.com/articles/1232123 a small
generic detector. Alternatively the following commands are helpful for
e-mail related services:
- openssl s_client -ssl3 -connect <server>:25 -starttls smtp
- openssl s_client -ssl3 -connect <server>:110 -starttls pop3
- openssl s_client -ssl3 -connect <server>:143 -starttls imap
- openssl s_client -ssl3 -connect <server>:237
- openssl s_client -ssl3 -connect <server>:443
- openssl s_client -ssl3 -connect <server>:465
- openssl s_client -ssl3 -connect <server>:587 -starttls smtp
- openssl s_client -ssl3 -connect <server>:993
- openssl s_client -ssl3 -connect <server>:995
- openssl s_client -ssl3 -connect <server>:8443
In case of any issues, questions or trouble do not hesitate to send a
message to the zarafa mailing list.
Greetings,
Robert
9 years, 5 months
Zarafa 7.1.11 has been submitted to updates-testing
by Robert Scheck
Good morning,
Zarafa 7.1.11 has been submitted to updates-testing (Fedora EPEL 5, 6
and 7, Fedora 19, 20, 21 and Rawhide). Here is the full list of changes
in Zarafa 7.1.11 [46050]:
Zarafa Collaboration Platform 7.1.11 final R1 [46050]
=====================================================
General
-------
This R1 release of the 7.1.11 final release addresses the WebAccess install
problem on RPM-based systems and resolves the dependencies problems under
Ubuntu 14.04.
Backend
-------
- ZCP-12472: zarafa-search crashes on ubuntu 14.0.4 LTS
- ZCP-12405: zarafa-search do not start on Ubuntu 14.04
- ZCP-12581: config files are being saved as config.cfg.dpkg-new on ubuntu
14.04
- ZCP-12570: install.sh for Ubuntu 14.04
- ZCP-12582: installing webaccess on rhel based systems result in scriptlet
failed, exit status 1
Zarafa Collaboration Platform 7.1.11 final [45875]
==================================================
General
-------
This release brings a few new features while maintaining stability. With
this release we address a few segfaults in zarafa-search to match this
final release.
Backend
-------
- ZCP-11809: zarafa-gateway is unable to create RTF text stream
- ZCP-11862: zarafa-backup zarafa-restore breaks textfiles
- ZCP-11934: Enhance MariaDB support by modifying sql_mode
- ZCP-12012: zarafa-server segfaults when running zarafa-stats --system
- ZCP-12097: Disposition-Notification-To double colons in middle of line.
dagent crashes
- ZCP-12110: Segfault zarafa-server 7.1.8 R1
- ZCP-12127: Support for Apache 2.4
- ZCP-12134: Randomly lost e-mail attachments in e-mails
- ZCP-12266: [BIG5] Customer requires an option to set the default
character encoding of incoming mail when no encoding is set.
- ZCP-12269: public folder shows MAPI_E_STORE_FULL when creating new
element
- ZCP-12272: WebAccess: .htaccess is not marked as a configuration file in
rpm
- ZCP-12436: jpegPhoto included twice in ldap.propmap.cfg
- ZCP-12500: Zarafa stores rfc enforced linebreaks as actual line breaks
- ZCP-12511: zarafa-gateway is unable to create RTF text stream
- ZCP-12537: ical issue when password contains a colon
- ZCP-12547: As a hoster I need a way to reduce the performance impact on
LDAP caused by zarafa-licensed.
- ZCP-12563: Create configuration setting to indicate if folder owners
automatically get full access rights or not
- ZCP-12548: zarafa-search segfault
You should be able to update to Zarafa 7.1.11 by using something like:
yum update --enablerepo=updates-testing 'zarafa*'
on all Fedora releases and for Fedora EPEL you should use the following:
yum update --enablerepo=epel-testing 'zarafa*'
After testing, please add positive or negative karma to the Zarafa packages
in Bodhi:
https://admin.fedoraproject.org/updates/zarafa
And if you should find bugs or issues, please fill a bug report in Red Hat
Bugzilla as described here:
https://fedoraproject.org/wiki/Zarafa#Bugs
Your feedback is very much appreciated.
Greetings,
Robert
9 years, 5 months