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_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
So far I've come up with this string to reproduce the list: ECDHE+AES-GCM:DHE+AES-GCM:CHACHA20-POLY1305
Each time I test it the DHE+AES-GCM gets flagged because it is only 1024 bits. Removing it means removing a lot of clients from the compatibility list.
After days of reseach I can't find the place to increase my DH group strength. Only a 5 year old article which says that I can't increase it.
Does anyone know if it is possible to increase DH group strength in either 13.1.1 or 14.1.2, and where to do it?
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.
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.
My 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.
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.
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
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.
One of the reasons why someone might want to have DHE ciphers enabled is because BIG-IP does not support modern ciphers for DTLS with Edge Client/F5 Access client. When will BIG-IP support DTLS1.2 or 1.3 for VPN?
Not 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".
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.
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 it
This has be sort of looked at before, Try here Solved: Re: LTM Cipher rule - DevCentral (f5.com) There is some screen shots, and I've put links into some cypher suites a bit lower down. should hopefully allow you at amend you cypher suite on your ssl profile to make everything happy.
To try to help, in the past i've configured these in my cypher suite, i'm no expert in this at all but i think the ECDHE part at the begining is using EC for the key exchange of the DH and not RSA at 1024.
