We recently asked a Security Consultant to perform a security audit of applications on our public cloud tenant.
The result of this audit was that ‘weak’ TLS/SSL ciphers appear to be used to secure our Auth0 login page.
The consultant said that the following ‘weak’ ciphers were supported by the server and should be disabled:
∙ TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
∙ TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
∙ TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
∙ TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
∙ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
∙ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
∙ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
∙ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028
We were very surprised to find that Auth0 continues to support these ‘weak’ ciphers.
Why do you continue to support these ciphers and is there any way for us to remove them?
NOTE: When using 3rd party tools, please remember that Auth0 is not in any way responsible for the validity of the results of any tests that you may choose to perform.
The issue of ‘weak’ cipher suites for public cloud is a source of legitimate concern. However, in practice, a balance needs to be struck between security and usability.
Using a completely ‘strong’ set of ciphers might well break things for a lot of customers and end-users. For example, users of legacy smartphones.
Unfortunately, there is no direct way to remove these ‘weak’ ciphers.
If this issue is of grave concern to you, then we offer the option of deploying Custom Domains in conjunction with self-managed certificates:
A custom domain, used in conjunction with self-managed certificates, will permit complete control over the termination of SSL/TLS connections and you will be able to implement your own preferred set of ciphers.
An alternative ( though more expensive) option would be to migrate to a Private cloud instance.
If you have any technical questions about either of the above options, then please create a Support ticket via the Support Center or post a question to our Community forum.