Bug 1153737 - Disable SSL v3, by default.
Summary: Disable SSL v3, by default.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-16 16:50 UTC by Noriko Hosoi
Modified: 2019-07-11 08:16 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-10.el7
Doc Type: Bug Fix
Doc Text:
Cause: SSL version 3.0 has a known vulnerability. Fix: SSL version 3.0 is disabled, by default. That is, to enable the version, the Directory Server has to be intentionally configured to use SSL version 3.0. Result: The Directory Server is securer.
Clone Of:
Environment:
Last Closed: 2015-03-05 09:36:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
containing verification scripts. (37.48 KB, text/plain)
2014-10-24 00:37 UTC, Noriko Hosoi
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Noriko Hosoi 2014-10-16 16:50:02 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47928

On the new installation, SSL v3 should be disabled by default, and provide the safe cipher suites.

Comment 2 Noriko Hosoi 2014-10-24 00:37:14 UTC
Created attachment 950141 [details]
containing verification scripts.

test_ticket47928_run_0 - Test Case 13 - No SSL version config parameters
test_ticket47928_run_1 - Test Case 14 - No nsSSL3, nsTLS1; sslVersionMin > sslVersionMax
test_ticket47928_run_2 - Test Case 15 - nsSSL3: on; sslVersionMin: TLS1.1; sslVersionMax: TLS1.2
test_ticket47928_run_3 - Test Case 16 - nsSSL3: on; nsTLS1: off; sslVersionMin: TLS1.1; sslVersionMax: TLS1.2

Comment 3 Noriko Hosoi 2014-11-13 18:41:59 UTC
On 11/13/2014 07:25 AM, thierry bordaz wrote:
> On 11/13/2014 01:49 PM, Martin Kosek wrote:
>> On 11/13/2014 01:34 PM, thierry bordaz wrote:
>>> On 11/13/2014 12:55 PM, Martin Kosek wrote:
>> ...
>>>> If yes, how can we set it? Setting sslVersionMin to TLS1.0 does not seem to
>>>> work. The error log is confusing in this case:
>>>>
>>>> [12/Nov/2014:18:52:22 -0500] - SSL alert: Default SSL Version settings;
>>>> Configuring the version range as min: TLS1.0, max: TLS1.2;
>>>> [12/Nov/2014:18:52:22 -0500] SSL Initialization - Configured SSL version range:
>>>> min: TLS1.1, max: TLS1.2
>>>>
>>>> Also, the value I see in dse.ldif does not match what ldapsearch sees. AFAIK,
>>>> Thierry already investigated it, but the fix is not in RHEL-7.1.
>>> In my tests, setting sslVersionMin was not enough. I also had to set 'nsSSL3:
>>> on' to let pki-tomcatd (10.2.0) start.
>>>
>> With paragraph above I was more referring to the fact that even if I change
>> sslVersionMin with ldapmodify, ldapsearch still returns old (default) value
>> even though the value is changed in dse.ldif.
>>
>>
>> Also, do you have any explanation for the DS error log above? Why is min range
>> TLS 1.0 on one line and suddenly it is 1.1 in the next one?
> My understanding is that it is the result of computation to determine the most appropriate TLS version to support.
> In that case ('nsSSL3: off', 'nsTLS1:on') means that all versions >= tls1.0 are supported. But nssVersionMax being >= TLS1.1, it forces nssVersionMin to run TLS1.1 (even if configured with 1.0).
> Modifying the setting (to be more secure) has the drawback of  the two opposite messages and may prevent a customer to configure SSL to match their needs.

I learned from Elio from the NSS team that TLS1.0 and SSL3 are almost equivalent.  So, I thought to disable SSL3, TLS1.0 has to be disabled, too.  Thus, I interpreted nsTLS1 as TLS1.1.

And to support both the old attributes "nsSSL3, nsTLS1" and new ones "nsVersionMin/Max", when conflicts are found, the tighter one is chosen.  That picks up the TLS1.1 for nsVersionMin, which is coming from nsTLS1.

Following the discussion, I could reset the rule as "nsTLS1 is TLS1.0 and newer".  That should allow the default SSL version TLS1.0 and newer, by default.
I'm also setting TLS1.0 to the default nsVersionMin version.

Comment 5 Sankar Ramalingam 2014-11-25 16:08:53 UTC
The default instance shows up the version in cn=encryption,cn=config entry is "sslVersionMin: TLS1.0".

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
sslVersionMin: TLS1.0

And if I enable nsSSL3, then I get error messages...

[21/Nov/2014:20:05:40 +051800] - SSL alert: Found unsecure configuration: nsSSL3: on; We strongly recommend to disable nsSSL3 in cn=encryption,cn=config.
[21/Nov/2014:20:05:41 +051800] - SSL alert: Configured range: min: TLS1.0, max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the supported range.
[21/Nov/2014:20:05:41 +051800] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2

Hence, marking the bug as Verified.

Comment 6 Noriko Hosoi 2014-12-13 01:53:01 UTC
Setting the status to POST for the logconv.pl.
#47949 	logconv.pl -- support parsing/showing/reporting different protocol versions
Total Connections:            293
 - LDAP Connections:          281
 - LDAPI Connections:         0
 - LDAPS Connections:         12
 - StartTLS Extended Ops:     10
 Secure Protocol Versions:
  - TLS1.2 128-bit AES - 7
  - TLS1.1 128-bit AES - 1
  - SSL3 128-bit AES - 2
  - SSL 128-bit AES - 4    --> legacy access log

Comment 7 Sankar Ramalingam 2015-01-05 07:13:25 UTC
Total Connections:            82
 - LDAP Connections:          74
 - LDAPI Connections:         0
 - LDAPS Connections:         8
 - StartTLS Extended Ops:     0
 Secure Protocol Versions:
  - TLS1.2 128-bit AES - 8


Legacy reference for SSL has been removed. Hence, marking the bug as Verified.

Build tested: 
[root@mgmt9 ~]# rpm -qa 389-ds-base
389-ds-base-1.3.3.1-10.el7.x86_64

Comment 9 errata-xmlrpc 2015-03-05 09:36:53 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-2015-0416.html


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