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 <h...@open.com.au> wrote: > 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://www.open.com.au/radiator/history.html > >> 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. > > That's quite likely. I'm currently travelling so I don't have a good > opportunity to test this yet. What it looks like is that Net::SSLeay > 1.53 + OpenSSL 1.0.1 are the minimum requirement for TLSv1.2 support for > TLS based EAP methods. The former for correct MPPE key calculation and > the latter for TLSv1.2 (and TLSv1.1). > > I previously mentioned Net::SSLeay 1.46, but it seems to be missing > SSL_export_keying_material, altough it provides constants > Net::SSLeay::OP_NO_TLSv1_1 and Net::SSLeay::OP_NO_TLSv1_2 which allow > setting the desired TLS versions. > > Another thing to consider is the change introduced in Radiator 4.13 > patches: Radiator 4.13 + patches, 4.14 and 4.15 allow TLSv1.0, 1.1 and > 1.2 for TLS based EAP methods. Previously only TLSv1.0 was allowed. > > What Klara reported is one example where this can cause problems even > when EAPTLS_Protocols is not set: TLSv1.2 tunnel is successfully > negotiated but the MPPE keys are not calculated correctly because of an > old Net::SSLeay. The fix could be to upgrade Net::SSLeay or allow only > TLS 1.0 and 1.1. However, if Net::SSLeay is too old, for example > RHEL/CentOS 6, then the missing constants do not allow this and the only > option that remains is to upgrade Net:SSLeay. > > For the above reason this might be a good default: > - Revert back to TLSv1.0 by default (when EAPTLS_Protocols is not defined) > - When EAPTLS_Protocols is defined, check the Net::SSLeay version and > complain if it is older than 1.53 and OpenSSL version indicates that > TLSv1.1 and TLSv1.2 are not supported > > I'd say the above should not cause problems when TLSv1.2 (and 1.1) > clients become more widely used because the server would default to > choosing TLSv1.0. On the server side this has worked for ages and quite > likely the TLSv1.2 supporting clients do not refuse TLSv1.0 by default, > at least yet. > > When TLSv1.1 and TLSv1.2 server side support is required, it can be > turned on with EAPTLS_Protocols. If there are problems, the rollback can > be done by commenting out EAPTLS_Protocols and going back to TLSv1.0. > > Any comments on this? > > The above changes would probably mean a release to make the change > easier for everyone. The changes would go to patches first for those who > are interested in testing the new defaults and behaviour. > > Thanks for your comments, everyone! > Heikki > >> On Thu, Jul 30, 2015 at 6:49 PM, Christopher Bongaarts <c...@umn.edu> wrote: >>> 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. > > -- > Heikki Vatiainen <h...@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. > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
