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
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
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?
(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
> 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").
See also your own comment at Bug 37459 Comment 12.
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
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 ).
In case somebody needs to check the parameter files in detail, this helps: openssl asn1parse < /usr/share/univention-ldap/dh_2048.pem
<http://errata.univention.de/ucs/4.0/270.html>