RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1320295 - If nsSSL3 is on, even if SSL v3 is not really enabled, a confusing message is logged.
Summary: If nsSSL3 is on, even if SSL v3 is not really enabled, a confusing message is...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-22 19:10 UTC by German Parente
Modified: 2020-09-13 21:42 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.5.2-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 20:40:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1835 0 None None None 2020-09-13 21:42:14 UTC
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description German Parente 2016-03-22 19:10:53 UTC 
Description of problem:

it seems that some values under cn=encryption,cn=config are calculated from sslVersionMin and sslVersionMax.

Now, let's change in the console, the value of nsSSL3 to "on":

================================
time: 20160322194222
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: on
================================

in the console, it stays still to off (it's calculated from, in my case:

sslVersionMin: TLS1.0
sslVersionMax: TLS1.2

And also it's calculated in ldapsearch output:

 ldapsearch -D "cn=directory manager" -w secret12 -b "cn=encryption,cn=config"  | grep nsSSL3:
nsSSL3: off

But this calculated value is not written to dse.ldif:

grep nsSSL3:  /etc/dirsrv/slapd-server/dse.ldif
nsSSL3: on

So, at restart:

systemctl restart dirsrv 

[22/Mar/2016:20:01:52 +0100] - SSL alert: Found unsecure configuration: nsSSL3: on; We strongly recommend to disable nsSSL3 in cn=encryption,cn=config.
[22/Mar/2016:20:01:52 +0100] - SSL alert: Configured range: min: TLS1.0, max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the supported range.
[22/Mar/2016:20:01:52 +0100] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2

And this is very confusing for customer.

Now, if we go to the console to set it to off, it is already to off.

Regards,

German.

Version-Release number of selected component (if applicable):

389-ds-base-1.3.4.0-26.el7_2.x86_64


How reproducible: always.


Steps to Reproduce:
1. change value of nsSSL3 to on in the console.
2. restart server.
3. grep dse.ldif 
4. ldapsearch it or view in console

Actual results:

Values differ and the messages at startup are confusing.


Additional info:

Workaround:

change value in dse.ldif after stopping the server.
Comment 7 Noriko Hosoi 2016-03-23 00:09:19 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/48775
Comment 9 Simon Pichugin 2016-08-02 14:17:17 UTC 
Build tested:
389-ds-base-1.3.5.10-5.el7.x86_64

Fix commit message says:
"Description: The config entry cn=encryption,cn=config takes old and new
formats to specify SSL versions.
* old format:
  nsSSL3: on|off
  nsTLS1: on|off
* new format:
  sslVersionMin: <min value, e.g., TLS1.0>
  sslVersionMax: <max value, e.g., TLS1.3>
To enable SSLv3, both nsSSL3 needs to be on and sslVersionMin needs to
set to SSL3.  But the current code logs the following warning if nsSSL3
is on, even if sslVersionMin is set to higher than SSL3:
  Found unsecured configuration: nsSSL3: on; We strongly recommend to
  disable nsSSL3 in cn=encryption,cn=config.

Instead, this patch changes the behaviour to log the warning only when
nsSSL3 is on and sslVersionMin is set to lower than or equal to SSL3:
  Min value is too low in range: min: SSL3, max: TLS##;
  We strongly recommend to set sslVersionMin higher than TLS1.0."

Verification steps:
1) Install Directory Server instance

2) Enable SSL

3) Set nsSSL3: on
[root@rhel-dev ~]# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: on

modifying entry "cn=encryption,cn=config"

4) Set sslVersionMin: SSL3
[root@rhel-dev ~]# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123
dn: cn=encryption,cn=config
changetype: modify
replace: sslVersionMin
sslVersionMin: SSL3

modifying entry "cn=encryption,cn=config"

5) Restart the instance

6) Check error log for the warning message
[root@rhel-dev ~]# tail /var/log/dirsrv/slapd-rhel-dev/errors
[02/Aug/2016:16:08:44.142836232 +0200] SSL alert:       TLS_RSA_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER)
[02/Aug/2016:16:08:44.159967815 +0200] SSL alert:       TLS_RSA_WITH_RC4_128_MD5: enabled, (WEAK CIPHER)
[02/Aug/2016:16:08:44.164679188 +0200] SSL alert:       SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA: enabled, (WEAK CIPHER)
[02/Aug/2016:16:08:44.169573949 +0200] SSL alert:       SSL_RSA_FIPS_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER)
[02/Aug/2016:16:08:44.174629834 +0200] SSL alert:       TLS_RSA_WITH_DES_CBC_SHA: enabled, (WEAK CIPHER)
[02/Aug/2016:16:08:44.193644636 +0200] SSL alert: Min value is too low in range: min: SSL3, max: TLS1.2; We strongly recommend to set sslVersionMin higher than TLS1.0.
[02/Aug/2016:16:08:44.198469638 +0200] SSL Initialization - Configured SSL version range: min: SSL3, max: TLS1.2
[02/Aug/2016:16:08:44.209585378 +0200] 389-Directory/1.3.5.10 B2016.197.39 starting up
[02/Aug/2016:16:08:44.313029303 +0200] slapd started.  Listening on All Interfaces port 389 for LDAP requests
[02/Aug/2016:16:08:44.318594584 +0200] Listening on All Interfaces port 636 for LDAPS requests

Marking as verified.
Comment 11 errata-xmlrpc 2016-11-03 20:40:41 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://rhn.redhat.com/errata/RHSA-2016-2594.html
Note You need to log in before you can comment on or make changes to this bug.