The other thing that I want to say...
It would be far better to deal with any problems if-and-when they
arise based on technical realities rather than defaulting to the
conservative position of TLS 1.0 by default.
If something does arise that requires not offering TLS 1.2 by default,
then fair en
Right now, just Apple. If I take TLSv1 out of the EAPTLS_Protocols line
and watch logs, every attempt results in an "access reject" except for a
small handful of Apple devices.
-Christopher
On 7/31/15, 10:31 AM, "Heikki Vatiainen" wrote:
>On 07/31/2015 05:04 PM, Howard, Christopher wrote:
>
Safe but, in my opinion, fundamentally rather unhelpful as it keeps
people on a deprecated version of the TLS protocol by default. I don't
think it's the right choice on balance.
Instead of failing to start if you feel that is too severe, you are
still able to limit to TLS 1.0 only.
< 1.46, force
On 07/31/2015 05:04 PM, Howard, Christopher wrote:
> We're running CentOS 6 here and fixed the TLSv1.2 issue with these new
> OSes. You're correct that using yum to install Net::SSLeay will result in
> not being able to use newer versions of TLS.
Thanks for confirming this.
> However, I've alwa
On 07/31/2015 05:16 PM, Nick Lowe wrote:
> Isn't $Net::SSLeay::VERSION available, from which you could refuse to
> start Radiator if Net:SSLeay <= 1.46 is detected and you can't disable
> TLS 1.2?
Yes, that's the key for figuring out what should work. The OpenSSL
library version is also available
$ perl -MNet::SSLeay -e 'print "$Net::SSLeay::VERSION\n"'
1.70
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Sorry, < 1.46 not <= ...
So the logic would be:
< 1.46, bail and fail to start Radiator going forward
< 1.53, always disable TLS 1.2 going forward
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Isn't $Net::SSLeay::VERSION available, from which you could refuse to
start Radiator if Net:SSLeay <= 1.46 is detected and you can't disable
TLS 1.2?
On Fri, Jul 31, 2015 at 2:57 PM, Heikki Vatiainen wrote:
> On 07/31/2015 12:11 PM, Nick Lowe wrote:
>> Surely, the best solution is to check for th
We're running CentOS 6 here and fixed the TLSv1.2 issue with these new
OSes. You're correct that using yum to install Net::SSLeay will result in
not being able to use newer versions of TLS.
However, I've always used the CPAN shell to build and install perl
modules. Doing this works perfectly fin
On 07/31/2015 12:11 PM, Nick Lowe wrote:
> Surely, the best solution is to check for the availability of the
> SSL_export_keying_material. If it is not available, disable TLS 1.2.
This is certainly the best solution, provided Net::SSLeay version is at
least 1.46. This is the first version that all
Surely, the best solution is to check for the availability of the
SSL_export_keying_material. If it is not available, disable TLS 1.2.
I definitely do not think that it is a great idea to disable support
for TLS 1.2 by default.
Regards,
Nick
On Thu, Jul 30, 2015 at 9:12 PM, Heikki Vatiainen wr
On 07/30/2015 08:57 PM, Nick Lowe wrote:
> Agreed: "Added support for SSL_export_keying_material where present
> (ie in OpenSSL 1.0.1 and later)."
Support for this Net::SSLeay function was added in Radiator 4.11
patches. In other words, Radiator 4.12 and later will use it if it's
available.
https
Hi,
> Not tested, but I suspect that we will find that 1.53 is the version
> at which this starts to work and, if so, it should become the minimum
> version that should be used.
based on other changes etc I would say just go for the current latest
release - 1.70 - why opt for something older? (e
Agreed: "Added support for SSL_export_keying_material where present
(ie in OpenSSL 1.0.1 and later)."
Not tested, but I suspect that we will find that 1.53 is the version
at which this starts to work and, if so, it should become the minimum
version that should be used.
Regards,
Nick
On Thu, Jul
On 7/30/2015 12:43 PM, Nick Lowe wrote:
> 1.46 doesn't work.
Quickly looking through the release notes, 1.53 has a change that seems
relevant.
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota
1.46 doesn't work.
Nick
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
On 7/24/2015 3:17 PM, David Zych wrote:
> 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
Agreed, but it would be good to use all sensible means available to
communicate this - it is not one or the other, there's no mutual
exclusivity.
I just feel that it would be useful to try and step in to prevent this
from becoming a problem when iOS 9 and OS X El Capitan come out of
beta and ship.
Hi,
> I definitely agree with your suggestion. Now that we all know that
> this is an issue, we can take steps to raise awareness and inform. For
> Eduroam in particular, I feel that notices should be put out to
> participating institutions.
actually, as a specific vendor problem, I would hope th
Hi David,
I definitely agree with your suggestion. Now that we all know that
this is an issue, we can take steps to raise awareness and inform. For
Eduroam in particular, I feel that notices should be put out to
participating institutions.
I replied to Heikki before, forgetting to copy to the lis
On 07/26/2015 04:06 AM, Heikki Vatiainen wrote:
> On 07/25/2015 04:28 PM, Nick Lowe wrote:
>
>> Well, just as a point of related interest, FreeRADIUS had an issue
>> where the MPPE key was incorrectly calculated for TLS 1.2:
>>
>> https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bb
Hi David,
On Fri, Jul 24, 2015 at 03:17:50PM -0500, David Zych wrote:
> 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 authentic
Also, iOS 9 is available for public beta testing.
If you have a device that you can test with, you can sign up for
immediate access here:
https://beta.apple.com/sp/betaprogram/
Nick
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/
The supplicant in Windows 7 and newer support TLS 1.2 for the
TLS-based EAP types offered such as EAP-PEAP if the machine is fully
patched via Windows Update.
TLS 1.1 and 1.2 are disabled by default but can be enabled for you to test with.
See the second More Information section of:
https://supp
On 07/25/2015 04:28 PM, Nick Lowe wrote:
> Well, just as a point of related interest, FreeRADIUS had an issue
> where the MPPE key was incorrectly calculated for TLS 1.2:
>
> https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bbd6e9079be4b11f0adc27fa994416
>
> FreeRADIUS 2.2.6 and
On 07/25/2015 03:22 PM, a.l.m.bu...@lboro.ac.uk wrote:
> the heartbleed fix requires something like 1.69 (now i really
> hope that RedHat have at least backported the fixes to their old version!!!)
I agree the using recent Net::SSLeay version is a good idea. In addition
to what you wrote, for exa
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
Hmm...
Well, just as a point of related interest, FreeRADIUS had an issue
where the MPPE key was incorrectly calculated for TLS 1.2:
https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bbd6e9079be4b11f0adc27fa994416
FreeRADIUS 2.2.6 and 3.0.7 don't work with iOS 9 unless TLS 1.2 is
Hi,
> 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 wa
29 matches
Mail list logo
