Weak Ciphers in WAF

Hi all,

I tried to fix this with Sophos support, but as always the question was to hard. I hope you guys can help me with this. I have a UTM cluster running version 9.5.xx. I enabled the WAF option. Although the WAF is very limited in its options compared to other products, I am really missing one option. Being able to disable weak ciphers. We are a hosting party and we take security very seriously. There for we are looking to use the UTM as a loadbalancer and using all the WAF features available. All done that. No problem

When testing my test site against ssllabs.com I see that weak ciphers are used, and only TLS1.2 is used instead of TLS1.2 and higher. Sophos says we can't help you -goodbye-. Sorry but the product is just to expensive for an answer like that.

Now, I have read some articles about this on how to change the ciphers using the command line interface on the UTM. But I don't know exactly what file to modify, or what to put in it. Does anyone know how to achieve this the best way?

Greets,

Jeffrey

  • In reply to Evianne:

    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 Folks,

    I think Sabine has posted a proper solution. Now in order to apply it on the UTM9, for Home devices, it should not be an issue. For licensed UTM9, it'd be better if it's discussed with the Account manager or Support first before doing these changes. I'll check if this information can be used in a Public article.

    Regarding changes I did my lab device, it was reverted with Change in the config, also with a reboot. I could not check with a firmware update but that's obvious that it will not stay persistent.

  • In reply to Jaydeep:

    Hi JayDeep,

    Thank you for testing this for us. Your answer really helps me/us. I was wondering. You say the config changes back, but could we get around this using a cron job? for example, place the modified file on a location where it wouldn't be overwritten, and after every reboot replace the original file and restart the WAF service.

     

    Greets,

    Jeffrey

  • In reply to Jeffrey Jaspers:

    That would help after a restart. But what about the changes you do in the config? I guess it's not possible to do a cronjob for that. Sabine has suggested a proper fix which is persistent over the changes we would attempt. Would you be able to try that and see if that helps? Please post any difficulties you face.

  • In reply to Jaydeep:

    JayDeep,

     

    Thank you again. I'm setting up my testing environment as we speak. I'll keep you informed.

     

    Greets,

    Jeffrey

  • In reply to Evianne:

    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.

  • In reply to Jeffrey Jaspers:

    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.

  • In reply to Evianne:

    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

  • In reply to Evianne:

    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:

    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)   DH 2048 bits   FS 256
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)   DH 2048 bits   FS 128
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 256

    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