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 1155186 - Can't switch off SSLv3 cipher groups in haproxy
Summary: Can't switch off SSLv3 cipher groups in haproxy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: haproxy
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ryan O'Hara
QA Contact: Brandon Perkins
URL:
Whiteboard:
Depends On: 1212193
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-21 14:20 UTC by Neil Wilson
Modified: 2015-11-19 12:09 UTC (History)
0 users

Fixed In Version: haproxy-1.5.12-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:09:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Self signed cert used. (1.61 KB, text/x-vhdl)
2014-10-21 16:04 UTC, Neil Wilson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1383704 0 None None None Never
Red Hat Product Errata RHBA-2015:2376 0 normal SHIPPED_LIVE haproxy bug fix and enhancement update 2015-11-19 10:41:33 UTC

Description Neil Wilson 2014-10-21 14:20:56 UTC
Description of problem:

You don't seem to be able to switch off cipher groups in haproxy - which makes it difficult to deal with the POODLE problem by turning off sslv3.


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

1.5.2-3.el7_0

How reproducible:

If you add the 'no-sslv3' option to an ssl configuration, stop and start haproxy, and then run nmap against it.

nmap --script ssl-enum-ciphers -p 443 <server-name>

you still see the sslv3 ciphers listed.

Host is up (0.035s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_DES_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: weak

Nmap done: 1 IP address (1 host up) scanned in 2.91 seconds

Similarly an sslv3 connection still works:

openssl s_client -connect <server>:443 -ssl3

...

SSL handshake has read 1106 bytes and written 352 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol : SSLv3
    Cipher : DHE-RSA-AES256-SHA
    Session-ID: BD5B48A809FDFD00CD7C2479A8E1E0B145AD7B546D12591E4D439413651C247A
    Session-ID-ctx:
    Master-Key: 6DD4FBA8A6A09736EB37AC72CCFC29F6B3FA8C1B35E2451762EE99C5227D36835F6926104781839CA5135EFFFE8888E8
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1413896330
    Timeout : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---


Additional info:

Config:

global
    user haproxy
    group haproxy

defaults
    timeout connect 30000
    timeout client  50000
    timeout server  50000
    timeout check   5000

  # Listener lba-f22gv-https-443
  frontend lba-f22gv-https-443_frontend
        bind 0.0.0.0:443 no-sslv3 ssl crt /etc/haproxy/ssl_cert.pem
	reqadd X-Forwarded-Proto:\ https
        default_backend lba-f22gv-https-443_backend

  backend lba-f22gv-https-443_backend
    balance leastconn
    mode http
    option forwardfor
    server brightbox 109.107.36.218:80

Comment 2 Ryan O'Hara 2014-10-21 14:47:38 UTC
You have to put "no-sslv3" after the "ssl" option. For the example shown in comment #1, change this:

bind 0.0.0.0:443 no-sslv3 ssl crt /etc/haproxy/ssl_cert.pem

To this:

bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl_cert.pem no-sslv3

The retry the nmap test and you should see this:

Starting Nmap 6.45 ( http://nmap.org ) at 2014-10-21 09:45 CDT
Nmap scan report for 10.15.85.31
Host is up (0.15s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   SSLv3: No supported ciphers found
....

Comment 3 Neil Wilson 2014-10-21 15:24:30 UTC
Yes I've done that. That's not the cause.

The cause seems to be self-signed certs. If you use a self-signed cert, you should see the problem.

A cert from a CA seems to show up the deny.

Comment 4 Ryan O'Hara 2014-10-21 15:30:23 UTC
(In reply to Neil Wilson from comment #3)
> Yes I've done that. That's not the cause.
> 
> The cause seems to be self-signed certs. If you use a self-signed cert, you
> should see the problem.
> 
> A cert from a CA seems to show up the deny.

I used a self-signed cert.

Comment 5 Neil Wilson 2014-10-21 16:04:28 UTC
Created attachment 949043 [details]
Self signed cert used.

When you use this self-signed cert on RHEL7 with haproxy (as opposed to Fedora!) then the SSL port is open and reports nothing.

Comment 6 Ryan O'Hara 2014-10-31 01:28:02 UTC
It appears the cause was identified and fixed in the latest haproxy upstream release, 1.5.7. From the release announcement on the haproxy mailing list:

  - John Leach reported an interesting bug in the way SSL certificates were
    loaded : if a certificate with an invalid subject (no parsable CN) is
    loaded as the first in the list, its context will not be updated with the
    bind line arguments, resulting in such a certificate to accept SSLv3
    despite the "no-sslv3" keyword. That was diagnosed and fixed by Emeric.

Comment 9 Ryan O'Hara 2015-06-24 12:48:50 UTC
The rebase to haproxy version 1.5.12 (#1212193) contains the upstream fix for this issues. Marking this as modified.

Comment 13 errata-xmlrpc 2015-11-19 12:09:18 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-2376.html


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