Good evening, Thank you for your suggestions/ reply. My comments/ questions are underneath your thoughts using ">>".
I have been working with FreeRadius and reading these threads for sometime now trying to figure out how to properly configure and implement EAP-TLS using ECDHE-ECDSA ciphers.
Set the right parameters for OpenSSL.
Do you mean within the OpenSSL source code? I've been trying to track down the location of where OpenSSL picks a TLS 1.0 handshake over TLS 1.2.
I am writing because perhaps there is a FreeRadius setting/ concept that I have been foolishly neglecting.
All of the required OpenSSL setting are in the FreeRADIUS config files. And documented there.
I'll continue to read. Is it acceptable under the ECC Curve section in EAP.Conf to use two elliptic curves? That is what wire shark is sending over.
The client (wpa_Supplicant) sends FreeRadius a Client Hello over TLS 1.0 (could perhaps cause problems with ECC?) and then FreeRadius Rejects it because of and "SSL3_CLIENT_HELLO: no shared cipher." However, I have confirmed that the latest version of openssl supports my cipher.
Use wireshark to look at the packets. It should be able to decode both sides of the EAP-TLS conversation, and show you which ciphers are being used.
wire shark has been showing the correct cipher suites are available on nth sides, which is odd. It seems that FR server rejects the Client Hello right away, even though the client hello seemingly has all the necessary information. Could it have something to do with Users/ clients.conf? I can't seem to figure out any combination that does the trick.
Does the EAP.conf/ FR have anything to do with Elliptic Curve's and their shared cipher besides putting in "ALL" for the cipher and "secptxxx" for the curve?
That should be it. Depending on OpenSSL magic, maybe "ALL" doesn't mean "ALL". Try listing the ciphers explicitly.
will do.
I have also confirmed through OpenSSL's s_client/ s_server program that my certificates are set up properly and ONLY succeed with TLS1_2 and not TLS1.0 or TLS1.1.
That tests the local OpenSSL. It doesn't test the remote end. It's possible that the remote end doesn't support the ciphers.
Both machines are identical CentOS images, except for the configuration for FR and Wpa_supplicant on the respective machines. Also, s_client/ s_server works on both.
Thank you very much for your thoughts. Much appreciated. Max Sent via mobile
On Nov 2, 2014, at 6:00 AM, freeradius-users-request@lists.freeradius.org wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org
You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..."
Today's Topics:
1. Re: issue with reaped processes timing out in rad_waitpid (Alan DeKok) 2. Re: EAP-TLS Suggestions on FreeRadius (Alan DeKok) 3. Re: 3.0.x rlm_sql mime encoding UTF8 characters (Isaac Boukris) 4. Re: Dailycounter not working (Matej ?erovnik) 5. Re: radius logs with garbage username (Jan Rafaj)
----------------------------------------------------------------------
Message: 1 Date: Sat, 01 Nov 2014 09:05:08 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: issue with reaped processes timing out in rad_waitpid Message-ID: <5454DA84.50302@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Alex Sharaz wrote:
So just to check, if I download the latest version of 2.x.x from git.freeradius.org as outined at freeradius.org/git it'll have your patch in it?
https://github.com/FreeRADIUS/freeradius-server/tree/v3.0.x
Look at the right side of the screen. There's a button "download zip".
Alan DeKok.
------------------------------
Message: 2 Date: Sat, 01 Nov 2014 09:07:49 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: EAP-TLS Suggestions on FreeRadius Message-ID: <5454DB25.7020901@deployingradius.com> Content-Type: text/plain; charset=UTF-8
Max Freeman wrote:
I have been working with FreeRadius and reading these threads for sometime now trying to figure out how to properly configure and implement EAP-TLS using ECDHE-ECDSA ciphers.
Set the right parameters for OpenSSL.
I am writing because perhaps there is a FreeRadius setting/ concept that I have been foolishly neglecting.
All of the required OpenSSL setting are in the FreeRADIUS config files. And documented there.
The client (wpa_Supplicant) sends FreeRadius a Client Hello over TLS 1.0 (could perhaps cause problems with ECC?) and then FreeRadius Rejects it because of and "SSL3_CLIENT_HELLO: no shared cipher." However, I have confirmed that the latest version of openssl supports my cipher.
Use wireshark to look at the packets. It should be able to decode both sides of the EAP-TLS conversation, and show you which ciphers are being used.
Does the EAP.conf/ FR have anything to do with Elliptic Curve's and their shared cipher besides putting in "ALL" for the cipher and "secptxxx" for the curve?
That should be it. Depending on OpenSSL magic, maybe "ALL" doesn't mean "ALL". Try listing the ciphers explicitly.
I have also confirmed through OpenSSL's s_client/ s_server program that my certificates are set up properly and ONLY succeed with TLS1_2 and not TLS1.0 or TLS1.1.
That tests the local OpenSSL. It doesn't test the remote end.
It's possible that the remote end doesn't support the ciphers.
Alan DeKok.
------------------------------
Message: 3 Date: Sat, 1 Nov 2014 16:24:53 +0200 From: Isaac Boukris <iboukris@gmail.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: 3.0.x rlm_sql mime encoding UTF8 characters Message-ID: <CAC-fF8RjDSAn7U4418hstWnoF4=K_Tjau_e1MpyvJ=w6npXoyA@mail.gmail.com> Content-Type: text/plain; charset=UTF-8
Hi,
On Mon, Oct 27, 2014 at 4:31 PM, Adam Hammond <adam.hammond@wicoms.com> wrote: ...
My questions are:
Is there a way for me to get rlm_sql to accept UTF8 characters? Or even ignore that check (at my own risk)?
I was faced with the same problem today (version 2.5.5).
I managed to get it working by replacing the function 'sql_escape_func' in 'rlm_sql.c' with the function 'sql_utf8_escape_func' from 'rlm_sql_log.c' file.
This seems to pass basic tests, but I am not sure what are the implications of this change.
HTH, Isaac B.
------------------------------
Message: 4 Date: Sat, 01 Nov 2014 16:46:53 +0100 From: Matej ?erovnik <matej@zunaj.si> To: freeradius-users@lists.freeradius.org Subject: Re: Dailycounter not working Message-ID: <5455006D.9040409@zunaj.si> Content-Type: text/plain; charset=windows-1252; format=flowed
On 28.10.2014 21:26, Matej ?erovnik wrote:
On 20.10.2014 23:40, Alan DeKok wrote: Matej ?erovnik wrote:
Hello!
I'm trying to use dailycounter on a LDAP authenticated user and it doesn't seem to work. I think I did all steps correctly, but then again, i have been wrong before:) ... rlm_sql (sql): Released sql socket id: 2 [sql] User testuser not found ++[sql] returns notfound The "testuser" isn't found. So the sqlcounter module can't do it's job, because it doesn't know what value to use for the session limit. I posted this a while ago, but I'm trying my luck one more time if anyone can point me to the right direction:
This is the part that is giving me troubles... My users exists in LDAP to which I don't have access, but I can authenticate with UserDN. I added entry testuser Max-Daily-Session := 600 to mysql radcheck table hoping radius will pick it up and use it in 'dailycounter'.
Access-request packet looks like this: rad_recv: Access-Request packet from host 10.10.10.10 port 33651, id=75, length=202 NAS-Port-Type = Wireless-802.11 Calling-Station-Id = "00:24:D7:47:1C:XX" Called-Station-Id = "hs-kit-testing" NAS-Port-Id = "bridge-bralci" User-Name = "testuser" NAS-Port = 2151677975 Acct-Session-Id = "80400017" Framed-IP-Address = 192.168.81.198 Mikrotik-Host-IP = 192.168.81.198 User-Password = "password" Service-Type = Login-User WISPr-Logoff-URL = "http://192.168.81.1" NAS-Identifier = "kit-testing" NAS-IP-Address = 192.168.1.116
Can RADIUS use the username provided in access-request for the sqldailycounter? Is that even suppose to work? Can I use 'dailycounter' on LDAP authenticated users or does that only work on local users, who are in sql database?
Matej
-- --- Matej Zerovnik
------------------------------
Message: 5 Date: Sun, 2 Nov 2014 01:09:58 +0100 (MET) From: Jan Rafaj <jr-freeradius@cedric.unob.cz> To: freeradius-users@lists.freeradius.org Subject: Re: radius logs with garbage username Message-ID: <alpine.LNX.2.00.1411020109001.2774@cedric.unob.cz> Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII
On Wed, 29 Oct 2014, Rando Nakarmi wrote:
I have few fews which has garbage username, why does this happens ?
radiusd[367]: Login OK: [u2ttxxBZPlxGkGvGiM6lhPw==] radiusd[369]: Login OK: [f2vnxxBZPlxGkGvGiM6lhPw==]
any help
Sounds like incorrectly configured mobile phones with Symbian OS. (If not configured correctly for WPAx-Enterprise, they tend to send identities with multiple delimiters, base64-encoded cert parts, and what not, in the User-Name...).
------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
End of Freeradius-Users Digest, Vol 115, Issue 3 ************************************************
Max Freeman wrote:
Good evening,
Thank you for your suggestions/ reply. My comments/ questions are underneath your thoughts using ">>".
Ugh. Standard quoting rules are nicer.
Do you mean within the OpenSSL source code? I've been trying to track down the location of where OpenSSL picks a TLS 1.0 handshake over TLS 1.2.
No. I mean via the FreeRADIUS configuration. There is no TLS 1.0 versus 1.2 configuration currently in the server. It's not really needed.
I'll continue to read. Is it acceptable under the ECC Curve section in EAP.Conf to use two elliptic curves? That is what wire shark is sending over.
I think it's only one, but I'm not really sure. It's more of an OpenSSL question.
The client (wpa_Supplicant) sends FreeRadius a Client Hello over TLS 1.0 (could perhaps cause problems with ECC?) and then FreeRadius Rejects it because of and "SSL3_CLIENT_HELLO: no shared cipher." However, I have confirmed that the latest version of openssl supports my cipher.
FreeRADIUS depends on OpenSSL to do all SSL. If OpenSSL says "no shared cipher", FreeRADIUS can't do much about it.
wire shark has been showing the correct cipher suites are available on nth sides, which is odd. It seems that FR server rejects the Client Hello right away, even though the client hello seemingly has all the necessary information. Could it have something to do with Users/ clients.conf?
No. Presuming you've listed the NAS in the "clients.conf" file...
Does the EAP.conf/ FR have anything to do with Elliptic Curve's and their shared cipher besides putting in "ALL" for the cipher and "secptxxx" for the curve?
No.
I have also confirmed through OpenSSL's s_client/ s_server program that my certificates are set up properly and ONLY succeed with TLS1_2 and not TLS1.0 or TLS1.1.
Hmm.. that might be the issue. In v3, try editing src/main/tls.c. Change: ctx = SSL_CTX_new(TLSv1_method()); to: ctx = SSL_CTX_new(SSLv23_method()); If that works, I'll make the change in the main tree. Alan DeKok.
participants (2)
-
Alan DeKok -
Max Freeman