Weak Ciphers in WAF

Hi Jeffrey Jaspers 

Emile has correctly mentioned the limitation. The Ciphers are located in reverseproxy.conf file hence it won't be persistent in a similar way as changes mentioned by Bob for httpd.conf

I've voted for the feature request already and I encourage you to do that as well. And you should ask your account manager to get a status on this.

Hi Jaydeep,

For WAF, the ciphers are in /var/chroot-reverseproxy/usr/apache/conf/httpd.conf, and after we were told to modify that conf file, I don't recall folks having to redo the changes.  I suspect that that's because the changes were also done at Sophos before a major Up2Date might have replaced that file.

NOTE about an hour later: As Emile points out below, it's another file in that same directory that contains the ciphers: reverseproxy.conf

NOTE a day later: as Sabine points out below, the change should indeed be made in the httpd.conf file.  As Jaydeep mentions above, reverseproxy.conf changes are not persistent.

Cheers - Bob

Hi Bob,

Checked with a Customer i was onsite with today what they have to do and they have to modify the reverseproxy.conf file.

The HTTPD.conf file, that apploes to the webadmin/user portal doesn't it? (or am i getting wires crossed).

Emile

Thanks, you're right, Emile, it is the reverseproxy.conf file, so I'll correct my post.

If you look back at your notes on addressing POODLE, you'll see that we modified httpd.conf in the /var/chroot-reverseproxy/usr/apache/conf directory.

Cheers - Bob

Thanks, you're right, Emile, it is the reverseproxy.conf file, so I'll correct my post.

If you look back at your notes on addressing POODLE, you'll see that we modified httpd.conf in the /var/chroot-reverseproxy/usr/apache/conf directory.

Cheers - Bob

Hi Folks!

I am going to change this in my lab device to see when these Ciphers are reset. So I'll check a change in config first, then a reboot and then an update(now that it's available). I'll post my observations here.

Hi JayDeep,

Thank you for helping us out. I also voted for this to just be available in the GUI. Thanks to Bob and Douglas I know what to do. Im 100% sure we can get it to work and get it secure. But the big problem here is Sophos not supporting it. 

!! It is a security problem not being fixed by a security company.

Just frustrating.

Hello Jeffrey, I ran into exactly the same problem. Thank for sharing your insights.
You wrote: " I know what to do. Im 100% sure we can get it to work and get it secure. "

Are you willing to share the contents of the configuration file once you've altered and tested it?

Thnx, Peter-Paul

Hi Peter-Paul,

To bad you ran into the same problem. I hope I can test it next week. I'll have to setup a testing environment first and of course my coworkers are on vacation... So you know how it is XD. I will definitly share this, whether it works or not.

Hi,

it's possible to override the settings in the reverseproxy.conf at the end of the httpd.conf. The settings in httpd.conf aren't overwritten by config changes or reboot.

Edit /var/chroot-reverseproxy/usr/apache/conf/httpd.conf:

After the line 'Include conf/reverseproxy.conf' you can put for example:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!aNULL:!MD5:!DSS

Restart the reverseproxy: /var/mdw/scripts/reverseproxy restart

Best,

 Sabine

Hello Sabine,

thanks for sharing, but is this supported by Sophos? Not only for home or lab use, but for a production environment? That is the important question for most here.

At least an entry in the KB should or could deal with that.

Best regards

Alex

Hi Sabine,

I put up a testing environment just yet. It is a virtualised UTM running 9.4.xx and has a home license installed. So I was just testing what you said, but I experience a failure after restarting the reverseproxy service. After adding the SSLCipherSuite line the reverseproxy service wont start. When I remove the line the service starts without a problem. I will be testing more today so I'll keep you posted.

Hi,

did you by chance add the SSLProtocol line instead of the SSLCipherSuite?
Because this won't work.

Btw. in 9.4, the directive SSLCipherSuite is still located in httpd.conf. So, you can just change it there. Starting with 9.5, it's in the reverseproxy.conf.

Hi all,

So I tested today with all version from 9.4.xx and up to 9.6.latest. I repeatedly tried to change the SSLCipherSuite. First in the httpd.conf and later in the reverseproxy.conf. That change can be made very easily and seems to be working well. BUT... indeed whenever you make ANY change in  your WAF setting, or you do a fireware update, or you do a reboot your reverseproxy.conf file will change your SSLCipherSuite back to the default setting. 

I would advise to experiment this with smaller environments where WAF settings are barely touched/changed. For myself/my company (we are a hosting party so we change the WAF a lot) we cannot use this. Yes we could change the reverseproxy.conf after every change we do. But it is too much/too dangerous work for a production environment. because you can only do it from the CLI.

So my message to Sophos, fix this please. For all the users which rely on you for their security. Your WAF products contains weak Ciphers which cannot be changed.

For now my question is answered and I want to thank you all for your help, and I really hope Sophos will hear and listen to our shout out.

My next step is to get a refund of my license and then I will need to look for a product which can provide us with a secure WAF.

Greets,

Jeffrey Jaspers

Hi Folks

Just to add to this thread (though I suspect everybody here will already realise this, but just to add it for the benefit of anybody new here searching for information on same) I've been experimenting using https://www.ssllabs.com/ (hey, I'm stuck in the house and suffering from cabin fever; it's either experimenting with this or just hitting the gin) and I found that based on the contents of Sabine's excellent post on page 1 (the key part being as pasted below) the tweak did indeed drop a lot of the ones SSLlabs deemed as being 'weak'...

Edit /var/chroot-reverseproxy/usr/apache/conf/httpd.conf:

After the line 'Include conf/reverseproxy.conf' you can put for example:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!aNULL:!MD5:!DSS

Restart the reverseproxy: /var/mdw/scripts/reverseproxy restart

…but the SSLlabs test did still contain a moderately sizable list of others that they now also deem to be weak, so I did some further experimenting and found a more strict option using SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:!aNULL:!MD5:!DSS which restricts them down to just the below list:

As you can see, according to SSLlabs that still facilitates just two of the weaker ones, but including these last two does enable the entire list of semi-antique clients to successfully pass the handshake test. I did try a couple of others, with one variant resulting in the bottom line from that table disappearing (which would only have impacted on IE11 on Windows Phone 8.1, but not an updated version of same) and another I tried removed both of the last 'weak' lines (SSLCipherSuite ECDH+AESGCM:DH+AESGCM:!aNULL:!MD5:!DSS, but that also took out Safari versions up to and including 8) so in the end, I elected to just leave it as SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:!aNULL:!MD5:!DSS and thus have everything on the clients list showing as being happy to talk to me (so quite significantly better than my status within the real world, then). :-)

All the best to all,
Pottering Briain