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: 2019-11-14 07:38 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:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 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@server.service 

[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.