Bug 1264951

Summary: sslBackwardCompatibility=false (default) disables too much
Product: Red Hat Enterprise Linux 7 Reporter: Alois Mahdal <amahdal>
Component: tog-pegasusAssignee: Vitezslav Crhonek <vcrhonek>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: lmiksik, psklenar
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tog-pegasus-2.14.1-3.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 11:08:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch none

Description Alois Mahdal 2015-09-21 17:29:14 UTC 
Description of problem
======================

New tog-pegasus introduces option sslBackwardCompatibility:

> sslBackwardCompatibility
>
>        Description:This  setting  specifies  whether  the ssl supports
>        SSLv3 and versions of TLS lesser than 1.2 .Ideally for security
>        Compilance purposes it is by default set to false.
>        Default Value: false
>        Dynamic: No

Per consultation with security QA (Hubert Kario):

While SSLv3 is indeed insecure and dangerous, the same cannot be said
about TLS1.1 or even TLS1.1, so the option effect is a bit excessive.

Since it's off by default, in fact it introduces regression: any clients
that do not use TLS1.2 but will try TLS1.0 or TLS1.1 will be refused.


Version-Release number of selected component
============================================

tog-pegasus-2.14.1-2.el7


How reproducible
================

Always


Steps to Reproduce
==================

 1. Start tog-pegasus service with default settings
 2. connect using TLS1.0 or TLS1.1


Actual results
==============

Connection is shut down (RST) by server


Expected results
================

Connection should succeed.
Comment 1 Vitezslav Crhonek 2015-09-22 08:14:43 UTC 
Created attachment 1075693 [details]
proposed patch

Patch modifies sslBackwardCompatibility option to affect only SSLv3 support. (This should be probably emphasized in release notes, as it differs from upstream/expected behaviour significantly.)
Comment 2 Alois Mahdal 2015-09-22 12:53:47 UTC 
Note to QA: we have at least one test case (TC#506392) that can safely cover this.

Also I will add specific test case as well--it should be really simple:

 1. Connect to the HTTPS port with

     *  various SSL/TLS versions, at least

         *  SSLv3,
         *  TLS1.0 (=SSLv1.1),
         *  TLS1.1
         *  TLS1.2
         *  TLS1.3 if you you have a client that supports it.

     *  sslBackwardCompatibility set to true or false (default)

    Consider using curl, openssl s_client or similar.  It's enough
    if you get connected and *some* reply from the server; an
    HTTP 4xx reply is OK.

 2. Make sure only SSLv3 is turned off by default, and turning on
    sslBackwardCompatibility turns SSLv3 back on (IOW all versions
    will work)
Comment 6 Alois Mahdal 2015-09-24 01:26:52 UTC 
Automated test scheduled for the new build: TJ#1092237
Comment 7 Alois Mahdal 2015-09-24 04:06:16 UTC 
All passed; thanks!

quick fix jumped over the lazy bug
Comment 8 errata-xmlrpc 2015-11-19 11:08:59 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/RHBA-2015-2314.html