Forum Discussion
Heinrichm5
Altocumulus
AltocumulusIncrease DH key exchange to 2048
I'm trying to move from cipher lists in the ssl profile to cipher rules and groups in order to support TLS1.3 I would like to only enable strong cipher suites. So far I've found this list TLS_EC...
The answer is no - there is still no mechanism to increase DH group strength on the BigIP.
The BigIP does not support Diffie Hellman keys greater than 1024 bits in any current version at present:
One reason is computational efficiency - the move to 2048-bit keys is 5 times the mathematical processing of 1024-bit keys (80% reduction in DHE SSL throughput). ECDHE is much more computationally efficient, and is not exposed in the same way DHE is.
Older browsers such as IE6 and Java clients do not support 2048-bit DH parameters.
The TLS protocol prior to TLSv1.3 does not provide any method for negotiating the DH parameter-length to ensure compatibility. Initial drafts of TLS1.3 did not even include DHE ciphers, which was added in at a late stage.
Modern versions of Chrome, Safari, and Firefox do not support DHE by default.
The cipher preference of these browsers includes only the ECC version (ECDHE) for Perfect Forward Secrecy (PFS) support.
Modern versions of Internet Explorer (IE9 through IE11) do support DHE, but in a lower preference than ECDHE. The net result is that any SSL/TLS server (including BIG-IP) would negotiate to ECDHE, since the browser's highest preference will dictate the cipher.
In addition, the BigIP auto rotate the prime numbers that are used to generate the Ephemeral keys (hourly), and does not use a common group of primes. You can also enable "Single DH use" as a Client SSL profile option. This means that the proposed WeakDH attack on 1024-bit primes is not considered feasible for LTM DHE 1024-bit keys.
I hope this answers your questions - F5 does not support 2048-bit DHE keys, as there has been no compelling reason to make the change - ECDHE ciphers are stronger and have wider support in the browser market, and DHE ciphers are likely to be de-emphasised as HTTP/2 and faster TLSv1.3 ciphers become supported. Additionally, the risks of exposure for 1024-bit DHE were based in a common set of primes and non-changing ephemeral keys that were never used on the BigIP.
Simon_Blakely
Employee
EmployeeThe answer is no - there is still no mechanism to increase DH group strength on the BigIP.
The BigIP does not support Diffie Hellman keys greater than 1024 bits in any current version at present:
One reason is computational efficiency - the move to 2048-bit keys is 5 times the mathematical processing of 1024-bit keys (80% reduction in DHE SSL throughput). ECDHE is much more computationally efficient, and is not exposed in the same way DHE is.
Older browsers such as IE6 and Java clients do not support 2048-bit DH parameters.
The TLS protocol prior to TLSv1.3 does not provide any method for negotiating the DH parameter-length to ensure compatibility. Initial drafts of TLS1.3 did not even include DHE ciphers, which was added in at a late stage.
Modern versions of Chrome, Safari, and Firefox do not support DHE by default.
The cipher preference of these browsers includes only the ECC version (ECDHE) for Perfect Forward Secrecy (PFS) support.
Modern versions of Internet Explorer (IE9 through IE11) do support DHE, but in a lower preference than ECDHE. The net result is that any SSL/TLS server (including BIG-IP) would negotiate to ECDHE, since the browser's highest preference will dictate the cipher.
In addition, the BigIP auto rotate the prime numbers that are used to generate the Ephemeral keys (hourly), and does not use a common group of primes. You can also enable "Single DH use" as a Client SSL profile option. This means that the proposed WeakDH attack on 1024-bit primes is not considered feasible for LTM DHE 1024-bit keys.
I hope this answers your questions - F5 does not support 2048-bit DHE keys, as there has been no compelling reason to make the change - ECDHE ciphers are stronger and have wider support in the browser market, and DHE ciphers are likely to be de-emphasised as HTTP/2 and faster TLSv1.3 ciphers become supported. Additionally, the risks of exposure for 1024-bit DHE were based in a common set of primes and non-changing ephemeral keys that were never used on the BigIP.
Heinrichm5Altocumulus
AltocumulusMy issue is that if I only enable these, then my compatibility list goes way down. So either I increase DH or select weaker cipher suites like include CBC. So to me it would be quite compelling.
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA25
That is beside the point. I'm grateful for your thorough and speedy answer. Thank you very much for the explanation.
- Simon_Blakely
No worries, and I get the point about the constraint on ciphers.
From our perspective, the 1024-bit DHE issue is more nuanced than the blanket approach that SSLLabs takes, for example.
And I know that there are some embedded clients in the wild that do not support ECDHE and cannot be upgraded to support Elliptic Curve ciphers.
Use SSL testing ratings as a guide, but you have to make a decision based on what you are supporting - just have a strong justification for your decision.
- Heinrichm5
I agree that it is necessary to have a nuanced approach, I'd just seen these as good and liked they provided excellent rating as well as compatibility
You seem to have a good grasp on this. Would you recommend enabling TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with an ECDH key exchange instead of those I'm experiencing issues with? I don't understand enough to know which is better
- strong cipher with weak key exchange
- weaker cipher suite with strong key exchange
By the rating I'm assuming option 2. But I'd like your opinion
- Simon_Blakely
I'd certainly not recommend CBC ciphers at all - there are weaknesses in CBC ciphers that mean that they should not be used at all.
I'd trust to the (apparently weak but not weak in reality) Key Exchange of DHE (on a BigIP) and a strong bulk cipher as opposed to CBC bulk ciphers that have a number of possible exploits.