Use Mozilla's intermediate cipher suites set by default.
Alan and Arran, Please may I suggest that you consider changing the default cipher suites configuration in FreeRADIUS 2.x and 3.x 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 FreeRADIUS in to compliance with the very likely upcoming: https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ Cheers, Nick
Nick Lowe wrote:
Alan and Arran,
Please may I suggest that you consider changing the default cipher suites configuration in FreeRADIUS 2.x and 3.x to use Mozilla's intermediate compatibility (default) set to encourage the use of better cipher suites that use ECDHE, GCM and PFS?
Except that also disables the PSK cipher suites, which we absolutely require. And we want to disable all SSLv3 cipher suites, because EAP uses TLSv1 or later. I am VERY wary of changing the list of cipher suites. I'd be happier with forbidding certain ones. Alan DeKok.
Oh, yes - it would need to be modified to support PSK suites! That intermediate set is for TLS 1.0 and later. The issue is the ordering of the cipher suites - OpenSSL does not have a sensible default here. Nick
On 18/11/14 16:03, Nick Lowe wrote:
Alan and Arran,
Please may I suggest that you consider changing the default cipher
Can I make a suggestion? Don't embed a suite list at all. Instead, comment the eap module with a link to a place, which should contain a *current* best-practice list. TLS is getting a lot of attention now. I think it's safe to assume one or more ciphers will become insecure, and any list you put into default configs, out of date. I realise giving no default leaves you dependent on OpenSSL, and that's not ideal - but solving the problem of stale OpenSSL defaults by introducing FreeRADIUS defaults which then go stale is not great. (Also, that enormous cipher list is eye-bleedingly bad; hard to read, therefore hard to audit and manage; damn you straight to hades, OpenSSL)
Phil, I agree with you to the extent that simply modifying the default configuration file to define a cipher_list would be a rather poor idea as it would stick around as best practices change. I think the right approach is to change the behaviour of FreeRADIUS so that it sets a sane cipher suites configuration where cipher_list isn't defined in eap.conf. As new releases of FreeRADIUS come out, this can be easily changed as becomes necessary as best practices change. Nick
On 18/11/14 17:10, Nick Lowe wrote:
Phil,
I agree with you to the extent that simply modifying the default configuration file to define a cipher_list would be a rather poor idea as it would stick around as best practices change.
I think the right approach is to change the behaviour of FreeRADIUS so that it sets a sane cipher suites configuration where cipher_list isn't defined in eap.conf.
That's even *worse* - you want to embed it in the source code! If you have to do either, embedding it in the default config files is least evil IMO.
Why in that worse or even bad? You're free to override it by defining a cipher_list... It avoids the issue of stale configuration. On Tue, Nov 18, 2014 at 5:21 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
That's even *worse* - you want to embed it in the source code! If you have to do either, embedding it in the default config files is least evil IMO.
In general I prefer dynamic over static. A source level default is static once the binary is compiled. A config level default is less so. So entirely subjective... ;o) -- Sent from my mobile device, please excuse brevity and typos
Phil Mayers wrote:
Can I make a suggestion? Don't embed a suite list at all. Instead, comment the eap module with a link to a place, which should contain a *current* best-practice list.
Asking people to read docs is a bit much...
TLS is getting a lot of attention now. I think it's safe to assume one or more ciphers will become insecure, and any list you put into default configs, out of date.
Well, we can update then. The default should be secure as of the date the server ships.
(Also, that enormous cipher list is eye-bleedingly bad; hard to read, therefore hard to audit and manage; damn you straight to hades, OpenSSL)
For many, many, reasons. Alan DeKok.
participants (3)
-
Alan DeKok -
Nick Lowe -
Phil Mayers