[RADIATOR] Apple iOS 9 and OS X El Capitan

[Heikki Vatiainen]

On 07/24/2015 11:17 PM, David Zych wrote:

> TL;DR: check what version of Net::SSLeay your Radiator is using!

Thanks for sharing this David! A couple of comments from me:

First, I'll push additions to release notes. My TL;DR is: Net::SSLeay
1.46 + OpenSSL 1.0.1 are minimum requirements for fully controlling TLS
versions with EAPTLS_Protocols and TLS_Protocols.

For enabling or disabling TLSv1.1 and TLSv1.2, Net::SSLeay 1.46
2012-04-03 is required. Radiator uses constants
Net::SSLeay::OP_NO_TLSv1_1 and Net::SSLeay::OP_NO_TLSv1_2 which were
added to Net::SSLeay version 1.46

If your current Net::SSLeay does not support these, you will see these
messages when you set EAPTLS_Protocols (or TLS_Protcols) to use TLSv1.1
or TLSv1.2.

> Then Radiator 4.15 came out with an important vulnerability fix, and I 
> took advantage of its new configuration options to specify:
>    EAPTLS_Protocols TLSv1.2, TLSv1.1, TLSv1
>    EAPTLS_Ciphers DEFAULT:!EXPORT:!LOW:!RC4
> which caused it to emit the following log warnings:
> TLS_Protocols value TLSv1.2 not available. Ignoring.
> TLS_Protocols value TLSv1.1 not available. Ignoring.

The theory of operation in Radiator is to disable all SSL and TLS
versions and then clear the 'no' flags for the desired versions.

> These warnings led me to discover that the RHEL6-provided version of 
> perl-Net-SSLeay I had been using was positively ancient:
> $ perl -e 'use Net::SSLeay; print $Net::SSLeay::VERSION."\n"'
> 1.35
> so I installed the latest Net::SSLeay 1.70 from cpan and successfully 
> got rid of the warnings.

That should do it. RHEL6 comes with OpenSSL 1.0.1 so this combination
should give you full control over TLS versions.

With 1.35 (no options to control TLSv1.1 or TLSv1.2) the behaviour falls
back to what is available since Radiator 4.14: all TLS versions are
supported.

> What's even more surprising to me is that even with the older 
> Net::SSLeay, the RADIUS server would respond to the TLSv1.2 Client Hello 
> with a TLSv1.2 Server Hello (based on my other observations up to this 
> point, I would have expected to see the server negotiate TLSv1.0 
> instead).

Radiator 4.14 relaxed the strict requirement for TLSv1.0. See this
thread started by Nick:

http://www.open.com.au/pipermail/radiator/2014-November/020058.html

> The other half-baked hypothesis that occurs to me is that perhaps the 
> old Net::SSLeay somehow caused Radiator to end up sending the wrong 
> value in MS-MPPE-Recv-Key; if the AP had the wrong PMK, then it wouldn't 
> be able to validate the STA's portion of the 4-way handshake.  But how 
> would Radiator manage to successfully decode everything else well enough 
> to carry out the whole inner authentication, and only have problems with 
> that one value?

This might be the reason: if the MPPE keys are calculated incorrectly,
all looks fine but nothing works. This might be related to Nicks recent
message where changes were needed in FreeRADIUS MPPE key calculation
when TLSv1.2 was used.

I have not gone through Net::SSLeay release notes to see if there's
anything related to functionality related to MPPE key calculation. It
might be Radiator does not require changes because of Net::SSLeay
already provides them.

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.