Hide Forgot
I was asked to report this bug by Tomas Hoger in bug 818670. This is just a note that if httpd is rebuilt with the current OpenSSL in RHEL-6.5, it will start to automatically support ECDH key exchange ciphersuites. If errata is done for bug 1034984, it should be probably noted in the errata, that this support is now there.
Scratch my comment. httpd 2.2.15 (el6) does not support ECDH support, so rebuilding against an OpenSSL with ECDH support will not make any difference. Adding ECDH support is an option via the referenced patch.
This is the commit: http://svn.apache.org/viewvc?view=revision&revision=1540727
Yes, sorry, that's the one.
I can't read comments 6-9, but I got the text via email. About Comment #9: We need that. RH Case 00952610. We try to use Red Hat to implement a secure webserver. Following the German BSI and US NIST [2] SHA is not allowed any more. RedHat offers two SSL solutions mod_ssl and mod_nss. When using mod_ssl with Firefox 27 [3] (most current version of our most used browser), only with ECDHC it is possible to use SHA256. We would also like to offer GCM and that also required ECDHC with our second most often used Brower IE [4]. When using mod_nss no SHA256 or high is available, both by my own observation [5] as well as [6] see NSSCipherSuite. [1] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekSignatur/BSI_SHA1_Zert_07_pdf.pdf;jsessionid=91EE7C347A0ECF75110CE9FCF9FAF677.2_cid391?__blob=publicationFile [2] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf [3] https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=27&platform=Win%208 [4] https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1 [5] https://git.fedorahosted.org/cgit/mod_nss.git/tree/nss_engine_init.c [6] https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html#Directives
(In reply to Jens Kuehnel from comment #10) > I can't read comments 6-9, but I got the text via email. > > About Comment #9: > We need that. RH Case 00952610. The conversation was about automatic selection of curves used for ECDHE. Current version of openssl and mod_ssl as shipped in RHEL can use only one curve (nist256p by default). The discussion was about a mechanism implementing selection of the ECDHE curve based on curves advertised by client in ClientHello message. This does not impact the overall ability to support ECDHE cipher suites. Manual selection of the curve used by ECDHE is tracked in bug 1057656. > We try to use Red Hat to implement a secure webserver. Following the German > BSI and US NIST [2] SHA is not allowed any more. > RedHat offers two SSL solutions mod_ssl and mod_nss. SHA-1 used as a HMAC or KDF is allowed by NIST (see pages 13-14 [2]) so cipher suites that use SHA-1 are still allowed. > When using mod_ssl with Firefox 27 [3] (most current version of our most > used browser), only with ECDHC it is possible to use SHA256. > We would also like to offer GCM and that also required ECDHC with our second > most often used Brower IE [4]. > > When using mod_nss no SHA256 or high is available, both by my own > observation [5] as well as [6] see NSSCipherSuite. Please escalate those issues through Customer Portal, this way we can prioritise them the best way possible.
> The conversation was about automatic selection of curves used for ECDHE. Ahh, OK. I only read commend #9 and answered that ECDH is needed by a customer. Sorry, that happens with private comments. > Current version of openssl and mod_ssl as shipped in RHEL can use only one I'm pretty sure that mod_ssl in RHEL 6.5 does not support ECDHE. Wouldn't this bug be useless if this was the case? > > We try to use Red Hat to implement a secure webserver. Following the German > > BSI and US NIST [2] SHA is not allowed any more. > > RedHat offers two SSL solutions mod_ssl and mod_nss. > SHA-1 used as a HMAC or KDF is allowed by NIST (see pages 13-14 [2]) so > cipher suites that use SHA-1 are still allowed. Thanks, you are right. I will reread the German BSI warning to check what they are saying. I will check if that change the requirement I get from our security department. I don't think so, they want the strongest crypto possible. > Please escalate those issues through Customer Portal, this way we can > prioritise them the best way possible. It is handled by Case 00952610, so this is already on the way.
(In reply to Jens Kuehnel from comment #12) > > Current version of openssl and mod_ssl as shipped in RHEL can use only one > I'm pretty sure that mod_ssl in RHEL 6.5 does not support ECDHE. Wouldn't > this bug be useless if this was the case? Yes, I was thinking about OpenSSL while wrote down both of them. ECDHE is not supported by mod_ssl as shipped in RHEL 6, this bug is about this very issue. Sorry for any confusion caused.
Is it possible to get a copy of this rpm or srpm? Thanks
The previous Comment 11 suggested that openssl/mod_ssl only supports a single curve, (nist256p by default), but traces I have from a sendmail instance on CentOS6 indicate that openssl/sendmail/STARTTLS itself also supports secp384r1, so it would seem feasible for mod_ssl to have secp384r1 support, but I don't know whether it is intended that this bugfix would add that capability. Is it intended to add secp384r1 support to mod_ssl as part of this? Comment 11 also suggested that: "Manual selection of the curve used by ECDHE is tracked in bz1057656." My understanding is that bz1057656 related to the dynamic selection of the DH Parameters rather than the EC Parameters, and 1057656 has been superseded by bz1071883, anyway. What may be more relevant is a corresponding bugzilla for RHEL7, i.e. bz1080125, which relates to the dynamic selection of EC parameters. Is there any intention to roll the fix for bz1080125 into the generic backporting of ECDH into httpd on RHEL6? Whilst the lack of aforementioned support for SHA256 and GCM may be important, the more pressing requirement in my view is the provision of Perfect-Forward-Secrecy capable Ciphers to Windows Clients. At present, because of a lack of support for Cipher Suites "TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)" or "TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)" in Windows7/8, any Windows Client has to fallback to a non-PFS Cipher when communicating with a RHEL6 Apache instance. I'm not entirely sure why Win7/Win8 don't support the DHE Ciphers, but I would judge that it will be faster to add EC to RHEL6 rather than DHE to Win7.
(In reply to Ted Rule from comment #32) > The previous Comment 11 suggested that openssl/mod_ssl only supports a > single curve, (nist256p by default) > but traces I have from a sendmail > instance on CentOS6 indicate that openssl/sendmail/STARTTLS itself also > supports secp384r1, so it would seem feasible for mod_ssl to have secp384r1 > support, but I don't know whether it is intended that this bugfix would add > that capability. Is it intended to add secp384r1 support to mod_ssl as part > of this? mod_ssl can use only one curve, and it will use it for all connections that use ECDHE . The user can change it to different one from nistp256p default but user can't set multiple ones and let OpenSSL/mod_ssl automatically select the best one (or one also supported by client) on a per connection basis. This limitation is caused by both OpenSSL (bug 1080128) and mod_ssl (bug 1080125). > Comment 11 also suggested that: > > "Manual selection of the curve used by ECDHE is tracked in bz1057656." > > My understanding is that bz1057656 related to the dynamic selection of the > DH Parameters rather than the EC Parameters, and 1057656 has been superseded > by bz1071883, anyway. that's correct > What may be more relevant is a corresponding bugzilla for RHEL7, i.e. > bz1080125, which relates to the dynamic selection of EC parameters. > Is there any intention to roll the fix for bz1080125 into the generic > backporting of ECDH into httpd on RHEL6? The general backport of ECDHE functionality is covered by this bugzilla entry. Bug 1080125 is related to making the implementation RFC compliant. The backported functionality is interoperable with significant majority of ECC capable clients, including all major cryptographic libraries working in default configuration (RFC compliance is not needed for interoperability at current time). > Whilst the lack of aforementioned support for SHA256 and GCM may be > important, Both ciphers that use SHA-256 PRF or HMAC and ones that use AES-GCM cipher suites are supported by currently released mod_ssl/openssl. > the more pressing requirement in my view is the provision of > Perfect-Forward-Secrecy capable Ciphers to Windows Clients. At present, > because of a lack of support for Cipher Suites > "TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)" or > "TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)" in Windows7/8, any Windows > Client has to fallback to a non-PFS Cipher when communicating with a RHEL6 > Apache instance. I'm not entirely sure why Win7/Win8 don't support the DHE > Ciphers, but I would judge that it will be faster to add EC to RHEL6 rather > than DHE to Win7. The main goal of this bugzilla is to make mod_ssl support ECDH cipher suites in general, that includes both static and ephemeral (ECDHE) key exchange. This includes support for ECDHE-RSA-AES128-SHA (0xc013), ECDHE-ECDSA-AES128-SHA (0xc009) or ECDHE-ECDSA-AES128-GCM-SHA256 (0xc02b) among others (see `openssl ciphers -V 'ECDH:!eNULL:!aNULL'` output for full list).
httpd-2.2.15-30.el6_5 ===================== :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-AES128-GCM-SHA256 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ FAIL ] :: Connecting to localhost with openssl (Expected 0, got 1) :: [ FAIL ] :: File '/var/tmp/tmp.PfiSrOXmw3' should contain 'Cipher is ECDHE-RSA-AES128-GCM-SHA256' :: [ FAIL ] :: File '/var/tmp/tmp.PfiSrOXmw3' should contain 'Server Temp Key: ECDH' :: [ FAIL ] :: File '/var/tmp/tmp.PfiSrOXmw3' should contain 'Verify return code: 0' :: [ FAIL ] :: File '/var/tmp/tmp.PfiSrOXmw3' should not contain 'fail' :: [ FAIL ] :: File '/var/tmp/tmp.PfiSrOXmw3' should not contain 'error:' ### and all other cipher variants with ECDH failed too ### httpd-2.2.15-39.el6 =================== :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-AES128-GCM-SHA256 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.0QqpF4zUZs' should contain 'Cipher is ECDHE-RSA-AES128-GCM-SHA256' :: [ PASS ] :: File '/var/tmp/tmp.0QqpF4zUZs' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.0QqpF4zUZs' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.0QqpF4zUZs' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.0QqpF4zUZs' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-AES256-GCM-SHA384 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.WvvXpMGiQz' should contain 'Cipher is ECDHE-RSA-AES256-GCM-SHA384' :: [ PASS ] :: File '/var/tmp/tmp.WvvXpMGiQz' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.WvvXpMGiQz' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.WvvXpMGiQz' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.WvvXpMGiQz' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-AES256-SHA384 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.01Jn8d7IeB' should contain 'Cipher is ECDHE-RSA-AES256-SHA384' :: [ PASS ] :: File '/var/tmp/tmp.01Jn8d7IeB' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.01Jn8d7IeB' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.01Jn8d7IeB' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.01Jn8d7IeB' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-AES256-SHA :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.C0N5JkPWRY' should contain 'Cipher is ECDHE-RSA-AES256-SHA' :: [ PASS ] :: File '/var/tmp/tmp.C0N5JkPWRY' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.C0N5JkPWRY' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.C0N5JkPWRY' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.C0N5JkPWRY' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-DES-CBC3-SHA :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.pgdiojyxB9' should contain 'Cipher is ECDHE-RSA-DES-CBC3-SHA' :: [ PASS ] :: File '/var/tmp/tmp.pgdiojyxB9' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.pgdiojyxB9' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.pgdiojyxB9' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.pgdiojyxB9' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-RC4-SHA :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.IEGg8O6YgW' should contain 'Cipher is ECDHE-RSA-RC4-SHA' :: [ PASS ] :: File '/var/tmp/tmp.IEGg8O6YgW' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.IEGg8O6YgW' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.IEGg8O6YgW' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.IEGg8O6YgW' should not contain 'error:' :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Testing httpd with ECDH, cipher: ECDHE-RSA-RC4-SHA :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Command 'rm -f /etc/pki/tls/private/localhost.key /etc/pki/tls/certs/localhost.crt' (Expected 0, got 0) :: [ PASS ] :: Command 'openssl ecparam -name secp384r1 -out p384.pem' (Expected 0, got 0) :: [ PASS ] :: Command 'openssl req -x509 -newkey ec:p384.pem -keyout server.key -out server.crt -subj /CN=localhost -nodes -batch' (Expected 0, got 0) :: [ PASS ] :: Command 'cat server.key >> /etc/pki/tls/private/localhost.key' (Expected 0, got 0) :: [ PASS ] :: Command 'cat server.crt >> /etc/pki/tls/certs/localhost.crt' (Expected 0, got 0) :: [ PASS ] :: Command 'rlServiceStart httpd' (Expected 0, got 0) :: [ PASS ] :: Connecting to localhost with openssl (Expected 0, got 0) :: [ PASS ] :: File '/var/tmp/tmp.Tf0rLuqHwx' should contain 'Cipher is ECDHE-ECDSA-AES128-GCM-SHA256' :: [ PASS ] :: File '/var/tmp/tmp.Tf0rLuqHwx' should contain 'Server Temp Key: ECDH' :: [ PASS ] :: File '/var/tmp/tmp.Tf0rLuqHwx' should contain 'Verify return code: 0' :: [ PASS ] :: File '/var/tmp/tmp.Tf0rLuqHwx' should not contain 'fail' :: [ PASS ] :: File '/var/tmp/tmp.Tf0rLuqHwx' should not contain 'error:' ### test will be added after some more tuning ###
the last section of test run with ECDHE-ECDSA-AES128-GCM-SHA256 cipher, header is incorrect
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1386.html