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/00005... 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.1.1...
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
zarafa-announce@lists.fedoraproject.org
-
Robert Scheck