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?

kash_49328
Nimbostratus
Dec 17, 2014
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.
Joe_M
Nimbostratus
Mar 09, 2015
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.
Joe_M
Nimbostratus
Mar 10, 2015
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?
Chase_Abbott
Employee
Mar 10, 2015
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.
Joe_M
Nimbostratus
Mar 10, 2015
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
Joe_M
Nimbostratus
Mar 10, 2015
Not using DHE is what I will have to do if there isn't a way to specify 2048 or 4096 DH keys (like the example of the Linux box above). What we will lose (or in our case not get because we are upgrading from 10.2.4 and 11.3.0) is "Forward Secrecy" for slightly older clients that don't support ECDHE. They will have to rely on AES. And for the documentation about 1024 bit keys going from good to weak, that is located here on page 6 and the change record on page 8.

https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pdf
DavidScottNorto
Nimbostratus
Apr 30, 2015
We are a bit stuck on this one as well because we need to support some clients that don't have ECDHE abut we still want to maintain Forward Secrecy:(

Any one else with this need this be sure open a support ticket and give your business case for 435231 - RFE: LTM Support for higher-bit DH keys
Joe_M
Nimbostratus
May 07, 2015
I am on that RFE as well. But I was told the F5 is going away from DHE because it is too process intensive so this RFE is pretty low priority. :(
Joe_M
Nimbostratus
May 20, 2015
FYI, this was announced this morning. http://www.phoronix.com/scan.php?page=news_item&px=HTTPS-Logjam-Vulnerability&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Phoronix+%28Phoronix%29 I contacted my F5 Field engineer and he said F5 is on top of it and a SOL should be coming out soon. I hope that also means this RFE is going to get some traction.
bkhowson
Nimbostratus
May 20, 2015
This is an old topic, but is now a big deal due to "LogJam" guidance at:

https://weakdh.org/

Follow the link to "Guide to Deploying Diffie-Hellman for TLS" https://weakdh.org/sysadmin.html

"Good News! This site uses a unique or infrequently used 1024-bit Diffie-Hellman group. You are likely safe, but it's still a good idea to generate a unique, 2048-bit group for the site. "

The step by step guide does not cover F5 products...