dh key too small

  • 4
  • Question
  • Updated 3 years ago
  • (Edited)
The latest security fixes on Ubuntu break the compatibility to WPA2 Enterprise with EAP Authentication.
They restricted dh keys shorter than 768 bit.
Our cert seems to be ok.

Has anyone an idea how to change the dh key length?

Regards,
Christian
Photo of Christian Wäschenfelder

Christian Wäschenfelder

  • 4 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 4
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
What RADIUS server are you using for EAP termination? The built-in one (presumably) or an external RADIUS server?
Photo of Christian Wäschenfelder

Christian Wäschenfelder

  • 4 Posts
  • 0 Reply Likes
I'm using the build in radius server.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I suggest that you consider deploying NPS or FreeRADIUS yourself on one-or-more servers to workaround this until a fixed HiveOS version becomes available from Aerohive.

It likely won't be practical to configure the clients to not offer DHE-based cipher suites in the TLS Client Hello that is sent by the supplicant, your only workaround from a client perspective if you continue to use the built-in RADIUS server.

I really ought to sit down and establish which cipher suites are available through HiveOS via its RADIUS server for the TLS-based EAP types that it implements/offers to see what needs changing/correcting.

HiveOS should actually only be offering ECDHE and RSA based cipher suites and not DHE. DHE is slow and all modern clients offer ECDHE, legacy clients can use RSA.

Other improvements are needed regardless in HiveOS like TLS 1.2 support for EAP.
(The cipher suites offered should match what a best-practice configured Web server does for HTTPS.)
(Edited)
Photo of Christian Wäschenfelder

Christian Wäschenfelder

  • 4 Posts
  • 0 Reply Likes
Just tested it with an external radius server, it works perfectly.
Unfortunately I have multiple locations where it will be too expensive to put separate radius server in place.
I think I'll maybe have to hold back the security update till there's a fixed version of the HiveOS.

But thank you for your fast help.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
HiveOS 6.6r1 is due very soon now, it has been mentioned to me that weak DHE is a known issue to Aerohive so it may contain a fix.

It is clearly something that ought to be backported where necessary for the older models of AP that cannot run the latest feature branch of HiveOS.
(Edited)
Photo of Christian Wäschenfelder

Christian Wäschenfelder

  • 4 Posts
  • 0 Reply Likes
Ok, I hope they'll fix it with that version.
Photo of shoremedia

shoremedia

  • 22 Posts
  • 4 Reply Likes
I checked out the HiveOS and HiveManager 6.6r1 Release Notes, and no mention of fix for weak DHE...can anyone comment on release date to address this issue?

I'm hoping that aerohive RADIUS server weak keys issue is the cause of beta version of OSX 10.11 and beta of iOS 9 to fail if the RADIUS server, (in this case, aerohive as RADIUS) allows negotiation with a 512-bit or smaller group.  Same setup in non beta OSX 10.10 works perfectly with aerohive as RADIUS.  Rolling back to OSX 10.10 and iOS 8 corrects failing authentication issue, but that is not viable solution.

Per OSX 10.11 release notes: "When negotiating a TLS/SSL connection with Diffie-Hellman key exchange, OS X El Capitan requires a 1024-bit group or larger. OS X El Capitan will not connect to a server that allows negotiation with a 512-bit or smaller group."  Enterprise Wi-Fi (802.1X) is included in the list of server types.

I confirmed on an external RADIUS server works as expected with same certs (1024-bit), yet aerohive 6.6r1 still appears to break authentication with beta OSX 10.11 and beta of iOS 9. 
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
so Aerohive, when can we expect an update?! How hard is it to generate a new key for the RADIUS server and publish and update?
snippet from:
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
    • The openssl dhparam tool generates 2048-bit DH parameters by default. [OpenSSL 1.0.2 (all releases), OpenSSL 1.0.1n (next release)]. You can use an earlier version of the tool to generate secure parameters as well - just make sure to specify the bitlength explicitly:
$ openssl dhparam -out dh_2048.pem 2048
If you absolutely must continue to use a 1024-bit group (e.g., for compatibility with older clients - JDK 7-based clients are known to reject groups larger than 1024 bits), avoid the defaults built into your server software and make sure to generate fresh, custom parameters instead.

Please update the firmware with the option to have at least 1024 and 2048 bit for the keylength.
Thank you
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The better solution is to remove all DH based cipher suites actually rather than increasing the key size.
(Edited)
Photo of Joshua Wright

Joshua Wright

  • 1 Post
  • 0 Reply Likes
How and where do you do this? 
(Edited)
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Joshua,
You don't. We have done that in new HiveOS images which will be announced shortly.
Photo of shoremedia

shoremedia

  • 22 Posts
  • 4 Reply Likes
ChromeOS Stable (v45) 802.1X authentication is now broken if your environment uses Aerohive AP as RADIUS.

The latest ChromeOS stable build (v45) enforces extra requirements on the ephemeral Diffie-Hellman keys which servers provide. In practice, some wireless certificates will be rejected, kicking back a confusing "authentication certificate rejected locally" error on a ChromeOS device when trying to connect to certain enterprise or university 802.1X wireless networks utilizing Aerohive as RADIUS.

http://blog.chromium.org/2015/07/chrome-45-beta-new-es2015-features.html
  • The logjam attack is fixed in this release by deprecating the use of keys smaller than 1024 bits in Diffie-Hellman key exchanges, which may require developers to update their server’s TLS configuration.
As in my reply above, I confirmed that an external RADIUS server still works as expected with same certificates (even as low/weak as 1024-bit)...but that is not ideal if you have deployed Aerohive as RADIUS at present.  It seems until Aerohive corrects issue, those on ChromeOS latest stable release may need to reconfigure your infrastructure to NOT use Aerohive AP as RADIUS function.
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
You cannot replace DH with RSA: DH and RSA are not the same. DH is a key exchange algorithm, RSA an encryption/signing algorithm.
So that does not make sense.
As usual, there is no flow in the Diffie-Helman symmetric key algorithm, there is a flaw in the implementation as you can read about here: https://weakdh.org/ .

How do you know they are working on it? It should be a minor change and selling them selves as Enterprise and easy is not really being lived up to if you ask me.
Let's hope those new firmwares will be released soon and that they are quicker next time. Non acceptable from a security point of view.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2480 Posts
  • 447 Reply Likes
RSA encapsulates both functions. It is also a form of key exchange:

https://www.openssl.org/docs/manmaster/apps/ciphers.html
kRSA, aRSA, RSA
cipher suites using RSA key exchange, authentication or either respectively.
What I said is accurate therefore and your statement about RSA is not correct.

I stated that it is better to replace DH-based cipher suites with ECDH-based cipher suites at this juncture. They inherently do not have this key size issue, have better performance characteristics and also offer forward secrecy.

RSA-based cipher suites are then offered to be used in legacy fallback for older clients. They do not offer forward secrecy.

The reason to not offer DH-based cipher suites going forward is that there are significant performance implications doing so with larger key sizes, these especially impact embedded devices, such as APs. It can be an easy DoS vector. ECDH is the better route.

I understand that the issue is being worked on as I have been told this.
(Edited)
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
You talked about cipher suites, that is where my comment is based upon, nice you read up on it.
If I understand correctly what you mean, what you propose will require devices to handle the key exchange differently, and that will not be backwards compatible, right?
That would require all those devices to be able to do that.
ECDH is still DH, right?

Do you have any leverage in Aerohive communicating that there is an increasing numbner of users not being able to connect to Aerohive access points?
Would be great if this gets pushed a bit, 4 months for a security patch seems way too long to me.

Thank you.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2480 Posts
  • 447 Reply Likes
It is a variant of DH but fundamentally different enough that it is not at all affected by this issue. There's no need to go in to the details here.

This change fully backwards compatible without compatibility implications. Modern supplicants already offer and put ECDHE-based cipher suites ahead in the Client Hello, ahead of any DH-based and RSA-based cipher suites.

Older clients have RSA based cipher suites available which they can sue without forward secrecy.

You just need an intersection of supported cipher suites between the EAP client and the EAP server.

This is actually an area that I have a lot of experience. I haven't just casually read up on it ;)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2480 Posts
  • 447 Reply Likes
It is a variant of DH but fundamentally different enough that it is not at all affected by this issue. There's no need to go in to the details here.

This change fully backwards compatible without compatibility implications. Modern supplicants already offer and put ECDHE-based cipher suites ahead in the Client Hello, ahead of any DH-based and RSA-based cipher suites.

Older clients have RSA based cipher suites available which they can sue without forward secrecy.

You just need an intersection of supported cipher suites between the EAP client and the EAP server.

This is actually an area that I have a lot of experience. I haven't just casually read up on it ;)
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Folks,
I have been monitoring this thread and apologize to you all for not jumping in sooner.

Aerohive is aware of this issue and has been taking steps to address it. The fixes have not been quite as trivial as some have surmised; we have to coordinate changes across the entire product line. 

We are on track to release, at or before the end of this month (September 2015), a number of patch releases of HiveOS specifically to address this issue. 
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
Thank you for responding Mike, looking forward to the releases. 
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Nick, openminded (love that handle, btw),
Because these will be patch releases (e.g. 6.6r1b not 6.6r2, 6.4r1g not 6.4r2, etc) we are trying to minimize the changes and effectively are just removing the weak ciphers at this time.

We ARE laying the foundation for further improvements in security such as adoption of TLS 1.2, increased key lengths and improved ciphers, but those changes will all be realized in a future feature release. 
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Removing the DH-based cipher suites completely is the better move than increasing the key length for DH so that's a good thing.

It would be awesome to see ECDHE-based cipher suites make it in rather than just RSA-based with TLS 1.2 in the future.

(I understand that the next version of Android is now negotiating TLS 1.2 now too for EAP.)

All of the changes should be easy and low impact conceptually, but I understand the nervousness from a QA and support to make changes where there's a perception there could be a compatibility or reliability bite.

I do personally think such concerns are overblown and not substantiated though.
(Edited)
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
Thank you Mike. I was hoping for TLS 1.2 and Nick's suggestion sounds good also, having less overhead with increasing key length.
It would be great to set the key length, in case OpenSSL decides to further extend it :).
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
*I was editing my post to state that I'm a 'do it now, get it done' kind of guy which does colour my opinion on this type of thing, I'm certainly not conservative from a making changes perspective! :P

Mike, of course I'd be happy to discuss stuff 'offline' re: use of TLS if that'd be helpful?
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I'm expecting people to have noticed this issue with iOS 9 and HiveOS:

Set a strong group size for Diffie-Hellman key exchange
If your service uses Diffie-Hellman key exchange, set the group size to a minimum of 1024 bits. A group size of 2048 bits or greater is recommended.
If your app or service doesn't meet this requirement, devices that use iOS 9 or OS X El Capitan might not connect to it
https://support.apple.com/en-us/HT205020
(Edited)
Photo of E. Saludes

E. Saludes

  • 3 Posts
  • 0 Reply Likes
Hello all, I know this isn't strictly an Aerohive question but here it is. If I want to force my ChromeOS / chromebook to accept a "weak cert" is there anyway, assuming I'm willing to take all risk and "root" it. I really need this WiFi for school and can't wait for them to fix it. 
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
This isn't a weak X.509 certificate issue. It's a cipher suites issue.
Nope, you cannot control the cipher suites in the Client Hello to my knowledge.
The fix for this can only come from Aerohive if you wish to continue using the built-in RADIUS server. An alternative is to deploy a third-party RADIUS server that is not affected such as NPS or recent versions of FreeRADIUS.
(Edited)
Photo of E. Saludes

E. Saludes

  • 3 Posts
  • 0 Reply Likes
I have no choice in the matter at all as I am just a student and not IT (I happen to be an IT student). So you suspect the "certificate rejected locally" error when attempting to connect via PEAP /MSCHAP is a ciper suites issue? Thanks by the way, I appreciate your help. My school help desk is of no help.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Sorry, I meant that the issue under discussion in this thread is not a weak X.509 certificate issue. I did not realise you were a student so answered in the presumed context of you being an administrator of an Aerohive network. Just checking, does your school use Aerohive APs?

In the generic sense, yes, there are definitely other certificate issues that cause 802.1X supplicants to trip up. This issue under discussion here is something new to add to the mix of potential causes. If your problem has only recently started and other clients do not experience issues, it could easily be weak DH related, which would be then nothing to do with the certificate.

(That said, all iOS 9 clients will be unable to associate where this problem exists and they are widespread now. If other users can associate with iOS 9 clients, it is not weak DH.)

The common known issues for non-expired X.509 certificates are documented here if you wish to check for anything:

https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations

(Scroll towards the bottom.)

Google deliberately do not allow easy overrides for this type of thing for good reason. It usually requires administrative intervention, sorry!
(Edited)
Photo of E. Saludes

E. Saludes

  • 3 Posts
  • 0 Reply Likes
Thanks, Nick. I will go to the college today and ask if anyone is running iOS9, then about their WiFi connectivity, that would narrow it down to a weak DH key. I will also attempt to enable logging and post that up for everybody. Google forums would definitely lock this type of discussion, as all "certificate rejected locally" threads I see are locked because "it's enterprise". What is really bugging me now is that I swear earlier in my research I saw someone post how to force chromeOS to accept weaker cyphers (and in general manipulate what it accepted), it required you do the "root thing" as you would to install Linux (non ChromeOS linux that is). I'm backed up on HW so I can't dedicate as much time to this as i might like. I will say that amazon reviews for chromebooks lately include quite a few one star "doesn't work with my school wifi" reviews so I imagine I am not alone in this problem.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Awesome news! A software update to correct this is available now:

HiveOS 6.1 Branch
AP110/120/170/320/340, BR100
Fixed Version: 6.1r6f

HiveOS 6.4r1 Branch
AP121/141/230/330/350/1130, BR200/200-WP/200-LTE-VZ, CVG (aka HiveOS VA, aka VPN Gateway), 
SR2024/2024P/2124P/2148P
Fixed Version: 6.4r1g

HiveOS 6.6r1 Branch
AP130/230/330/350/1130, BR200/200-WP/200-LTE-VZ, CVG (aka HiveOS VA, aka VPN Gateway), SR2024/2024P/2124P/2148P
Fixed Version: 6.6r1b

Hurrah!

Nick
(Edited)
Photo of openminded

openminded

  • 6 Posts
  • 0 Reply Likes
About time :)