Fwd: RADSEC / TLS errors but not sure why
Hi All, I'm currently testing out RADSEC/TLS on the latest version, 3.2.3, with openssl 3.0 on Ubuntu 22.04. The key, certificate and CA are correct and have been validated to match before using in the Freeradius config. When I start the daemon there are no errors indicating the key/cert don't match so I assume all is well. However, when a client connects over RADSEC/TLS (port 2083), Freeradius displays an SSL error. I've also tried the openssl s_client command and the same error is thrown. openssl s_client -showcerts -connect radius.hostname:2083 The key/cert is secp384r1 based. mods-enabled/eap: --------------------------- tls-config tls-common { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 1024 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no ecdh_curve = "secp384r1" } --------------------------- sites-enabled/tls: --------------------------- listen { ipaddr = * port = 2083 type = auth+acct proto = tcp virtual_server = default clients = radsec limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } tls { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.key ca_file = ${certdir}/my_key.key dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no require_client_cert = no } } clients radsec { client all { ipaddr = 0.0.0.0/0 proto = tls secret = radsec } } home_server tls { ipaddr = 127.0.0.1 port = 2083 type = auth secret = radsec proto = tcp status_check = none tls { private_key_password = whatever private_key_file = ${certdir}/purple.key certificate_file = ${certdir}/purple.crt ca_file = ${certdir}/purple.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" } } home_server_pool tls { type = fail-over home_server = tls } realm tls { auth_pool = tls } --------------------------- radius debug: [snip] Listening on auth+acct proto tcp address * port 2083 (TLS) bound to server default Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on proxy address * port 40253 Ready to process requests ... new connection request on TCP socket Listening on auth+acct from client (1.2.3.4, 38639) -> (*, 2083, virtual-server=default) Waking up in 0.9 seconds. (0) (TLS) Initiating new session (0) (TLS) Handshake state - before/accept initialization (0) (TLS) Handshake state - Server before/accept initialization (0) (TLS) recv TLS 1.2 Handshake, ClientHello (0) (TLS) send TLS 1.2 Alert, fatal handshake_failure (0) ERROR: (TLS) Alert write:fatal:handshake failure (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (0) ERROR: (TLS) System call (I/O) error (-1) (0) (TLS) Failed in TLS handshake receive (TLS) Closing socket from client port 38639 If I query a public radsec radius server on port 2083 using the openssl s_client command it returns the certificate list correctly etc. Is it a problem with my key/cert, openssl, or the client? Thanks
Hi All, I'm currently testing out RADSEC/TLS on the latest version, 3.2.3, with openssl 3.0 on Ubuntu 22.04. The key, certificate and CA are correct and have been validated to match before using in the Freeradius config. When I start the daemon there are no errors indicating the key/cert don't match so I assume all is well. However, when a client connects over RADSEC/TLS (port 2083), Freeradius displays an SSL error. I've also tried the openssl s_client command and the same error is thrown. openssl s_client -showcerts -connect radius.hostname:2083 The key/cert is secp384r1 based. mods-enabled/eap: --------------------------- tls-config tls-common { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 1024 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no ecdh_curve = "secp384r1" } --------------------------- sites-enabled/tls: --------------------------- listen { ipaddr = * port = 2083 type = auth+acct proto = tcp virtual_server = default clients = radsec limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } tls { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no require_client_cert = no } } clients radsec { client all { ipaddr = 0.0.0.0/0 proto = tls secret = radsec } } home_server tls { ipaddr = 127.0.0.1 port = 2083 type = auth secret = radsec proto = tcp status_check = none tls { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" } } home_server_pool tls { type = fail-over home_server = tls } realm tls { auth_pool = tls } --------------------------- radius debug: [snip] Listening on auth+acct proto tcp address * port 2083 (TLS) bound to server default Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on proxy address * port 40253 Ready to process requests ... new connection request on TCP socket Listening on auth+acct from client (1.2.3.4, 38639) -> (*, 2083, virtual-server=default) Waking up in 0.9 seconds. (0) (TLS) Initiating new session (0) (TLS) Handshake state - before/accept initialization (0) (TLS) Handshake state - Server before/accept initialization (0) (TLS) recv TLS 1.2 Handshake, ClientHello (0) (TLS) send TLS 1.2 Alert, fatal handshake_failure (0) ERROR: (TLS) Alert write:fatal:handshake failure (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (0) ERROR: (TLS) System call (I/O) error (-1) (0) (TLS) Failed in TLS handshake receive (TLS) Closing socket from client port 38639 If I query a public radsec radius server on port 2083 using the openssl s_client command it returns the certificate list correctly etc. Is it a problem with my key/cert, openssl, or the client? Thanks
On Aug 7, 2023, at 8:19 AM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
When I start the daemon there are no errors indicating the key/cert don't match so I assume all is well.
TLS also requires agreement from the other end.
(0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
Either your system is configured with a restrictive list of ciphers, OR the other end is configured with a restrictive list of ciphers. i.e. Maybe one end says "I only do DES", and the other "I only do AES". At that point they can't agree in a shared encryption method, and they can't talk. Since the openssl client is showing the same error, the issue is likely the server. Go back to the default configuration, and don't use exotic certificates. Use the test certificates in raddb/certs. It will work. Then, replace pieces of the configuration and certs one by one (and test them) until it stops working. The thing you just changed is what's breaking it. Alan DeKok.
Thanks. So when I use a basic certificate, it works, and using the openssl show cert command from an external machine it returns the certificates. I've also just tried using this SSL cert with radsecproxy instead of FreeRADIUS, on the same server, and it also errors when I run the openssl show cert command. So yes, it must be related to the specific SSL certificate I am trying to use. I will go through a few more checks. For reference, this is a publicly issued certificate from the WBA for OpenRoaming client/server use. So it's not my own certificate, however I do have the private key/CSR of course. I have verified the key/cert/ca matches. Thanks
On Aug 7, 2023, at 11:26 AM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks. So when I use a basic certificate, it works, and using the openssl show cert command from an external machine it returns the certificates.
That's good.
I've also just tried using this SSL cert with radsecproxy instead of FreeRADIUS, on the same server, and it also errors when I run the openssl show cert command.
Because radsecproxy uses OpenSSL for all of the TLS / certificate stuff.
So yes, it must be related to the specific SSL certificate I am trying to use. I will go through a few more checks.
For reference, this is a publicly issued certificate from the WBA for OpenRoaming client/server use. So it's not my own certificate, however I do have the private key/CSR of course. I have verified the key/cert/ca matches.
OpenRoaming definitely uses FreeRADIUS and OpenSSL. So it definitely is possible to get it to work. The only question is what magic string has to go into the "cipher_list". See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for a list of what strings are allowed in the "cipher_list" configuration item. But be aware that you need to update *both* the client and server. If the server supports EC certificates, then it's likely also automatically support the relevant cipher suites which use those EC certificates. Which means you likely need to update the *client* configuration to allow the ECDH cipher suites. And yes, use "wireshark" to see the list of cipher suites which each side supports. Alan DeKok.
The thing is, I am using the same Openroaming issued certificate as other RADSEC providers. If I query a public RADSEC server, from the same client (that doesn't have any Openroaming specific or CA certs installed), it's fine: openssl s_client -showcerts -connect radsec1a.eu1.odyssys.net:2083 CONNECTED(00000003) depth=3 C = US, ST = California, L = San Jose, O = "Cisco Systems, Inc.", OU = Openroaming, CN = openroaming.org, emailAddress = enb-devops@cisco.com verify error:num=19:self signed certificate in certificate chain verify return:1 depth=3 C = US, ST = California, L = San Jose, O = "Cisco Systems, Inc.", OU = Openroaming, CN = openroaming.org, emailAddress = enb-devops@cisco.com verify return:1 depth=2 C = SG, ST = Singapore, L = Singapore, O = Wireless Broadband Alliance, OU = WBA, CN = openroaming.org, dnQualifier = WBA WRIX ECC Policy Intermediate CA-01 verify return:1 depth=1 C = US, O = "Kyrio, Inc.", OU = WBA, CN = openroaming.org, dnQualifier = WBA WRIX ECC Intermediate CA-2 verify return:1 depth=0 C = GB, O = Global Reach Technology EMEA Limited, OU = WBA:WRIX End-Entity, CN = radsec1a.eu1.odyssys.net, UID = GlobalReach:GB verify return:1 Server certificate subject=C = GB, O = Global Reach Technology EMEA Limited, OU = WBA:WRIX End-Entity, CN = radsec1a.eu1.odyssys.net, UID = GlobalReach:GB issuer=C = US, O = "Kyrio, Inc.", OU = WBA, CN = openroaming.org, dnQualifier = WBA WRIX ECC Intermediate CA-2 --- Acceptable client certificate CA names C = US, ST = California, L = San Jose, O = "Cisco Systems, Inc.", OU = Openroaming, CN = openroaming.org, emailAddress = enb-devops@cisco.com Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 5255 bytes and written 436 bytes Verification error: self signed certificate in certificate chain --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 19 (self signed certificate in certificate chain) --- But when querying my server using the same CA issued certificate: CONNECTED(00000003) 140245345748288:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1555:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 227 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1691356240 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no ---
On Aug 7, 2023, at 12:18 PM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The thing is, I am using the same Openroaming issued certificate as other RADSEC providers.
That doesn't matter. I've suggested multiple times what you can do to help track down the issue.
But when querying my server using the same CA issued certificate:
CONNECTED(00000003) 140245345748288:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1555:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent
Which is a different error. And therefore unrelated to the original "no shared cipher suite" message. You're trying to fix the problem by trying random things. And, by looking at unrelated systems with different configurations. a) ask one of the other systems how they configured FreeRADIUS, and then do the same thing yourself. b) follow the suggestions given here for tracking the problem down. Pick one. There is no option: c) ignore all of the advice on the list, and instead try a bunch of random other things Alan DeKok.
The error isn't different. I just didn't include the client side error in my original post. To confirm: Client shows: CONNECTED(00000003) 140245345748288:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1555:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 227 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1691356240 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Server shows: (0) (TLS) Initiating new session (0) (TLS) Handshake state - before/accept initialization (0) (TLS) Handshake state - Server before/accept initialization (0) (TLS) recv TLS 1.2 Handshake, ClientHello (0) (TLS) send TLS 1.2 Alert, fatal handshake_failure (0) ERROR: (TLS) Alert write:fatal:handshake failure (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (0) ERROR: (TLS) System call (I/O) error (-1) (0) (TLS) Failed in TLS handshake receive (TLS) Closing socket from client port 38639 Alas, I'm moving on to the suggested advice on how to debug. I've captured the traffic from both the client and server side, and can see it's clearly failing on the Client Hello. The client is sending 31 ciphers, all of which are also available on the server side. I don't know why the server isn't selecting a cipher and allowing the handshake. The server supports all of these, it's an out the box openssl build. TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA Are you suggesting that something is misconfigured which means they can't agree on a cipher? Thanks
On Aug 7, 2023, at 1:38 PM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
The error isn't different. I just didn't include the client side error in my original post. To confirm:
OK.
(0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
That's pretty definitive.
The client is sending 31 ciphers, all of which are also available on the server side. I don't know why the server isn't selecting a cipher and allowing the handshake.
OpenSSL negotiation isn't trivial.
The server supports all of these, it's an out the box openssl build.
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-25 6-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA
Does *OpenSSL* support this, or have you configured the server to support this? Those are two different questions. You can configure the server to support a restricted set of ciphers, which is a subset of the above list. Sometimes this is as easy as using a particular kind of certificate. For example, if you have an EC cert, then none of the RSA cipher methods listed above will work. If you disable SHA256, then all of the SHA256 methods won't work.
Are you suggesting that something is misconfigured which means they can't agree on a cipher?
Yes. Somehow the server is using a subset of the above list. And that subset has no overlap with what the client is sending. If I had to guess, the client only supports RSA methods, and the server is using an EC certificate. So there's no overlap, and nothing happens. But without more information, it's impossible to know. Alan DeKok.
I too initially assumed it was the client that was the problem, but because I can call another public server, with the same signed certificate (just a different CN/Alt names - all Openroaming issued certs are the same CA etc) as I'm trying to use, and the client successfully negotiates SHA384, with a peer signature type of ECDSA, using TLSv1.3 and cipher TLS_AES_256_GCM_SHA384, then I can't see how the client is the problem. I seem to be able to use openssl s_client against any TLS host and get a valid response, just not my host. I am not restricting (that I'm aware of) anything in the openssl config on the host so it should be able to use TLS_AES_256_GCM_SHA384, which is inside the Client Hello packet capture. Running "openssl ciphers" on the server provided that supported list in the previous message. I'll look more into the server side of things now. Do you have any pointers as to what could be restricting the available ciphers on the server? Thanks
On Aug 7, 2023, at 3:37 PM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I too initially assumed it was the client that was the problem, but because I can call another public server, with the same signed certificate (just a different CN/Alt names - all Openroaming issued certs are the same CA etc) as I'm trying to use, and the client successfully negotiates SHA384, with a peer signature type of ECDSA, using TLSv1.3 and cipher TLS_AES_256_GCM_SHA384, then I can't see how the client is the problem. I seem to be able to use openssl s_client against any TLS host and get a valid response, just not my host.
I've tried repeatedly to explain, so I'm not sure what isn't getting across. It's NEGOTIATION. That means BOTH SIDES HAVE TO AGREE ON THE CIPHERS. Depending on what happens, you may have to change the configuration of the client, or of the server. Since your messages go back and forth on what's happening, my response may seem to give different advice. But don't take a reply to one message as meaning that my other replies are wrong.
I am not restricting (that I'm aware of) anything in the openssl config on the host so it should be able to use TLS_AES_256_GCM_SHA384, which is inside the Client Hello packet capture.
Running "openssl ciphers" on the server provided that supported list in the previous message.
<sigh> I suggest reading my messages. The fact that the OPENSSL LIBRARIES SUPPORT A PARTICULAR SET OF CIPHERS does not mean that FREERADIUS WILL SUPPORT THE SAME SET OF CIPHERS I gave a long explanation in my previous message, including examples. What is very much unhelpful is replying with the same comment of "But I ran openssl ciphers". I don't care. It's irrelevant. Or may only *slightly* relevant. It's frustrating to see my explanations ignored, and the same replies repeated. So yes... I did see your message about "openssl ciphers". I replied to it, and explained why it didn't matter. Are you going to pay attention to the reply?
I'll look more into the server side of things now. Do you have any pointers as to what could be restricting the available ciphers on the server?
There are "configuration files" shipped with FreeRADIUS. Which includes "comments" and "documentation" on how, and what, to configured. The only thing which is clear here is that: * the default (i.e. likely RSA) certificates work * the EC cert doesn't work So.... see my previous message for comments on EC versus RSA ciphers. Alan DeKok.
I've tried repeatedly to explain, so I'm not sure what isn't getting across. It's NEGOTIATION. That means BOTH SIDES HAVE TO AGREE ON THE CIPHERS.
I know, and understand. I am reading your replies, and they are most helpful. I am asking follow up questions because although everything you are saying makes sense, I haven't been able to get it working. I am using an out the box freeradius 3.2.3 config with modified tls and eap sections as per my original post. I thought you said openssl handles all the TLS comms, therefore apart from setting the path to my certs, what else can I do in freeradius config to help? Therefore the comments and documentation don't help me solve this because I've not set anything that would cause this. I am using an out the box ubuntu installation and openssl library with no cipher restrictions set either side. When I start a server using: ------ openssl s_server -key /usr/local/etc/raddb/certs/my_key.key -cert /usr/local/etc/raddb/certs/my_key.crt -chainCAfile /usr/local/etc/raddb/certs/my_key.ca -accept 2083 -www ------ the same client can successfully establish a connection, but that fails when the freeradius daemon is running using the same key/cert/ca This is why I am bouncing messages back and forth, not because I'm questioning your advice. Please don't take it that I'm not listening.
On Aug 7, 2023, at 4:17 PM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I know, and understand. I am reading your replies, and they are most helpful. I am asking follow up questions because although everything you are saying makes sense, I haven't been able to get it working.
That is clear. What isn't helpful is repeating the same thing over and over. Or not paying attention to the replies. A common problem I've seen repeatedly is people sending many many messages to the list, all quickly, and trying a bunch of different things. This is entirely the wrong approach. You have to take a methodical approach. Which doesn't involve repeating the same actions.
I am using an out the box freeradius 3.2.3 config with modified tls and eap sections as per my original post. I thought you said openssl handles all the TLS comms, therefore apart from setting the path to my certs, what else can I do in freeradius config to help? Therefore the comments and documentation don't help me solve this because I've not set anything that would cause this.
Except that it doesn't work. And the default configuration does work. So.... Alan DeKok.
Just wanted to provide an update on this. I rebuilt the server, did a fresh install of openssl 3.0.2 and libssl-dev (same version) and it started working with the same certs. After comparing the two, it appears that when freeradius was compiled, it chose an old openssl 1.x library and wasn't actually using the correct one at all. I don't know how that old version was on the box at time of compile (as well as 3.0.2) but once I'd removed 1.x and compiled again, it began working on the server. This was also why, when manually launching a server using openssl s_server with the cert, because that was using 3.0.2 it was good. The client didn't change in any way, so it was 100% this. Thanks for the explanation and help. I've learnt something from this. James
On Aug 8, 2023, at 4:00 PM, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I rebuilt the server, did a fresh install of openssl 3.0.2 and libssl-dev (same version) and it started working with the same certs.
That's good.
After comparing the two, it appears that when freeradius was compiled, it chose an old openssl 1.x library and wasn't actually using the correct one at all. I don't know how that old version was on the box at time of compile (as well as 3.0.2) but once I'd removed 1.x and compiled again, it began working on the server.
Some recommendations: * don't build your own packages * don't install multiple versions of OpenSSL on the same system. Many things are likely to break * if your distribution has old versions of FreeRADIUS, then use the packages on http://packages.networkradius.com * use "radiusd -xv" to see which version of OpenSSL is being used by FreeRADIUS. Alan DeKok.
So this is interesting... if I run the following command on the server: openssl s_server -key /usr/local/etc/raddb/certs/my_key.key -cert /usr/local/etc/raddb/certs/my_key.crt -chainCAfile /usr/local/etc/raddb/certs/my_key.ca -accept 2083 -www and on the same client that was failing when the freeradius daemon was loaded on port 2083, I can successfully query it and it establishes a TLS 1.3 session: openssl s_client -showcerts -my_host:2083 CONNECTED(00000003) depth=3 C = US, ST = California, L = San Jose, O = "Cisco Systems, Inc.", OU = Openroaming, CN = openroaming.org, emailAddress = enb-devops@cisco.com verify error:num=19:self signed certificate in certificate chain verify return:1 depth=3 C = US, ST = California, L = San Jose, O = "Cisco Systems, Inc.", OU = Openroaming, CN = openroaming.org, emailAddress = enb-devops@cisco.com verify return:1 depth=2 C = SG, ST = Singapore, L = Singapore, O = Wireless Broadband Alliance, OU = WBA, CN = openroaming.org, dnQualifier = WBA WRIX ECC Policy Intermediate CA-01 verify return:1 depth=1 C = US, O = "Kyrio, Inc.", OU = WBA, CN = openroaming.org, dnQualifier = WBA WRIX ECC Intermediate CA-2 verify return:1 depth=0 C = GB, O = abc123, OU = WBA:WRIX End-Entity, CN = my_host, UID = MY:MY verify return:1 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 5112 bytes and written 394 bytes --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 19 (self signed certificate in certificate chain) --- Ciphers supported in s_server binary TLSv1.3 :TLS_AES_256_GCM_SHA384 TLSv1.3 :TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 :TLS_AES_128_GCM_SHA256 TLSv1.2 :ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 :ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 :DHE-RSA-AES256-GCM-SHA384 TLSv1.2 :ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 :ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 :DHE-RSA-CHACHA20-POLY1305 TLSv1.2 :ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 :ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 :DHE-RSA-AES128-GCM-SHA256 TLSv1.2 :ECDHE-ECDSA-AES256-SHA384 TLSv1.2 :ECDHE-RSA-AES256-SHA384 TLSv1.2 :DHE-RSA-AES256-SHA256 TLSv1.2 :ECDHE-ECDSA-AES128-SHA256 TLSv1.2 :ECDHE-RSA-AES128-SHA256 TLSv1.2 :DHE-RSA-AES128-SHA256 TLSv1.0 :ECDHE-ECDSA-AES256-SHA TLSv1.0 :ECDHE-RSA-AES256-SHA SSLv3 :DHE-RSA-AES256-SHA TLSv1.0 :ECDHE-ECDSA-AES128-SHA TLSv1.0 :ECDHE-RSA-AES128-SHA SSLv3 :DHE-RSA-AES128-SHA TLSv1.2 :RSA-PSK-AES256-GCM-SHA384 TLSv1.2 :DHE-PSK-AES256-GCM-SHA384 TLSv1.2 :RSA-PSK-CHACHA20-POLY1305 TLSv1.2 :DHE-PSK-CHACHA20-POLY1305 TLSv1.2 :ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 :AES256-GCM-SHA384 TLSv1.2 :PSK-AES256-GCM-SHA384 TLSv1.2 :PSK-CHACHA20-POLY1305 TLSv1.2 :RSA-PSK-AES128-GCM-SHA256 TLSv1.2 :DHE-PSK-AES128-GCM-SHA256 TLSv1.2 :AES128-GCM-SHA256 TLSv1.2 :PSK-AES128-GCM-SHA256 TLSv1.2 :AES256-SHA256 TLSv1.2 :AES128-SHA256 TLSv1.0 :ECDHE-PSK-AES256-CBC-SHA384 TLSv1.0 :ECDHE-PSK-AES256-CBC-SHA SSLv3 :SRP-RSA-AES-256-CBC-SHA SSLv3 :SRP-AES-256-CBC-SHA TLSv1.0 :RSA-PSK-AES256-CBC-SHA384 TLSv1.0 :DHE-PSK-AES256-CBC-SHA384 SSLv3 :RSA-PSK-AES256-CBC-SHA SSLv3 :DHE-PSK-AES256-CBC-SHA SSLv3 :AES256-SHA TLSv1.0 :PSK-AES256-CBC-SHA384 SSLv3 :PSK-AES256-CBC-SHA TLSv1.0 :ECDHE-PSK-AES128-CBC-SHA256 TLSv1.0 :ECDHE-PSK-AES128-CBC-SHA SSLv3 :SRP-RSA-AES-128-CBC-SHA SSLv3 :SRP-AES-128-CBC-SHA TLSv1.0 :RSA-PSK-AES128-CBC-SHA256 TLSv1.0 :DHE-PSK-AES128-CBC-SHA256 SSLv3 :RSA-PSK-AES128-CBC-SHA SSLv3 :DHE-PSK-AES128-CBC-SHA SSLv3 :AES128-SHA TLSv1.0 :PSK-AES128-CBC-SHA256 SSLv3 :PSK-AES128-CBC-SHA --- Ciphers common between both SSL end points: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES256-SHA AES128-SHA Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA1:DSA+SHA256:DSA+SHA384:DSA+SHA512 Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 Supported groups: x25519:secp256r1:x448:secp521r1:secp384r1 Shared groups: x25519:secp256r1:x448:secp521r1:secp384r1 What would be different to the way freeradius accepts the connection using openssl to how openssl's built_in s_server accepts it? Thanks
You can use wireshark to capture the traffic on either side and see exactly what ciphers both ends are proposing. Maybe when you see what they are proposing, it will lead you to the appropriate configuration. On August 7, 2023 2:19:21 PM GMT+02:00, James Wood via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hi All,
I'm currently testing out RADSEC/TLS on the latest version, 3.2.3, with openssl 3.0 on Ubuntu 22.04.
The key, certificate and CA are correct and have been validated to match before using in the Freeradius config.
When I start the daemon there are no errors indicating the key/cert don't match so I assume all is well.
However, when a client connects over RADSEC/TLS (port 2083), Freeradius displays an SSL error. I've also tried the openssl s_client command and the same error is thrown.
openssl s_client -showcerts -connect radius.hostname:2083
The key/cert is secp384r1 based.
mods-enabled/eap:
--------------------------- tls-config tls-common { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 1024 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no ecdh_curve = "secp384r1" } ---------------------------
sites-enabled/tls:
--------------------------- listen { ipaddr = * port = 2083 type = auth+acct proto = tcp virtual_server = default clients = radsec limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } tls { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no require_client_cert = no } }
clients radsec { client all { ipaddr = 0.0.0.0/0 proto = tls secret = radsec } }
home_server tls { ipaddr = 127.0.0.1 port = 2083 type = auth secret = radsec proto = tcp status_check = none
tls { private_key_password = whatever private_key_file = ${certdir}/my_key.key certificate_file = ${certdir}/my_key.crt ca_file = ${certdir}/my_key.ca dh_file = ${certdir}/dh random_file = /dev/urandom fragment_size = 8192 ca_path = ${cadir} cipher_list = "DEFAULT" }
}
home_server_pool tls { type = fail-over home_server = tls }
realm tls { auth_pool = tls } ---------------------------
radius debug:
[snip] Listening on auth+acct proto tcp address * port 2083 (TLS) bound to server default Listening on command file /usr/local/var/run/radiusd/radiusd.sock Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on proxy address * port 40253 Ready to process requests
... new connection request on TCP socket Listening on auth+acct from client (1.2.3.4, 38639) -> (*, 2083, virtual-server=default) Waking up in 0.9 seconds. (0) (TLS) Initiating new session (0) (TLS) Handshake state - before/accept initialization (0) (TLS) Handshake state - Server before/accept initialization (0) (TLS) recv TLS 1.2 Handshake, ClientHello (0) (TLS) send TLS 1.2 Alert, fatal handshake_failure (0) ERROR: (TLS) Alert write:fatal:handshake failure (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Server : Error in error (0) ERROR: (TLS) Failed reading from OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (0) ERROR: (TLS) System call (I/O) error (-1) (0) (TLS) Failed in TLS handshake receive (TLS) Closing socket from client port 38639
If I query a public radsec radius server on port 2083 using the openssl s_client command it returns the certificate list correctly etc.
Is it a problem with my key/cert, openssl, or the client?
Thanks - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
James Wood -
marki