[RADIATOR] Apple iOS 9 and OS X El Capitan
dmrz at illinois.edu
Fri Jul 24 15:17:50 CDT 2015
In case anyone else out there is in the same boat...
Last week, we noticed that Apple devices running the beta releases of El
Capitan and iOS 9 were unable to connect to our WPA2 Enterprise
networks, which authenticate against Radiator running on Red Hat
Enterprise Linux 6.6.
TL;DR: check what version of Net::SSLeay your Radiator is using!
According to the station logs from our wireless infrastructure, our test
iOS 9 client was able to successfully make it all the way through the
authentication stage of 802.11i (producing a RADIUS Access-Accept which
was received by the wireless controller); the failure occurred after
that, during the four-way handshake to construct the PTK. At this
point, I reasoned, the RADIUS server is no longer involved in the
process, which led us to believe that the problem resided elsewhere
(i.e. with either Apple or our wireless vendor).
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
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.
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"'
so I installed the latest Net::SSLeay 1.70 from cpan and successfully
got rid of the warnings.
After I deployed these changes to production, we were pleasantly
astonished to discover that El Capitan and iOS 9 clients were suddenly
able to connect with no problems!
Subsequent re-testing in my lab environment shows that what made the
difference was not Radiator 4.15 or my config changes (which only work
with Radiator 4.15), but Net::SSLeay.
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). Furthermore, side by side comparisons of the unencrypted
portions of traffic captures from the RADIUS server show no obvious
differences in the ensuing conversation depending on which Net::SSLeay
is installed; both appear to be TLSv1.2 throughout, both select the same
cipher suite, and even the lengths of the (opaque to my Wireshark)
Encrypted Application Data in each packet after that match up perfectly.
It's obvious from the reproducible empirical success vs failure that the
RADIUS server as a whole must be doing _something_ different in the two
cases, but for the life of me I can't see what it is... and if something
went wrong in setting up the TLS tunnel, then I would expect iOS 9 to
bail out immediately rather than continuing to authenticate over a
tunnel it didn't like.
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?
If anyone more knowledgeable than I has any insights to share, I remain
ever-curious about what exactly was going wrong earlier, but my main
goal in posting this is to share the solution that I discovered purely
by accident (upgrade Net::SSLeay) with anybody else who might be tearing
their hair out over the same problem.
More information about the radiator