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 1264951 - sslBackwardCompatibility=false (default) disables too much
Summary: sslBackwardCompatibility=false (default) disables too much
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tog-pegasus
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Vitezslav Crhonek
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-21 17:29 UTC by Alois Mahdal
Modified: 2015-11-19 11:08 UTC (History)
2 users (show)

Fixed In Version: tog-pegasus-2.14.1-3.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 11:08:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed patch (1.78 KB, patch)
2015-09-22 08:14 UTC, Vitezslav Crhonek 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2314 0 normal SHIPPED_LIVE tog-pegasus bug fix and enhancement update 2015-11-19 10:07:59 UTC

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
Note You need to log in before you can comment on or make changes to this bug.