Can't switch off SSLv3 cipher groups in haproxy

[Neil Wilson]

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.

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)
---

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: haproxy 1.5.4-1ubuntu1
ProcVersionSignature: User Name 3.16.0-23.30-generic 3.16.4
Uname: Linux 3.16.0-23-generic x86_64
ApportVersion: 2.14.7-0ubuntu7
Architecture: amd64
Date: Tue Oct 21 12:53:25 2014
SourcePackage: haproxy
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.haproxy.haproxy.cfg: 2014-10-21T12:53:17.959361

[Neil Wilson (neil-aldur)]

The issue seems to be caused by a self-signed cert we're using. A cert from a CA seems to work as expected.

[Neil Wilson (neil-aldur)]

From RH Bug list:

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.

[Brian Morton (rokclimb15)]

Nominating this for wontfix since security support has ended for releases with haproxy >= 1.5 and <= 1.5.7. Everything earlier doesn't have SSL support built-in, and everything later is unsupported or has received the upstream fix. The solution is to upgrade to trusty and use backports or upgrade to xenial or newer.

[Christian Ehrhardt  (paelzer)]

Passing haproxy bugs after the latest stable 1-8 has landed in Ubuntu 18.04.
This bug is old and I agree with the former comment - setting states.