How to disable SSLv3 with Haproxy

AlexVallois

Hi PiBa,

Thank you very much. You got it ! My other webserver was not properly configured to deny SSLv3.
Once modified, it works fine.

However, I do not understand why it has any impact when testing SSLv3 with sslscan on the URL of the other website that was properly configured to deny SSLv3. Would it be possible to let me know ?

Thank you again for your quick and efficient help. :)

Alex

PS : previous post modified to manage code with # icon :)

PiBa

Hi Alex,

Probably the sslscan your using didn't send the sni extension, or for some reason its using a slightly different name than what you have configured in haproxy.. Ive sometimes seen that for example the port is included also when running on 443 , so the sni match would be done like "req.ssl_sni -i www.abc.com:443".

As for your sslscan sending sni extension, if you capture the traffic in wireshark and select the 'clienthello' packet. There should be a field ssl.handshake.extensions_server_name that has the sni servername in readable text, maybe its simply not sending it at all?

Regards,
PiBa-NL

AlexVallois

Hi PiBa,

Thank you. I followed your advice.

I did a Wireshark on client hello packets. Here is the result of what I observed :

for protocols TLSv1 and TLSv1.2, I can see a "Server Name Indication extension" section with a field "Server Name" defined to the correct URL.
for SSLv3 protocol, I do not see any entry in SSL section about SNI (see image attached)

Do you think it explains the behavior observed ? Maybe it explains why sslscan do not check the "right" webserver.

Thanks again PiBa.

Alex

sslscan_sslv3.png_thumb

PiBa

Hi Alex,

It seems like openssl which is used by sslscan doesnt like to send sni when using SSLv3 (SSLv3 is not really defined to support the extension very well..). http://security.stackexchange.com/a/101424 has a little info about that.

So that indeed would explain why the request would not match the sni hostname acl, and the default backend was used instead.
I assume that it was indeed the default backend that was not configured to block SSLv3?

Regards,
PiBa-NL

AlexVallois

Hi PiBa,

Thank you very much for this very clear explanation and the link provided.
You're right, I do confirm that it was the default backend that was still accepting SSLv3.

Alex

ACalcutt

Sorry to bring up an old thread, but there aren't many posts about securing HAProxy in pfsense and disabling tls ssl3/1.0/1.1. I just wanted to add a note how to fix this through the GUI in pfsense 21.02.2, which I didn't see anywhere.

The global setting mentioned above can be edited in the pfsense gui at
Services -> HAProxy ->Settings -> Global Advanced pass thru

To secure the ssl settings, go to https://ssl-config.mozilla.org/ and generate a HAProxy config, then add in to the Global Advanced pass thru settings. My settings looked like this

# intermediate configuration https://ssl-config.mozilla.org/
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

johnpoz

I believe all you really need to do to disable ssl3 is this drop down box

Nothing wrong with tweaking the settings how you want with the manual method. But if all your looking to do is disable the old stuff and leave 1.2 and or just even 1.3 You should be able to just use the drop down.

One thing will tell you is the testing site
https://www.ssllabs.com/ssltest/

Will not give you an A+ if only have 1.3 enabled, atleast last time I checked which wasn't all that long ago - there is a thread about getting A+ rating somewhere around here I started.

That was driving me a bit nuts for awhile...

But yeah if your interested/concerned/worried about your settings the above link to testing will give you loads of info about what ciphers, etc. Do you have CAA set, do you have OSCP stapling, HSTS, etc. etc..

ACalcutt

@johnpoz

Where is that tuning setting? When I look in my HAProxy settings I don't have that.

I know about SSL Labs, which is how I saw tls 1.0 and 1.1 were enabled by default (getting a B rating). With the changes I made it only gets a A, but with intermediate settings I used that was expected.

johnpoz

What version of haproxy are you using? I'm on haproxy-devel 0.62_3 package that is 2.2.6 of haproxy.

And its listed right there where you looking on mine.

Little tweaking any you can get A+

ACalcutt

@johnpoz

I am using the non-devel haproxy 0.61_1, so that is probably the difference. I'd imagine these changes in devel will eventually make it to the non-devel version?

It seems like I could tweak this further without upgrading the haproxy package to devel so I'm going to keep it on the stable release for now, but it is good to know it might be easier in the future. I looked all over today and kept getting back to this post.