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