How to set Ciphers used by WAF?

Dwayne,

can you report your findings?

Thanks

Hi,

here is a screenshot of the ciphers found by SSL Labs!

Regards, Dwayne Parker

Why are those Cipher Weak? 

https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities?_ga=2.9203317.1382138389.1582128978-560257088.1579687636#comment-303227

https://discussions.qualys.com/thread/17971-tlsrsawithaes256cbcsha-comes-to-be-weak-cipher

https://security.stackexchange.com/questions/210072/why-does-ssl-labs-now-consider-cbc-suites-weak

LuCar Toni please pass the information to devs or to someone that can investigate.

If the user has a paid license, he can open a ticket with support.

Regards

Actually i am not sure why all those used Cipher are weak in general.

Because other sites still listed them as secure. 

Only SSL Labs seems to use them as Weak. 

Example:

https://ciphersuite.info/search/?q=TLS_RSA_WITH_AES_128_CBC_SHA&cat=cs

LuCar Toni from the url:

While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.

and

https://en.wikipedia.org/wiki/Padding_oracle_attack

Yes, they assume, it could be used in the future for attacks, but actually there seems not be any real world attack of CBC? 

https://crypto.stackexchange.com/questions/44071/aes-in-cbc-mode-is-totally-unsecure-if-no-defense-is-provided-for-padding-oracle

To sum up; Please open a Support Case to get this sorted out. 

https://www.tripwire.com/state-of-security/vert/tls-cbc-padding-oracles/

Those Padding Attacks seems to use some sort of MAC variation.

The question is, is WAF in general insecure for those attacks? 

Answer: Regarding to SSLlabs: NO

I am not sure, how they test those attacks? 

Dwayne,

can you check your waf by using this link:

https://observatory.mozilla.org/

This one along with the ssl labs is suggested by OWASP

https://owasp.org/www-project-cheat-sheets/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

Please let us know.

Hi,

I really would like to open a support ticket, but unfortunately I'am a Home User.

Regarding the results of the Mozilla Observatory it seems like some ciphers are also considered as insecure/weak. The Level of the analysis is only "Intermediate".

Here is the explaination of the TLS Levels by Mozilla: https://wiki.mozilla.org/Security/Server_Side_TLS

Also the Keysize is only 2048 bits although my uploaded Certificate is a 4096 bits RSA.

Anyway, setting the used ciphers should be a basic Feature for a WAF.

Regards Dwayne Parker

Hi,

I really would like to open a support ticket, but unfortunately I'am a Home User.

Regarding the results of the Mozilla Observatory it seems like some ciphers are also considered as insecure/weak. The Level of the analysis is only "Intermediate".

Here is the explaination of the TLS Levels by Mozilla: https://wiki.mozilla.org/Security/Server_Side_TLS

Also the Keysize is only 2048 bits although my uploaded Certificate is a 4096 bits RSA.

Anyway, setting the used ciphers should be a basic Feature for a WAF.

Regards Dwayne Parker

Thanks. This should be addressed anyway.

@Flosupport can you help to investigate on this issue? A proper investigation is needed and an official answer is more than welcome!

Hi,

any news on this topic?

FloSupport, I would also be glad, if you could help to investigate this, and post an offical answer here!

If you are a Home User, feel free to simply modify the reverseproxy.conf and remove those cipher. 

The same process, other people did after Poodle appeared. 

https://community.sophos.com/products/unified-threat-management/f/web-server-security/50265/poodle---how-to-disable-sslv3

I am not sure, where to find the reverseproxy.conf in XG, but you should be able to figure out. 

LuCar Toni said:

I am not sure, where to find the reverseproxy.conf in XG, but you should be able to figure out. 

/cfs/waf/reverseproxy.conf

Hi Dwayne,

I'll follow up with the team to investigate this further.

Thanks!

Hi @Dwayne Parker

Here is the response from the development and security team here at Sophos regarding cipher list available in the XG for WAF:

Strong ciphers

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)

Weak ciphers

• Because CBC is used
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)

• Because SHA1 is used (in addition to CBC)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)

• Because no forward secrecy is offered (some also use CBC and/or SHA1)
  • TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
  • TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)

Regarding when "CBC is used"

According to the security team: "CBC being offered is ok as long as its a strong cipher.  That is no 3DES ciphers offered". All offered ciphers are strong is this regard (e.g. no 3DES is offered).

Conclusion: Leave it as it is

Regarding "SHA1 is used"

This is considered OK because SHA1 is used as HMAC-SHA1 which is not broken (unlike pure SHA1). All offered ciphers are strong in this regard.

Security team: "While SHA1 is broken, HMAC-SHA1 is not broken. Assuming that the HMAC key is not known to the attacker, HMAC-SHA1 is not susceptible to the same collision attacks that SHA1 is. If the attacker has the HMAC key, he has broken HMAC itself, no matter if it is HMAC-SHA1 or HMAC-SHA2."

Conclusion: Leave it as it is

Regarding "no forward secrecy is offered"

The overall SSL Labs rating does not change if the non-forward secrecy ciphers are removed.

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

We might lose support for less capable clients if we remove the non-forward secrecy ciphers. Clients that support forward secrecy will prefer the forward secrecy ciphers anyway.

Conclusion: Leave it as it is as it has no impact on clients that support forward secrecy but widens the support for less capable clients

As you can see if you remove the CBC ciphers from the list, you are limiting the client pool that can connect to your WAF instance.

If you would like to remove various ciphers, the file to edit is located here:  /usr/apache/conf/httpd.conf

You need to put the system into read/write mode: mount -no remount, rw /

Then edit the above file with VI and remove the SSL cipher suite offered in this line: SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS

Please note that when WAF is set to use TLS1.2, 3DES ciphers are not offered to the client.

I hope this answers everyone's question surrounding this.

Thanks!