Univention Bugzilla – Bug 34391
Support ECDHE Apache / Perfect Forward Secrecy
Last modified: 2015-01-29 11:52:52 CET
The Apache version in Wheezy/UCS doesn't support ECHDE. There's a bug on adding it to a point update: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733564 Background on ECHDE: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
This has been marked as "fixed in version 7.6"
Since all modern browsers support TLS 1.2 and ECs by now we could also accept only strong cipher suites. I tested the following successfully with UCS 4.0 MS1: add to .../mods-available/ssl.conf: > SSLHonorCipherOrder On > SSLCipherSuite "kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:+RC4:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA" "SSLHonorCipherOrder On" makes sure that the order of cipher suites is respected at all. "SSLCipherSuite" orders the cipher suites that OpenSSL provides (execute "openssl ciphers" for a complete list): - put TLS 1.2 + EC based as preferred cipher suites (kEECDH+ECDSA:kEECDH:kEDH) - allow HIGH cipher suites - put cipher suites with SHAv1/SSLv3 as next best choice (+SHA) - still allow RC4-based cipher suites but only if nothing else works (+RC4) - disallow weak cipher suites like NULL, LOW, 3DES, MD5, EXP ... - disallow rarely used cipher suites like PSK, SRP, CAMELLIA ... for a sorted list of the chosen cipher suites, execute the following > openssl ciphers -v 'kEECDH+ECDSA:kEECDH:kEDH:HIGH+SHA:+RC4:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA'
(In reply to Michael Grandjean from comment #1) > This has been marked as "fixed in version 7.6" UCS 4.0 is currently based on the 7.6 point release, so the underlying code base is present at least
In the light of CVE-2014-3566 (Poodle) I think we should reconsider applying the settings in Comment #2, but also drop SSLv3.
Created attachment 6532 [details] Add SSL Cipher Suite and SSLHonorCipherOrder to /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf
(In reply to Michael Grandjean from comment #4) > In the light of CVE-2014-3566 (Poodle) I think we should reconsider > applying the settings in Comment #2, but also drop SSLv3. +1 In my opinion you should not reconsider it but do it badly: UCS is currently bloody vulnerable! Tested (settings used from Comment #2) with UCS 4.0-0 errata10: (ssl.conf.patch appends in Comment #5) root@host:~# apt-get install patch root@host:~# cp /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf etc/univention/templates/files/etc/apache2/mods-available/ssl.conf.orig root@host:~# patch -p0 <ssl.conf.patch /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf root@host:~# diff /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf.orig /etc/univention/templates/files/etc/apache2/mods-available/ssl.conf 51a52,70 > # SSL Cipher Suite: > # List the ciphers that the client is permitted to negotiate. See the > # ciphers(1) man page from the openssl package for list of all available > # options. > @!@ > if configRegistry.get('apache2/ssl/ciphersuite'): > print 'SSLCipherSuite %s' % configRegistry.get('apache2/ssl/ciphersuite') > @!@ > > # SSLHonorCipherOrder > # Option to prefer the server's cipher preference order > # When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the > # client's preference is used. If this directive is enabled, > # the server's preference will be used instead. > @!@ > if configRegistry.get('apache2/ssl/honorcipherorder'): > print 'SSLHonorCipherOrder %s' % configRegistry.get('apache2/ssl/honorcipherorder') > > @!@ root@host:~# ucr set apache2/ssl/ciphersuite='kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:+RC4:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA' root@host:~# ucr set apache2/ssl/honorcipherorder='On' root@host:~# ucr commit /etc/apache2/mods-available/ssl.conf root@host:~# service apache2 restart Settings from Comment #2 are fully backwards compatible, i.e. IE 6/XP is supported (ssl3, TLS_RSA_WITH_RC4_128_SHA) Of course, with a strong focus on safety, these settings are still not optimal,but much better than the present state. Just a note: with focus on security i would recommend the settings from Comment #2, plus disallow rc4 (BEAST attack): root@host:~# ucr set apache2/ssl/ciphersuite='kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA:!RC4' regards Lutz Willek
(In reply to Lutz Willek from comment #6) > Just a note: with focus on security i would recommend the settings from > Comment #2, plus disallow rc4 (BEAST attack): > root@host:~# ucr set > apache2/ssl/ciphersuite='kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:!aNULL:!eNULL:! > LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA:!RC4' Thanks for the patch! I agree that RC4 has some serious issues and that one should stop using it as soon as possible. Personally, I would vote for disallowing RC4 just like you proposed. But just to get things straight: as far as I know BEAST is an attack against CBC encryption in TLS 1.0 and earlier. Using RC4 instead of CBC can be used as a server-side mitigation. The problem is, if one wants to support a diverse client base, one has probably to choose between being vulnerable to either RC4 weaknesses or the BEAST attack. With a focus on security, the best solution would be to ban RC4 and CBC and only allow TLS 1.2 and GCM cipher suites, but that might be too restrictive as a default. Just as a suggestion if someone wants to deploy "TLS-1.2-with-GCM-only": > 'kEECDH+ECDSA+AESGCM:kEECDH+AESGCM:kEDH+AESGCM:!HIGH+SHA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS'
(In reply to Michael Grandjean from comment #7) > With a focus on security, the > best solution would be to ban RC4 and CBC and only allow TLS 1.2 and GCM > cipher suites, but that might be too restrictive as a default. Indeed. This would lock out too many Internet Explorer users: Only 11 enables TLS 1.2 by default, for IE 10 users need to enable it manually and < IE 10 don't support it at all.
Apache in UCS 4.0 supports perfect forward secrecy out of the box. Support for ECDH ciphers was backported from Apache 2.4 in 2.2.22-13+deb7u2, which is part of UCS 4.0. This can be verified by running sslyze or "openssl s_client -connect 10.200.3.160:443": (..) SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 (..) The other issue mentioned on this bug (disabling SSLv3) has been already resolved in erratum 31 for UCS 4.0 and erratum 225 for UCS 3.2. Web browsers perform TLS negotiation and pick the best available option supported by both the server and the client. As a result the following browsers will use AES256-GCM by default: - Chrome >= 30 (since Chrome is usually auto-updated all versions should support it) - Firefox >= 27 (custom installations are usually auto-updated and the ESR series which is used by enterprise deployments and Linux distributions like UCS, Red Hat or Debia) use ESR31, which also supports it) - IE 11 (IE 10 also supports it, but it must be explicitly enabled) - All current Opera releases - Safari >= 7 Only allowing TLS 1.2 would be too intrusive, especially larger deployments will not yet have migrated to IE11. We can add a UCR variable which let people explicitly configure the available ciphersuites. I'll file a separate bug for that.
> We can add a UCR variable which let people explicitly configure the > available ciphersuites. I'll file a separate bug for that. -> Bug 37566
OK: zless /usr/share/doc/apache2.2-common/NEWS.Debian.gz OK: zless /usr/share/doc/apache2.2-common/README.Debian.gz OK: Config ciphers → Bug #37566 OK: openssl s_client -tls1 -cipher ECDH -connect 127.0.0.1:443
r57574 | Bug #34391 test: Check Apache for ECDHE support ucs-test/tests/01_base/83https_ecdhe