For backward compatibility reasons if the 3DES (TLS_RSA_WITH_3DES_EDE_CBC_SHA) cipher needs to be enabled in a web server, is there any compensating security control that can be used to detect and mitigate Sweet32-Birthday attacks on 3DES? Does a WAF help in this situation? Consider the web-application is running on containers behind a cloud load balancer.
One example is, Google has 3DES cipher enabled for https://www.google.com, in this scenario how they are continuing 3DES cipher support while maintaining defense against Sweet32-Birthday attacks.
Thank you for your help.
The endpoint google.com does have TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled. Is this a problem? Usually no, given that at least 32 Gigabytes of data from the same SSL/TLS session needs to be captured. In some real world reports, over 700 Gigabytes needs to be captured.
For a website delivering HTML pages, it is very unlikely that a single HTTPS connection will transfer that much data. However, breaking that one single session does not help with the next connection as the attack would have to start again.
is there any compensating security control that can be used to detect and mitigate Sweet32-Birthday attacks on 3DES?
I am not aware of any method to detect that someone has broken the encryption. There is no feedback loop that reports a successful attack.
Does a WAF help in this situation?
I am not aware of WAFs checking for encryption protocols. WAFs look for higher layer attacks.
Consider the web-application is running on containers behind a cloud load balancer.
Google HTTP(S) Load Balancers support SSL policies. Create a policy of TLS 1.0 with a Modern Profile or better and TLS_RSA_WITH_3DES_EDE_CBC_SHA and other weaker features will be disabled.
how they are continuing 3DES cipher support while maintaining defense against Sweet32-Birthday attacks.
I cannot answer. Given the large amount of data that needs to be captured, most companies do not worry about this specific birthday attack. When evaluating the strength and weakness of a security implementation there are tradeoffs. The cost of better security versus the value of the data being protected. If the value is low, more costly forms of security might not be required. In Google's case, I think this is more of an opportunity decision to ensure that google.com is widely available to all clients.