FreeRADIUS 3.0.15 fails to respond with TLS 1.0 (Debian testing)
Hi, it looks like FreeRADIUS 3.0.15 doesn't work anymore on Debian testing (with OpenSSL). I tried connecting an Android 6.0 client to FreeRADIUS and from what I understand from the following log, it fails responding to one part of the request because it tries to use TLS 1.0 (eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) and AFAIK, TLS 1.0 is not supported anymore in OpenSSL: (0) Received Access-Request Id 37 from 192.168.0.254:46065 to 192.168.0.100:1812 length 139 (0) User-Name = "me" (0) NAS-IP-Address = 192.168.0.254 (0) NAS-Port = 0 (0) Called-Station-Id = "D0-7D-0D-0F-1B-22:MyAP" (0) Calling-Station-Id = "12-34-56-78-90-AB" (0) Framed-MTU = 1400 (0) NAS-Port-Type = Wireless-802.11 (0) Connect-Info = "CONNECT 0Mbps 802.11" (0) EAP-Message = 0x02000007016d65 (0) Message-Authenticator = 0xb909500b8d92f535dd010ce46c878d47 (0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "me", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: Peer sent EAP Response (code 2) ID 0 length 7 (0) eap: EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize (0) [eap] = ok (0) } # authorize = ok (0) Found Auth-Type = eap (0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (0) authenticate { (0) eap: Peer sent packet with method EAP Identity (1) (0) eap: Calling submodule eap_peap to process data (0) eap_peap: Initiating new EAP-TLS session (0) eap_peap: [eaptls start] = request (0) eap: Sending EAP Request (code 1) ID 1 length 6 (0) eap: EAP session adding &reply:State = 0xf60008ccf601110e (0) [eap] = handled (0) } # authenticate = handled (0) Using Post-Auth-Type Challenge (0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (0) Challenge { ... } # empty sub-section is ignored (0) Sent Access-Challenge Id 37 from 192.168.0.100:1812 to 192.168.0.254:46065 length 0 (0) EAP-Message = 0x010100061920 (0) Message-Authenticator = 0x00000000000000000000000000000000 (0) State = 0xf60008ccf601110e4d96bfb0034242b4 (0) Finished request Waking up in 4.9 seconds. (1) Received Access-Request Id 38 from 192.168.0.254:46065 to 192.168.0.100:1812 length 260 (1) User-Name = "me" (1) NAS-IP-Address = 192.168.0.254 (1) NAS-Port = 0 (1) Called-Station-Id = "D0-7D-0D-0F-1B-22:MyAP" (1) Calling-Station-Id = "12-34-56-78-90-AB" (1) Framed-MTU = 1400 (1) NAS-Port-Type = Wireless-802.11 (1) Connect-Info = "CONNECT 0Mbps 802.11" (1) EAP-Message = 0x0201006e198000000064160301005f0100005b0301f3660ce76c4adfd99ae7f539e1867cd020b0da3f818c40bf2116c330cdb148c100001cc00ac0140039c009c0130033c007c0110035002f00050004000a00ff0100001600170000000b00020100000a00080006001700180019 (1) State = 0xf60008ccf601110e4d96bfb0034242b4 (1) Message-Authenticator = 0xc2e06b9b63ab56c6fbe401b903304705 (1) session-state: No cached attributes (1) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (1) authorize { (1) policy filter_username { (1) if (&User-Name) { (1) if (&User-Name) -> TRUE (1) if (&User-Name) { (1) if (&User-Name =~ / /) { (1) if (&User-Name =~ / /) -> FALSE (1) if (&User-Name =~ /@[^@]*@/ ) { (1) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (1) if (&User-Name =~ /\.\./ ) { (1) if (&User-Name =~ /\.\./ ) -> FALSE (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (1) if (&User-Name =~ /\.$/) { (1) if (&User-Name =~ /\.$/) -> FALSE (1) if (&User-Name =~ /@\./) { (1) if (&User-Name =~ /@\./) -> FALSE (1) } # if (&User-Name) = notfound (1) } # policy filter_username = notfound (1) [preprocess] = ok (1) [chap] = noop (1) [mschap] = noop (1) [digest] = noop (1) suffix: Checking for suffix after "@" (1) suffix: No '@' in User-Name = "me", looking up realm NULL (1) suffix: No such realm "NULL" (1) [suffix] = noop (1) eap: Peer sent EAP Response (code 2) ID 1 length 110 (1) eap: Continuing tunnel setup (1) [eap] = ok (1) } # authorize = ok (1) Found Auth-Type = eap (1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (1) authenticate { (1) eap: Expiring EAP session with state 0xf60008ccf601110e (1) eap: Finished EAP session with state 0xf60008ccf601110e (1) eap: Previous EAP request found for state 0xf60008ccf601110e, released from the list (1) eap: Peer sent packet with method EAP PEAP (25) (1) eap: Calling submodule eap_peap to process data (1) eap_peap: Continuing EAP-TLS (1) eap_peap: Peer indicated complete TLS record size will be 100 bytes (1) eap_peap: Got complete TLS record (100 bytes) (1) eap_peap: [eaptls verify] = length included (1) eap_peap: (other): before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: <<< recv TLS 1.2 [length 005f] (1) eap_peap: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version (1) eap_peap: ERROR: TLS Alert write:fatal:protocol version tls: TLS_accept: Error in error (1) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol (1) eap_peap: ERROR: System call (I/O) error (-1) (1) eap_peap: ERROR: TLS receive handshake failed during operation (1) eap_peap: ERROR: [eaptls process] = fail (1) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (1) eap: Sending EAP Failure (code 4) ID 1 length 4 (1) eap: Failed in EAP select (1) [eap] = invalid (1) } # authenticate = invalid (1) Failed to authenticate the user (1) Using Post-Auth-Type Reject (1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (1) Post-Auth-Type REJECT { (1) attr_filter.access_reject: EXPAND %{User-Name} (1) attr_filter.access_reject: --> me (1) attr_filter.access_reject: Matched entry DEFAULT at line 11 (1) [attr_filter.access_reject] = updated (1) [eap] = noop (1) policy remove_reply_message_if_eap { (1) if (&reply:EAP-Message && &reply:Reply-Message) { (1) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (1) else { (1) [noop] = noop (1) } # else = noop (1) } # policy remove_reply_message_if_eap = noop (1) } # Post-Auth-Type REJECT = updated (1) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Waking up in 0.6 seconds. (1) Sending delayed response (1) Sent Access-Reject Id 38 from 192.168.0.100:1812 to 192.168.0.254:46065 length 44 (1) EAP-Message = 0x04010004 (1) Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.9 seconds. (0) Cleaning up request packet ID 37 with timestamp +23 (1) Cleaning up request packet ID 38 with timestamp +23 Am I correct? If yes, is there any solution/workaround? Should I open a bug report? I tried to look for forcing TLS 1.2 but it doesn't seem to be an option anywhere (it can be disabled though). Thanks, Thomas
On Sep 8, 2017, at 7:30 PM, Thomas d'Otreppe <tdotreppe@gmail.com> wrote:
it looks like FreeRADIUS 3.0.15 doesn't work anymore on Debian testing (with OpenSSL).
The Debian people broke OpenSSL. They have their reasons, but that's the short summary.
I tried connecting an Android 6.0 client to FreeRADIUS and from what I understand from the following log, it fails responding to one part of the request because it tries to use TLS 1.0 (eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) and AFAIK, TLS 1.0 is not supported anymore in OpenSSL:
It's supported, but the application has to jump through hoops to do it. The debian patches were made after 3.0.15 was released. So there's every reason to expect that 3.0.15 won't work with broken OpenSSL
Am I correct? If yes, is there any solution/workaround? Should I open a bug report?
We've already fixed it in the v4 branch. We're looking at fixing it in the v3 branch, too. Probably next week, depending on what else is going on.
I tried to look for forcing TLS 1.2 but it doesn't seem to be an option anywhere (it can be disabled though).
The server is requiring TLS 1.2 (due to the OpenSSL changes), but the client is only doing 1.0. And that's the problem. In the mean time... don't use Debian "testing". It's TLS implementation is incompatible with pretty much every piece of software from 2 years ago (EAP systems, web browsers, etc). Debian testing will also break any server running on it which uses TLS. Those servers will be able to talk to new clients (released in the last 1-2 years). But they won't be able to talk to clients which are older than that. While I like security, you don't protect yourself from a cliff by nailing your feet to the floor. Alan DeKok.
tdotreppe@gmail.com ("Thomas d'Otreppe") writes:
Hi,
it looks like FreeRADIUS 3.0.15 doesn't work anymore on Debian testing (with OpenSSL). There were discussion on debian devel, and it is not anything with freeradius, but rather with ssl configuration in debian. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871918 https://lists.debian.org/debian-devel/2017/08/msg00166.html KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html My weight is perfect for my height -- which varies.
Could you point me to the commit in the 4.x branch (or in the 3.x branch if it has been ported to it)? I'd like to fix it in my patch until 3.0.16 is released (and hopefully contains the fix). Thomas On Sat, Sep 9, 2017 at 3:13 AM, Kamil Jońca <kjonca@o2.pl> wrote:
tdotreppe@gmail.com ("Thomas d'Otreppe") writes:
Hi,
it looks like FreeRADIUS 3.0.15 doesn't work anymore on Debian testing (with OpenSSL). There were discussion on debian devel, and it is not anything with freeradius, but rather with ssl configuration in debian. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871918 https://lists.debian.org/debian-devel/2017/08/msg00166.html
KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html My weight is perfect for my height -- which varies. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 24, 2017, at 6:02 PM, Thomas d'Otreppe <tdotreppe@gmail.com> wrote:
Could you point me to the commit in the 4.x branch (or in the 3.x branch if it has been ported to it)?
I'd like to fix it in my patch until 3.0.16 is released (and hopefully contains the fix).
In the v3 branch, there are a number of commits to src/main/tls.c. See those for patches. Alan DeKok.
Found them. Anything on or after September 8 for that file (and also includes src/include/tls-h). Thank you, Thomas On Tue, Oct 24, 2017 at 6:46 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 24, 2017, at 6:02 PM, Thomas d'Otreppe <tdotreppe@gmail.com> wrote:
Could you point me to the commit in the 4.x branch (or in the 3.x branch if it has been ported to it)?
I'd like to fix it in my patch until 3.0.16 is released (and hopefully contains the fix).
In the v3 branch, there are a number of commits to src/main/tls.c. See those for patches.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
kjonca＠o2.pl -
Thomas d'Otreppe