4:10 p.m.
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