Bug 38685 - [Security] Restrict TLSCipherSuite in OpenLDAP
[Security] Restrict TLSCipherSuite in OpenLDAP
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Security updates
UCS 4.0
Other Linux
: P1 normal (vote)
: UCS 4.0-2-errata
Assigned To: Philipp Hahn
Arvid Requate
:
Depends on: 37459 39158
Blocks: 47974
  Show dependency treegraph
 
Reported: 2015-06-11 13:05 CEST by Arvid Requate
Modified: 2018-10-15 13:26 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Security
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2015-06-11 13:05:18 CEST
OpenLDAP configuration in UCS currently offers several cipher suites, that are deprecated by now (think VENOM). We should make the TLSCipherSuite option configurable in the slapd.conf UCS template and provide a sensible default.

Maybe we should do the same for the option TLSEphemeralDHParamFile and create a custom DH Group (see https://weakdh.org/sysadmin.html).


FYI: Test results:

* testssl.sh criticises these points:
==================================================================
 SSLv3      offered (NOT ok)

 40 Bit encryption        offered (NOT ok)
 56 Bit encryption        Local problem: No 56 Bit encryption configured in /usr/bin/openssl
 Export Cipher (general)  offered (NOT ok)
 Low (<=64 Bit)           offered (NOT ok)
 DES Cipher               offered (NOT ok)

 Has server cipher order?     nope (NOT ok)

 Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), DoS threat
 CRIME, TLS (CVE-2012-4929)                VULNERABLE (NOT ok), but not using HTTP: probably no exploit known
 POODLE, SSL (CVE-2014-3566)               VULNERABLE (NOT ok), uses SSLv3+CBC (no TLS_FALLBACK_SCSV mitigation tested)
 FREAK  (CVE-2015-0204), experimental      VULNERABLE (NOT ok), uses EXPORT RSA ciphers
 BEAST (CVE-2011-3389)                     SSL3: DES-CBC3-SHA DES-CBC-SHA
                                                 EXP-DES-CBC-SHA EXP-RC2-CBC-MD5
                                           TLS1: DES-CBC3-SHA DES-CBC-SHA
                                                 EXP-DES-CBC-SHA EXP-RC2-CBC-MD5
                                           -- but also supports higher protocols (possible mitigation): TLSv1.1 TLSv1.2
 RC4 (CVE-2013-2566, CVE-2015-2808)        VULNERABLE (NOT ok): RC4-SHA RC4-MD5 EXP-RC4-MD5

Not OK: No ciphers supporting Forward Secrecy offered
==================================================================

sslyze.py --regular criticises these points:
==================================================================
      Client-initiated Renegotiations:   VULNERABLE - Server honors client-initiated renegotiations
==================================================================

POODLE might not be that relevant to LDAP, see https://lists.samba.org/archive/samba/2014-November/186849.html
Comment 1 Philipp Hahn univentionstaff 2015-07-06 15:48:27 CEST
FYI: <http://testssl.sh/testssl.sh> localhost:636

>  Has server cipher order?     nope (NOT ok) 
Happens on my UCS-4.0-0 test VM only.

>  Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), DoS threat
not configurable with OpenLDAP.

>  CRIME, TLS (CVE-2012-4929)                VULNERABLE (NOT ok), but not using HTTP: probably no exploit known 
AFAIK not exploitable with LDAP.


r61808 | Bug #38685 LDAP: Make SSL/TLS ciphers configurable
 Require TLSv1.0 or better (backward compatible to UCS-2.4)
 Disable weak chiphers like LOW, MEDIUM, RC4 and NULL by default.
 Enable PFS by default.

Package: univention-ldap
Version: 11.0.12-8.750.201507061538
Branch: ucs_4.0-0
Scope: errata4.0-2

r61809 | Bug #38685 LDAP: Make SSL/TLS ciphers configurable YAML
 2015-07-06-univention-ldap.yaml


FYI: I testes a UCS-2.4 system against an updated UCS-4.0-2 still works with TLSv1.0, but not with TLSv1.2:
 SERVER=xen12.knut.univention.de SECRET=xxxx BASE=dc=phahn,dc=dev
 LDAPTLS_REQCERT=allow LDAPTLS_CACERT=<(wget -qO- http://$SERVER/ucs-root-ca.crt) ldapsearch -ZZ -xLLL -H ldap://$SERVER:7389 -D cn=admin,$BASE -w $SECRET -b dc=phahn,$BASE
Comment 2 Arvid Requate univentionstaff 2015-07-16 18:59:43 CEST
I gues we better use "openssl dhparam" instead of "openssl gendh", see Warning in https://www.openssl.org/docs/apps/dhparam.html.

What is the logic of create-dh-parameter-files and the cron job?

* If ldap/tls/dh/paramfile is set it always generates a new DH group.

* The cron job runs the script every night at 4:30, generating a new DH parameter group every night?

* If the UCR variable is unset, it doesn't. But still the slapd.conf template uses /etc/ldap/dh_2048.pem as the default path (this part may be ok).

Can please you elaborate on the intended behaviour?
Comment 3 Philipp Hahn univentionstaff 2015-07-17 08:47:49 CEST
(In reply to Arvid Requate from comment #2)
> I gues we better use "openssl dhparam" instead of "openssl gendh", see
> Warning in <https://www.openssl.org/docs/apps/dhparam.html>.

I chose "gendh", because most of our code uses it:

mail/univention-mail-postfix/share/create-dh-parameter-files.sh:34 …gendh…
mail/univention-mail-postfix/share/create-dh-parameter-files.sh:35 …gendh…
mail/univention-mail-postfix/share/create-dh-parameter-files.sh:36 …gendh…
management/univention-ldap/scripts/create-dh-parameter-files:41 …gendh…
services/univention-radius/80univention-radius.inst:48 …gendh…
services/univention-radius/setupCA.sh:45 …dhparam…

Changed to "dhparam", as this is the recommended new way.

> What is the logic of create-dh-parameter-files and the cron job?
> 
> * If ldap/tls/dh/paramfile is set it always generates a new DH group.

No, it just specifies the file name. If unset, no DH is used for OpenLDAP.

> * The cron job runs the script every night at 4:30, generating a new DH
> parameter group every night?

Yes, this is what univention-mail-postfix does too.
My understanding is, that the DH parameters must be updated on a regular basis to guarantee PFS.
See <https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/>

> * If the UCR variable is unset, it doesn't. But still the slapd.conf
> template uses /etc/ldap/dh_2048.pem as the default path (this part may be
> ok).

I removed the default, so it can be disabled.

> Can please you elaborate on the intended behavior?

- Enable PFS by default
  - Can be disabled by setting ldap/tls/dh/paramfile=
- Refresh DH parameters nicghtly
  - Can be disabled or changed by setting "ldap/tls/dh/cron"
- Re-starts the OpenLDAP server slapd for each newly generated DH param file
  - Must be enabled explicitly by "ldap/tls/dh/restart", as this interrupts the LDAP service every time.


r62182 | Bug #38685 LDAP: Fix DH parameter handling
 Allow un-setting UCRV ldap/tls/dh/paramfile to disable PFS.
 Use "openssl dhparam" instead of "gendh".

Package: univention-ldap
Version: 11.0.12-10.756.201507170830
Branch: ucs_4.0-0
Scope: errata4.0-2

r62183 | Bug #38685 LDAP: Fix DH parameter handling YAML
 2015-07-06-univention-ldap.yaml

OK: aptitude install -y '?source-package(^univention-ldap$)?version(11.0.12-10.756.201507170830)?installed'
OK: openssl s_client -connect localhost:7636 </dev/null 2>&1 | grep "Cipher is"
 Before without PFS:
  New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
 After enabling DHE:
  New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
OK: /usr/share/univention-ldap/create-dh-parameter-files
Comment 4 Arvid Requate univentionstaff 2015-07-20 11:44:16 CEST
> Yes, this is what univention-mail-postfix does too.
> My understanding is, that the DH parameters must be updated on a regular basis to guarantee PFS.
> See <https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/>

No. PFS is based on ephemeral keys. The parameters can be, and usually are fixed. Logjam just suggests that the short default DH paramter "group" might be susceptible to pre-computation attacks, see https://blog.cloudflare.com/logjam-the-latest-tls-vulnerability-explained/

The document quoted by you just says "Since it is costly to generate those parameters – which are needed to negotiate a DH key exchange – OpenSSL suggests to create them when an application is installed." - which is what we do. We even do more: we generate a DH group for every server!


> - Refresh DH parameters nicghtly
>  - Can be disabled or changed by setting "ldap/tls/dh/cron"

So please change the default. Generation of a non-default DH parameter "group" is a recommended step against pre-computation attacks, that's good. But periodically changing the DH parameter "group" is a special precaution that isn't currently recommended as default, so we shouldn't do it either. See:


* http://www.postfix.org/FORWARD_SECRECY_README.html says:

"Optionally generate non-default Postfix SMTP server EDH parameters for improved security against pre-computation attacks [...]"

"You can improve security against pre-computation attacks further by regenerating the Postfix SMTP server EDH parameters periodically (an hourly or daily cron job running the above commands as root can automate this task)"


* https://tools.ietf.org/html/rfc3526 even recommends using a couple of standard parameters (DH "groups").
Comment 5 Arvid Requate univentionstaff 2015-07-20 11:46:23 CEST
See also your own comment at Bug 37459 Comment 12.
Comment 6 Philipp Hahn univentionstaff 2015-07-20 12:21:31 CEST
r62244 | Bug #38685 LDAP: Disable DH parameter creation by default

Package: univention-ldap
Version: 11.0.12-11.757.201507201215
Branch: ucs_4.0-0
Scope: errata4.0-2

r62245 | Bug #38685 LDAP: Disable DH parameter creation by default YAML
 2015-07-06-univention-ldap.yaml
Comment 7 Arvid Requate univentionstaff 2015-07-20 14:32:50 CEST
Verified:

* The cipher list is restricted as in univention-apache
* TLS 1.0 is configured as minimum
* testssh.sh is much more happy about this
* The default /usr/share/univention-ldap/dh_2048.pem is identical to
  https://bettercrypto.org/static/dhparams/group14.pem . Apart from the leading
  zero they are identical to the 2048 MODP group specified in RFC 3526.
* UCR ldap/tls/dh/cron in unset by default, so the cron job
  /etc/cron.d/univention-ldap is disabled by default.
* UCR ldap/tls/dh/paramfile is set to /etc/ldap/dh_2048.pem by default
* /etc/ldap/dh_2048.pem is a copy of that DH group 14 by default
* Running /usr/share/univention-ldap/create-dh-parameter-files creates
  a new individual 2048 bit DH parameter group
* Advisory: Ok

I adjusted the version field to only apply to ucs-4.0-2 (6 weeks grace period since ucs 4.0-2 release (12.5.2015) is over, see http://wiki.univention.de/index.php?title=Maintenance_Cycle_for_UCS ).
Comment 8 Arvid Requate univentionstaff 2015-07-20 17:49:54 CEST
In case somebody needs to check the parameter files in detail, this helps:

openssl asn1parse < /usr/share/univention-ldap/dh_2048.pem
Comment 9 Janek Walkenhorst univentionstaff 2015-08-06 17:53:11 CEST
<http://errata.univention.de/ucs/4.0/270.html>