Hello, during a recent analysis comparing security options provided by Apache httpd and F5 LTM we discovered that while Apache for RHEL/CentOS has lifted a limitation of 1024 bits for ephemeral keys in Diffie-Hellman exchange in version 2.2.15-32.el6 (EL6 is the version we're using at the moment, so let's stick to that; newest available package for EL6 is 2.2.15-39.el6) and now bases the length of ephemeral keys upon the server private key (2048 bits, as per current industry standard). On the other hand, F5 LTM v. 11.6.0 still uses the keys that are 1024 bits long in DH Exchange. Is there a possibility to control this behaviour that I'm not aware of? If not, what is the potential impact of this parameter? Are there any plans for changes in this respect? Additional reference: Bug report related to Apache httpd in RHEL6 https://bugzilla.redhat.com/show_bug.cgi?id=1071883 NIST SP 800-131A http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf Thanks for any information, W.Urbańczyk

As per security standpoint DH keys are impossible to break unless its a man in the middle attack so it does not matter what group you using. In addition to that it will create an overhead as you increase the size. I would say 1024 bits are enough.

I am running into the same issue. If DHE keys are impossible to break why does SSL Labs mark it as weak? and isn't the new setting "SSL Sign Hash" in the clientssl profile supposed to affect that? When I change that setting, it makes no difference. However, maybe that is only for ECDHE: "Specifies the hash algorithm the BIG-IP system uses for server key exchanges with Elliptic Curve ciphers. Possible choices are SHA1, SHA256, SHA384, or Any. When you select Any, you authorize the system to choose any one of the hash algorithms. Note that in this case, the BIG-IP system chooses SHA1 whenever possible. The SSL Sign Hash setting was introduced in BIG-IP 11.5.0." Regardless of whether or not DHE keys are impossible to break, PCI still views 1024 as weak and therefore shouldn't/can't be used by us. I may have to open up a ticket with F5, if no one has any other sugestions.

It is possible, I might be getting confused. But for clarification, the cert and key pair is signed with SHA2. What I am getting at is this, below are 2 snippets taken from SSL Labs reports. The first from our F5 indicating that the 1024 bit DH key is weak. 2nd is from the report of a linux box with the same ciphers using strong keys. F5 VIP: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK256 Linux box: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 4096 bits (p: 512, g: 1, Ys: 512) FS256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits (p: 512, g: 1, Ys: 512) FS256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits (p: 512, g: 1, Ys: 512) FS256 So how do I get the F5 to not use 1024?

11.6 will have a reduced set of lower level ciphers in the default config but any existing config is still supported. BigIP supports different levels because it has to account for many different configurations, like the COMPAT cipher list. Check out SOL8802 for a good list of 11.x based SSL articles, but you'll specifically want to read SOL13171 to configure only strong ciphers if that's the need. I can only assume that your VIP is using a an SSL profile that allows these lower level strings for negotiation fall back. But really review the SOL8802 and that will give you not only the possible ciphers that you'll want to support, but also how to configure the profile to use ONLY TLS 1.2 approved cipher strengths.

I am quite familiar with all of those documents. That is precisely how I have put together my cipher string. Here it is, nothing weak is in there. ECDHE:AES-GCM+RSA:DHE:AES+RSA:!DTLSv1:!RC4:!3DES:!SSLv3:!LOW:@STRENGTH:+TLSv1_1:+TLSv1 This has NOTHING to do with the cipher itself! It has to do with (from what I can tell) the Diffe-Hellman parameters that don't appear to be configurable on the F5. https://wiki.openssl.org/index.php/Diffie-Hellman_parameters

DHE key exchange: why is ephemeral key only 1024bit long?

21 Replies

Joe_M
Nimbostratus
May 26, 2015
I contacted F5 support to have this RFE pushed and this is the unfortunate response I got back.

I wanted to update you that I have heard back regarding your request and it was unfortunately denied. The recommendation they provided is completely disabling DHE, and using ECDHE instead. Also, I reviewed the links that you sent me and we actually have official documentation regarding logjam now that went up on Sunday. You can review that information at the link below.

https://support.f5.com/kb/en-us/solutions/public/16000/600/sol16674.html
DavidScottNorto
Nimbostratus
May 26, 2015
Very unfortunate that F5 doesn't seem to understand the impacts of not supporting legacy clients:( Why do they think I can drop 15% of my traffic? It looks like that means we will need to switch to L4 load balancing for many of our sites so we can use Apache function which is working.

That just leaves me with a dilemma of should I continue to spend so much money on F5 if all I can do is layer 4? Guess I will need to think more about my hardware refresh. Anybody looking at different gear that might solve the problem?
- JRahm
  Admin
  May 28, 2015
  Hi David, is an iRule possible in your environment? You can use one to loop through the ciphers offered by the client and then select another profile for them, but the business logic for which non-supported clients you would actually still want to connect would still need to be developed.
DavidScottNort1
Nimbostratus
May 26, 2015
Very unfortunate that F5 doesn't seem to understand the impacts of not supporting legacy clients:( Why do they think I can drop 15% of my traffic? It looks like that means we will need to switch to L4 load balancing for many of our sites so we can use Apache function which is working.

That just leaves me with a dilemma of should I continue to spend so much money on F5 if all I can do is layer 4? Guess I will need to think more about my hardware refresh. Anybody looking at different gear that might solve the problem?
- JRahm
  Admin
  May 28, 2015
  Hi David, is an iRule possible in your environment? You can use one to loop through the ciphers offered by the client and then select another profile for them, but the business logic for which non-supported clients you would actually still want to connect would still need to be developed.
Joe_M
Nimbostratus
May 27, 2015
FYI, this was written up a few days ago for logjam. https://devcentral.f5.com/articles/remediating-logjam-an-irule-countermeasure
JG
Cumulonimbus
May 28, 2015
There was this argument about the benefits of off-loading SSL operations to the hardware (ASIC) of F5. If ECDHE is too much even for F5 to handle, imagine the situation of the boxes the Apache httpd runs on. :-)

But I suspect F5 is probably worried about the existing older F5 hardware....

The SSL/TLS has really shaken up the industry in the past year and a lot of things stop working sooner...
Chase_Abbott
Employee
May 28, 2015
David's point is older clients will not support ECDH, not that the F5 gear wouldn't be able to handle it I think. In that case, iRules do have the ability to do a client detect so you can use ECDH on appropriate incoming requests and drop others to a different SSL profile or some other function.

We support compact and other legacy ciphers for this reason but the issue is, once enabled, your application stops complying with whatever new issue arises against TLS. This is that double-edge sword... with the iRule though, we could detect regular traffic and comply with any "scan" and proper ITIL documentation could detail the caveats for legacy clients that don't support the new ciphers. These always boil down to business decisions on what is supportable.

But yes, if enabling ECDH is too much for a hardware appliance with SSL Hardware acceleration, the Apache box would most likely be toast.
BAMcHenry
Ret. Employee
Jul 07, 2015
Here's a bit more detail on why supporting DHE parameter lengths greater than 1024 is a non-trivial development effort, and ultimately doesn't return the value in security, given the alternatives: https://devcentral.f5.com/articles/logjams-dhe-parameters-and-other-obstacles-to-tls-excellence

Bear in mind that older clients not supporting DHE 2048 should support ECDHE as a PFS alternative of quality strength.
sogboj_312474
Nimbostratus
Feb 21, 2019
Hello, is this still the case with later versions such as 13.x and beyond? That is, that you cannot increase the bit size of the DH key for the built-in ciphers?
- Kin
  Employee
  Jun 15, 2022
  Please refer to the latest update on this. K79342815: BIG-IP support for RFC7919 Negotiated Finite Field Diffie-Hellman Ephemeral (FFDHE)

Forum Discussion

DHE key exchange: why is ephemeral key only 1024bit long?

21 Replies

Recent Discussions

What happens if I only enable ASM in BIG-IP Under System > Resource Provisioning

What is the meaning is 52% block in WAF

Rundeck ansible F5 errors

rewrite Azure AD response for portal access via web portal

AS3 Monitoring multiple ports selectively

Related Content

Exchange 2016

MS Exchange ProxyNotShell block implemented via iRules

Exchange 2019

WILS: Load Balancing and Ephemeral Port Exhaustion

Change FQDN in ephemeral nodes