Hide Forgot
Description of problem: When I have NSSFIPS enabled/On, any settings I have in NSSProtocol are ignored. This presents an issue when I only want to use TLSv1.2 and exclude TLSv1.0 and TLSv1.1. When NSSFIPS is enabled/On it forces TLSv1.0->1.2 to be used as protocols. Version-Release number of selected component (if applicable): mod_nss-1.0.10-1.el6.x86_64 How reproducible: Always. Steps to Reproduce: 1. Set NSSFIPS On 2. Set NSSProtocol TLSv1.2 3. Make request like `curl --tlsv1.0 https://localhost:8443/` Actual results: curl using TLSv1.0 succeeds. Expected results: curl using TLSv1.0 would have SSL Handshake failure due to no overlapping protocols. Additional info: This may be an invalid bug report if FIPS requires TLSv1.0->1.2 to be used. Is the ability to use _only_ TLSv1.2 valid in terms of FIPS compliance? nss_engine_init.c:596 if (mctx->sc->fips) { ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, "In FIPS mode ignoring %s list, enabling TLSv1.0, TLSv1.1 and TLSv1.2", protocol_marker); tls = tls1_1 = tls1_2 = 1; }
I think the intention originally was to only allow TLSv1 and disable SSL2 and 3. This was before the range code and TLS 1.1 and 1.2 support. I think this just needs to be set the minimum range to TLS 1.0 by default and let NSSProtocol override it for higher values. I don't see a configuration workaround.
Created attachment 1130696 [details] Patch for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled.
Created attachment 1130697 [details] mod_nss.spec file diffs for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled.
I compiled and performed some minimal testing per the procedure documented in the initial description.
Comment on attachment 1130696 [details] Patch for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled. Functionally it is ok, I just have a few suggestions: 1. I think the initial "if (mctx->sc->fips)" check can be removed completely. I don't know that we learn anything by retaining it other than it detected we're in FIPS mode. 2. For the SSL2 and SSL3 checks rather than just logging "Disabling SSL[23]" I'd log that SSL[23] is disabled by FIPS policy or something like that. 3. For the final catch-all in FIPS mode for the case where no valid protocols were provided I'd change the log message to reflect that, something like: "%s: FIPS mode no valid protocols set, enabling TLSv1.0, TLSv1.1 and TLSv1.2", protocol_marker
(In reply to Rob Crittenden from comment #6) > Comment on attachment 1130696 [details] > Patch for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled. > > Functionally it is ok, I just have a few suggestions: > > 1. I think the initial "if (mctx->sc->fips)" check can be removed > completely. I don't know that we learn anything by retaining it other than > it detected we're in FIPS mode. > DONE > 2. For the SSL2 and SSL3 checks rather than just logging "Disabling SSL[23]" > I'd log that SSL[23] is disabled by FIPS policy or something like that. > QUESTION: Should these FIPS messages be marked as WARNING or INFO instead of DEBUG? > 3. For the final catch-all in FIPS mode for the case where no valid > protocols were provided I'd change the log message to reflect that, > something like: > > "%s: FIPS mode no valid protocols set, enabling TLSv1.0, TLSv1.1 and > TLSv1.2", > protocol_marker QUESTION: Should this message be marked as WARNING rather than INFO?
I think WARNING for the first, INFO for the second.
Created attachment 1130895 [details] Patch for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled. Attached revised patch for your review. Once again, I ran a number of tests to make certain that it still works.
Comment on attachment 1130697 [details] mod_nss.spec file diffs for rhbz #1312052 - NSSProtocol is ignored when NSSFIPS is enabled. LGTM
Verified using mod_nss :: mod_nss-1.0.10-6.el6.x86_64 Please see attachments for verification steps and console.log.
Created attachment 1132791 [details] console.log
Created attachment 1132792 [details] httpd_error_access_log
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. https://rhn.redhat.com/errata/RHBA-2016-0751.html