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 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. 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. 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. Happy Friday! David _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
