[RADIATOR] TLS 1.1 and TLS 1.2 Support in Radiator
Dear all, A quick question: Does Radiator support TLS 1.1 and TLS 1.2 with the TLS-based EAP types that it implements when paired with a feature-capable version of OpenSSL? The FreeRADIUS maintainers found that the code was calling TLSv1_method() rather than the very poorly named SSLv23_method(), inadvertently prohibiting the use of the newer TLS versions. When SSLv23_method() is called, SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 are specified to prohibit the use of these old protocols. This is documented at https://www.openssl.org/docs/ssl/SSL_CTX_new.html The upcoming FreeRADIUS 2.2.6 and 3.0.5 releases will allow TLS 1.1 and TLS 1.2 to be used by EAP clients, and by default: https://github.com/FreeRADIUS/freeradius-server/commit/d56fb1b5fa81ec25fddb9216ce1cf46eb2d99de9 2.x: https://github.com/FreeRADIUS/freeradius-server/commit/7d6344df30097df946010b2eac011cb9a480bec8 3.x: https://github.com/FreeRADIUS/freeradius-server/commit/d9a285ca285148a2fb122b18f73ab0cbffbc12f0 Microsoft also now support TLS 1.1 and TLS 1.2 with their TLS-based EAP implementations when configured through a TlsVersion bit flags-based DWORD in the Registry. [This covers Network Policy Server (NPS) therefore...] See "More Information" towards the end of https://support.microsoft.com/kb/2977292 As somebody who is not yet familiar with Radiator, I am therefore curious what the state of play is. Thanks! Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TLS 1.1 and TLS 1.2 Support in Radiator
Thanks! For info: The documentation for Microsoft's hotfix, which was pushed out automatically with Windows Update, is incomplete as it lumps together the Server and Client SCHANNEL SP_PROT flags for the TLS protocol versions. These bit flags are better documented for the SCHANNEL_CRED structure's grbitEnabledProtocols field and are defined in schannel.h See http://msdn.microsoft.com/en-gb/library/windows/desktop/aa379810.aspx > Here's one additional document: Microsoft's own documentation for PEAP. > It seems they still say only TLS 1.0 must be used. Good catch! I will make contact and suggest that they fix the specification. Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Use Mozilla's intermediate cipher suites set by default.
Please may I suggest that you consider changing the default cipher suites configuration in Radiator 4.14 for TLS to use Mozilla's intermediate compatibility (default) set to encourage the use of better cipher suites that use ECDHE, GCM and PFS? See https://wiki.mozilla.org/Security/Server_Side_TLS This is: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA This is fully compatible all the way back to Windows XP where 3DES will be used. It also brings Radiator in to compliance with the very likely upcoming: https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ Cheers, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Use Mozilla's intermediate cipher suites set by default.
This needs to be modified to allow PSK cipher suites though, as Alan pointed out to me! Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.15 released - security fixes and enhancements
RC4 is particularly broken now: https://www.rc4nomore.com https://www.rc4nomore.com/vanhoef-usenix2015.pdf In conjunction with https://tools.ietf.org/html/rfc7465 , it is probably time for RADIUS servers to comply with this by default unless explicitly configured otherwise: "o TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message. o If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case." ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 disabled server side. Any users of 2.2.6 and 3.0.7 should consider upgrading if they're using TLS-based EAP types. This affects Eduroam etc. (FreeRADIUS 2.2.7 and 3.0.8, and later work without issue.) Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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://support.microsoft.com/en-us/kb/2977292 The configuration of the TlsVersion DWORD in the registry is actually more granular than the KB article lets on as you actually get control of both the client and server version behaviour, it is not lumped together. The values map to the SP_PROT flags defined in schannel.h, documented online as part of the SCHANNEL_CRED structure under grbitEnabledProtocols. http://msdn.microsoft.com/en-gb/library/windows/desktop/aa379810.aspx SP_PROT_TLS1_SERVER 0x0040 SP_PROT_TLS1_CLIENT 0x0080 SP_PROT_TLS1_1_SERVER 0x0100 SP_PROT_TLS1_1_CLIENT 0x0200 SP_PROT_TLS1_2_SERVER 0x0400 SP_PROT_TLS1_2_CLIENT 0x0800 Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan (radiator Digest, Vol 74, Issue 10)
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 list, saying: "This was actually discovered with wpa_supplicant not via iOS 9 or El Capitan. Odds are therefore, all you will need to do here is to ensure that an old version of Net::SSLeay is not being use with Radiator so that Radiator users don't hang themselves here and document and warn better on the issue." Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan (radiator Digest, Vol 74, Issue 10)
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. Many people will install the free upgrades from Apple and all hell could break loose where clients cannot connect against certain home institutions. Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
1.46 doesn't work. Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 30, 2015 at 6:49 PM, Christopher Bongaarts 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. > > > -- > %% Christopher A. Bongaarts %% c...@umn.edu %% > %% OIT - Identity Management %% http://umn.edu/~cab %% > %% University of Minnesota%% +1 (612) 625-1809%% > ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 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 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 > > 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
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 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 allows disabling TLS 1.2 (and > TLS 1.1). > > The OpenSSL API allows creating SSL_CTX for one TLS/SSL version only, or > for all supported versions which means the undesired versions need to be > disabled separately. This is why Net:SSLeay 1.46 or more recent would be > needed. > > http://www.openssl.org/docs/ssl/SSL_CTX_new.html > >> I definitely do not think that it is a great idea to disable support >> for TLS 1.2 by default. > > We'll check what can be done. Unfortunately it looks like RHEL/CentOS 6 > won't work with TLS 1.2 out of the box because of the old Net:SSLeay. > Fortunately it appears that for more recent Net::SSLeay and OpenSSL > combinations TLS 1.1 and 1.2 can be left enabled. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > 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
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
$ 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
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 TLS 1.0 going forward < 1.53, always disable TLS 1.2 going forward Else... TLS 1.2 will be enabled by default. Thoughts? Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Apple iOS 9 and OS X El Capitan
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 enough - but we really have not seen anything to justify that position yet IMO. Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Password/certificate security seems next to none on Radiator server
If you wanted robust protection here, you would likely want to go down the route of a TPM or equivalent. Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Password/certificate security seems next to none on Radiator server
Nadav, You're just obfuscating by doing this as the RADIUS server still have to get access to those things. Security through obscurity really doesn't exist. It is a complete waste of time in my opinion. You have to reply on encryption of the backing storage and OS security primitives with administrative best practice to do this properly. There is no other way. Once somebody owns a box, all bets are off. Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Password/certificate security seems next to none on Radiator server
Hi Nadav, You're wrong. Please educate yourself about what a security boundary is. Kind regards, Nick On Tue, Oct 6, 2015 at 12:06 PM, Nadav Hod wrote: > Hi, > > The password doesn't need to be in plaintext in the configuration, it can > simply use an alias system so that if I send the argument "router123" then > router123's password will be copied to memory securely, where it can then be > used. Same goes for any passphrases for accessing certificate stores. This is > how kpcli works, you supply string1 and you get back password1. > > I think there is merit in changing the existing configuration files from > using "router123,mypassword" to something like GetPassword(%UserName). It > seems more secure to me and not because of obfuscation but because the > interface with Radiator itself is more secure. It also doesn't expose > credentials nearly as much as the status quo. At no point in any of the > configuration files and databases should credentials be left in unguarded > cleartext, it's just not technical limitation these days. > > I'm unsure why there isn't any interest from anyone in this mailing list > other than myself to secure these credentials. Let's look at other solutions. > I heard a suggestion to use TPM, but that's hardware-specific and also > depends on how the encryption software supports its use. > > Would using Microsoft EFS on the Radiator folder (which contains all NAS > credentials) and limiting access be a stronger solution than using an > encrypted database? Would this cause a noticeable performance hit for an SMB? > > > From: Christian Kratzer [ck-li...@cksoft.de] > Sent: Saturday, October 03, 2015 4:06 PM > To: Nadav Hod > Cc: Tuure Vartiainen; radiator@open.com.au > Subject: Re: [RADIATOR] Password/certificate security seems next to none > on Radiator server > > Hi, > > On Fri, 2 Oct 2015, Nadav Hod wrote: >> Hi Tuure, >> >> Moving the secrets from one cleartext file to another isn't secure, it's >> just a way to break the code between more files. > > you still clearly do not understand that there is no way to solve this in > software. > > Not in radiator or in any other software. > > Radiator or any other radius server needs to keep in plaintext: > - credentials it needs to connect to backend databases > - possible certificate private keys or passphrases to unlock those when needed > - radius secrets > - ... > >> I'm interested in a secure way to access credentials which are kept both >> encrypted and only accessed when authenticated by a keyfile or something >> equally strong. > > If credentials are kept encrypted and are decrypted on demand that is equally > just obfuscation. > > You asked for it and were shown a way how to accomplish this but rejected it. > >> As far as I can tell this doesn't exist today in Radiator, I'm asking this >> members in this mailing list whether or not they think there is added value >> in implementing some form of sustainable security for these credentials. > > Radiator is following best practices already. > > Greetings > Christian > > > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > ___ > 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
Re: [RADIATOR] Password/certificate security seems next to none on Radiator server
> Would using Microsoft EFS on the Radiator folder (which contains all NAS > credentials) and limiting access be a stronger solution than using an > encrypted database? Using the primitives and security boundaries provided by the underlying platform/OS is the only correct solution. Attempting to implement it in Radiator would be a fools errand. It is impossible to achieve your stated goal at that level, all you can possibly achieve is obfuscation, which isn't security at all. Regards, Nick ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
