Bug 1706224 - Protocol setting is inconsistent in FIPS mode
Summary: Protocol setting is inconsistent in FIPS mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: ---
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: 8.1
Assignee: mreynolds
QA Contact: RHDS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-03 20:24 UTC by Rob Crittenden
Modified: 2019-11-05 21:00 UTC (History)
10 users (show)

Fixed In Version: 389-ds-base-1.4.1.3-3.module+el8.1.0+3533+f8225121
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 21:00:29 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3401 None None None 2019-11-05 21:00:43 UTC

Description Rob Crittenden 2019-05-03 20:24:01 UTC
Description of problem:

Installing IdM in FIPS mode fails near the end when the DM password is reset over startTLS with a TLS alert.

ldap_start_tls: Connect error (-11) additional info: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

If a min/max value is provided directly for the TLS configuration, even if it matches the default, the installation is successful and LDAP responds.

dn: cn=encryption,cn=config
sslVersionMin: TLS1.0
sslVersionMax: TLS1.3

The TLS configuration messages look identical between a non-working:

[03/May/2019:16:12:45.637681302 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3

and a working configuration.

[03/May/2019:16:14:45.367855588 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3

When failing this is logged whenever a TLS/startTLS connection is made:

[03/May/2019:16:14:48.486690472 -0400] conn=5 fd=66 slot=66 connection from 192.168.121.98 to 192.168.121.98
[03/May/2019:16:14:48.486995136 -0400] conn=5 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[03/May/2019:16:14:48.487029802 -0400] conn=5 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000314375
[03/May/2019:16:14:48.487289319 -0400] conn=5 op=-1 fd=66 closed - security library failure.
[03/May/2019:16:14:48.674047457 -0400] conn=2 op=1 UNBIND
[03/May/2019:16:14:48.674067633 -0400] conn=2 op=1 fd=65 closed - U1

The client receives an error about a tls alert (duplicated using ldapsearch and ldappasswd).

Note that this was discovered while ensuring IdM works in FIPS mode. Other unrelated issues were detected as well.

Version-Release number of selected component (if applicable):
389-ds-base-1.4.0.20-10.module+el8.0.0+3096+101825d5.x86_64

Comment 1 mreynolds 2019-05-08 15:30:21 UTC
More info...

So in this case the problem seems to occur when NSS converts the requested min version from (TLS1.0 to TLS1.2):

sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);

But if we "get" the range after doing the initial "set", and then reset it again with the adjusted values then things start working:

sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeGet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);

If it does convert the range then all TLS connections fail.  If it doesn't have to convert it then it works as expected.

Comment 2 Rob Crittenden 2019-05-08 15:39:24 UTC
My open questions are:

- 389-ds is effectively trying to override the crypto policy which enables only TLS 1.2. Should this work as a general principal?
- Does being in FIPS mode have anything to do with this?

Note that I can duplicate similar behavior using selfserv:

# /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d . -Vtls1.0:tls1.2 -p 999 -f pwdfile.txt -v

When hit using TLS 1.1 it reports:

# openssl s_client -host `hostname` -port 999 -tls1_1

selfserv: About to call accept.
selfserv: HDX PR_Read returned error -12279:
Peer using unsupported version of security protocol.

Comment 4 mreynolds 2019-05-09 17:47:54 UTC
Upstream ticket:
https://pagure.io/389-ds-base/issue/50362

Comment 5 mreynolds 2019-06-18 19:55:32 UTC
This was actually fixed in:  https://pagure.io/389-ds-base/issue/50355

Comment 7 Viktor Ashirov 2019-08-22 09:47:40 UTC
===================================================================== test session starts =====================================================================
platform linux -- Python 3.6.8, pytest-5.1.1, py-1.8.0, pluggy-0.12.0 -- /usr/bin/python3.6
cachedir: .pytest_cache
389-ds-base: 1.4.1.3-5.module+el8.1.0+3776+ece1ae4c
nss: 3.44.0-8.el8
nspr: 4.21.0-2.el8_0
openldap: 2.4.46-10.el8
cyrus-sasl: not installed
FIPS: enabled
rootdir: /root/389-ds-base/dirsrvtests, inifile: pytest.ini
collected 1 item                                                                                                                                              

dirsrvtests/tests/suites/tls/ssl_version_test.py::test_ssl_version_range PASSED                                                                         [100%]

===================================================================== 1 passed in 36.87s ======================================================================

Marking as VERIFIED.

Comment 9 errata-xmlrpc 2019-11-05 21:00:29 UTC
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://access.redhat.com/errata/RHSA-2019:3401


Note You need to log in before you can comment on or make changes to this bug.