Forum Discussion

Heinrichm5's avatar
Icon for Altocumulus rankAltocumulus
Nov 27, 2019

Increase 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...
  • Simon_Blakely's avatar
    Nov 27, 2019

    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.