Zarafa Collaboration Platform vs. SSLv3/POODLE vulnerability

October 15, 2014 by Robert Scheck   Comments (0)

, , , , , ,

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". I would like to 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 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). For Apache it looks like 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

Please do not forget to restart your web server service and try if everything still works for you. Above cipher suite is taken from the current Mozilla recommendation and should be suitable for most environments. If you are more security sensitive use the "modern compatibility" rather the "intermediate compatibility" (that is used above).

How to test if your services support SSLv3 or whether it is disabled? Red Hat provides a small generic POODLE 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

Disabling SSLv3 support in the web server was easy, wasn't it? But unfortunately it isn't same easy 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.

Fortunately the upcoming Zarafa 7.2 will likely include my patch proposal to make SSL/TLS protocols, cipher suites and preferences configurable. But if you are a user of my RPM packages in Fedora or EPEL you can have that feature already today because I applied my patch to the Zarafa 7.1.11 packages there... ;-)