FreeRadius2 Diffie-Hellman 2048 bit iOS9 OSX 10.11

posto587

Hi,
the upcoming iOS9 and OSX 10.11 (El Capitan) update will affect the radius authentication. The Clients (chrome OS also) won't accept Diffie-Hellman keys smaller than 2048 bit with TLS v1.2. FreeRadius supports it from version 2.2.7, the actual version of the pfsense-package is 2.2.6.

Regards

Edit: Apple info - https://support.apple.com/en-us/HT205020

Nachtfalke

Hi,

I would suggest to contact one of the moderators/developers of pfsense so that they can create the new PBI files for freeradius based on the actual version 2.2.8.
I sent you this suggestion via PM but just want to document it here again ;)

http://svnweb.freebsd.org/ports/head/net/freeradius2/

Good luck!

posto587

iOS9 is now availiable, OSX 10.11 on 9/30

johnpoz

I am using eap-tls with freeradius on pfsense 2.2.4 and I updated both my wifes phone and my ipad last night.. And I was connected to my eap-tls network this morning I am almost positive. It might have switched over.. But looking right now I still show it connected to the eap-tls network..

Pretty sure it defaults when you create to 2048, so that should be fine should it not?

All for an update to current, but don't think its going to break anything.

I show my wifes phone connecting this morning
Sep 17 08:53:47 radiusd[49125]: Login OK: [k-iphone] (from client uap-ac-lr port 0 cli 80-00-6E-9D-EA-DE) k-iphone

In the log and was updated to ios 9 last night.

posto587

Thats interesting, the problem with the D-H Key seems to be an miscalculation of MPPE keys of the RADIUS server:

https://community.aerohive.com/aerohive/topics/802-1x-compatibility-issue-with-freeradius-and-radiator-with-forthcoming-ios-9-and-os-x-el-capitan

But in the bugfixes of freeradius this miscalculation is just named in 3.0.8: http://freeradius.org/press/index.html#3.0.8

johnpoz

yeah so now have 3 devices on ios 9, my work iphone 5s, my ipad and my wifes iphone 5c

All using eap-tls without any issues.
Sep 18 20:04:32 radiusd[49125]: Login OK: [j-iphone] (from client uap-ac-lr port 0 cli AC-FD-EC-62-34-97) j-iphone
Sep 18 19:58:51 radiusd[49125]: Login OK: [j-iphone] (from client uapac port 0 cli AC-FD-EC-62-34-97) j-iphone

Here I clearly moved from one AP in the hall to the AP in the kitchen.. If there is anything you would like me to test, just let me know..

sisko212

Seems also newer Android MarshMallow 6 has same trouble with Freeradius and tls auth:

https://code.google.com/p/android/issues/detail?id=188867#c29

nick.lowe

The miscalculated MPPE keys with TLS 1.2 issue has nothing to do with weak DH.

The best solution for weak DH is to configure your cipher_list directive in FreeRADIUS to one of the following two.

Where there is a desire to only support modern clients:

"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+AES+SHA384:EECDH+aRSA+AES+SHA384:EECDH+ECDSA+AES+SHA256:EECDH+aRSA+AES+SHA256:EECDH+ECDSA+AES+SHA1:EECDH+aRSA+AES+SHA1:RSA+AES+SHA256:RSA+AES+SHA1"

We can verify what this gives us via:

openssl ciphers -v "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+AES+SHA384:EECDH+aRSA+AES+SHA384:EECDH+ECDSA+AES+SHA256:EECDH+aRSA+AES+SHA256:EECDH+ECDSA+AES+SHA1:EECDH+aRSA+AES+SHA1:RSA+AES+SHA256:RSA+AES+SHA1"

And where there is a want/need for 3DES for compatibility for legacy clients (such as Windows XP), append RSA+3DES+SHA1 to the end of that string.

This gives:

"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+AES+SHA384:EECDH+aRSA+AES+SHA384:EECDH+ECDSA+AES+SHA256:EECDH+aRSA+AES+SHA256:EECDH+ECDSA+AES+SHA1:EECDH+aRSA+AES+SHA1:RSA+AES+SHA256:RSA+AES+SHA1:RSA+3DES+SHA1"

Again, the resultant set of cipher suites can be seen via:

openssl ciphers -v "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+AES+SHA384:EECDH+aRSA+AES+SHA384:EECDH+ECDSA+AES+SHA256:EECDH+aRSA+AES+SHA256:EECDH+ECDSA+AES+SHA1:EECDH+aRSA+AES+SHA1:RSA+AES+SHA256:RSA+AES+SHA1:RSA+3DES+SHA1"