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.
Tim_M
Nimbostratus
NimbostratusNot sure if you're aware of this, but there's a third-party scanning system out there called Bitsight that is giving out security scores. And it's flagging this issue like so:
Diffie-Hellman prime is less than 2048 bits
Now, since we host a lot of other apps through the F5, this will be a problem for our score. And obviously there are people who care a lot about this number because you know, it's a number and low is bad and high is good. So, web engineers and other ops people are going to be told, "make this number higher".
FredSelIt's exactly what I'm facing right now.
Bitsight has flagged it and I've been told to find a solution....I guess the only option is to accept the risk
So what is your current configuration?
It me worth raising a case with support or possibly a different post and we can try to assist you in updating your config.this post is quite old so where might be ways to solve this now.
- FredSel
We use the DEFAULT cipher suite for our ssl profiles, and some are flagged by BitSight while others not.
Is it possible that the BIGIP doesn't use the same suite from one profile to another one?
I can open a new post if you think that's worth itThanks
