Extreme Access Control (EAC) freeradius default cipher list

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
  • (Edited)
The default ciphers in freeradius on the EAC engine config for eap is:

cipher_list = "ADH-AES128-GCM-SHA256:ADH-AES128-SHA:ADH-AES128-SHA256:
ADH-AES256-GCM-SHA384:ADH-AES256-SHA:ADH-AES256-SHA256:ADH-CAMELLIA128-SHA:
ADH-CAMELLIA256-SHA:AECDH-AES128-SHA:AECDH-AES256-SHA:AES128-GCM-SHA256:
AES128-SHA:AES128-SHA256:AES256-GCM-SHA384:AES256-SHA:AES256-SHA256:
CAMELLIA128-SHA:CAMELLIA256-SHA:DHE-DSS-AES128-GCM-SHA256:
DHE-DSS-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:
DHE-DSS-AES256-SHA:DHE-DSS-AES256-SHA256:DHE-DSS-CAMELLIA128-SHA:
DHE-DSS-CAMELLIA256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA:
DHE-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA:
DHE-RSA-AES256-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:
ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA:
ECDH-ECDSA-AES128-SHA256:ECDH-ECDSA-AES256-GCM-SHA384:
ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES128-GCM-SHA256:
ECDH-RSA-AES128-SHA:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES256-GCM-SHA384:
ECDH-RSA-AES256-SHA:ECDH-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-SHA384:
PSK-AES128-CBC-SHA:PSK-AES256-CBC-SHA:SRP-AES-128-CBC-SHA:
SRP-AES-256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:
SRP-RSA-AES-128-CBC-SHA:SRP-RSA-AES-256-CBC-SHA"

It seems this config is generated with something like:

openssl ciphers HIGH | tr ':' '\n' | sort | grep -v RC4 | tr '\n' ':'
which is controled by application properties (default values):

RADIUS_TLS_CIPHER_LIST = "HIGH"
RADIUS_TLS_REMOVE_RC4_CIPHERS = true
So the list is sorted and the weak ciphers (128 < 256) gets in front. I don't know
how the EAC implementation uses this list, but the default openssl libs use
this list as an ordered list. So the weakest ciphers are used first.

Isn't this a security bug?
Photo of Patrick Koppen

Patrick Koppen

  • 770 Points 500 badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of Yacobucci, Ryan

Yacobucci, Ryan, Multi-Tier Technical Support Engineer

  • 5,734 Points 5k badge 2x thumb
Hello,

The ciphers list in the /opt/nac/radius/raddb/mods-enabled, to my knowledge, is a list of available ciphers that are negotiated by RADIUS server and client to be used to encrypt EAP-PEAP username and password information during a RADIUS transaction. While openssl  libs may use this list in an ordered fashion, the cihpers_list for freeRADIUS does not change the ciphers list for openssl. 

Do you have any information that indicates free RADIUS will always attempt to use the first cipher in the list when performing authentication? 

One side note is that removing the RC4 ciphers from this cipher list has caused some issues with customers as the clients were still attempting to used RC4 ciphers that were removed. If the RC4 ciphers were not in the list there had to be some other mechanism requiring the affected clients to attempt negotiation using RC4.

Thanks
-Ryan
Photo of Patrick Koppen

Patrick Koppen

  • 770 Points 500 badge 2x thumb
If you look at the freeradius source:

SSL_CTX_set_cipher_list(ctx, conf->cipher_list)
This funktion is part of the openssl library... so it might be a problem.

And for customers who need RC4 (I had this problem last week), they have to set
the list to "DEFAULT".

  https://extremeportal.force.com/ExtrArticleDetail?n=000012247

If you don't want to use RC4 but want to use the recommended list of ciphers
you have to set two options:

RADIUS_TLS_REMOVE_RC4_CIPHERS=false
RADIUS_TLS_CIPHER_LIST=HIGH
If you do not set any option, you get a sorted list of HIGH ciphers.
Photo of Ondrej Lepa

Ondrej Lepa, Employee

  • 6,038 Points 5k badge 2x thumb
Hi Patrick,

freeRADIUS seems to fully rely on openSSL to negotiate suitable cipher.
It is set in eap.conf and default string seems to go like this 
ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2
It may obviously differ based on intended server settings.
See more details in openSSL ciphers documentation

Anyway, it i the client who sets rules and cipher order seen on server side is quite irrelevant.
See page from openSSL s_server manual
-cipher cipherlist

this allows the cipher list used by the server to be modified. When the client sends a list of supported ciphers the first client cipher also included in the server list is used. Because the client specifies the preference order, the order of the server cipherlist irrelevant. See the ciphers command for more information.
There might be an exception related to server preferences, but this must be set within s_server SSL_CTX configuration
SSL_OP_CIPHER_SERVER_PREFERENCE

When choosing a cipher, use the server's preferences instead of the client preferences. When not set, the SSL server will always follow the clients preferences. When set, the SSLv3/TLSv1 server will choose following its own preferences. Because of the different protocol, for SSLv2 the server will send its list of preferences to the client and the client chooses.
You might give it a try with simple test - capturing authentication between client and server or try to find ssl.h and double check it is not used.

Let me know if you have any more questions.

Regards,
Ondrej
(Edited)
Photo of Patrick Koppen

Patrick Koppen

  • 770 Points 500 badge 2x thumb
Hi Ondrej,

during the TLS handshake the server sends his cipher list to the client and the client
this his to the server.

https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

The should agree on the stongest cipher. But if the client choses
the cipher (that itself would be a security risk), you have to check every implementation
of every client. If any of them uses this as a ordered list, your implementation is a
security bug.

You relying on:
  • implementation of freeradius
  • implementation of openssl
  • implementation of every client
So I think it's not good practise to use a wrong order in an ordered list. I'm not a
cryptographic expert but I still think this is a security bug in EMC/EAC.

Regards
Patrick
Photo of Patrick Koppen

Patrick Koppen

  • 770 Points 500 badge 2x thumb
Hi Ondrej,

if you look at the source code of freeradius (stable, not EOL):

if (conf->cipher_server_preference) {
/*
*      SSL_OP_CIPHER_SERVER_PREFERENCE to follow best practice
*      of nowday's TLS: do not allow poorly-selected ciphers from
*  *     client to take preference  
*/  
ctx_options |= SSL_OP_CIPHER_SERVER_PREFERENCE;
}
Regards,
Patrick
Photo of Ondrej Lepa

Ondrej Lepa, Employee

  • 6,038 Points 5k badge 2x thumb
Hi Patrick,

yes, in tls.c is written that CTX prefers server list.
Here is what openssl wiki says
So it is implementation dependent. In openssl there are two modes:
  • default is to choose the first compatible cipher suite from client hello.
  • SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order
If EAC uses server preferences you may only benefit from it. Today TLS severs usually relay on Eliptic Curves - GCM based ciphers and upon response to client server may use only specific cipher. See below



Could you share packet capture filtered with EAC IP to compare it?

If you do not like ciphers used by server, you might change the cipher list limiting weak ones. However, take in consideration wider support by older supplicants.

Regards,
Ondrej