Posted: Sun Nov 28, 2010 0:13 Post subject: TLS handshake problems: Wpa2 Enterprise - WR1043ND - XP SP3
Hello,
Environment:
Server side -
* TP-Link WR1043ND (DE ver 1.0) showed
+ DD-Wrt 14896 or BrainSlayer-V24-preSP2 r15778
* Debian sid
+ freeradius 2.1.10+dfs (almost default settings).
Client side -
* Windows XP SP3
* others (Win 7, Ubuntu, ...)
When connecting from Windows XP SP3 through a dd-wrt driven access point using (P)EAP-TLS authentication fails. It does not happen with the other OS mentioned above.
radius.log says:
Sat Nov 27 15:09:35 2010 : Error: TLS Alert write:fatal:protocol version
Sat Nov 27 15:09:35 2010 : Error: rlm_eap: SSL error error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Sat Nov 27 15:09:35 2010 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails.
The error does neither occur on a WRT54GL with 13064 nor on a WR1043ND with TP-Link firmware.
It seems, that the newer builds of dd-wrt use a supplicant linked agains openssl 0.9.8 libraries with disabled tls negotiation. While this prevents faked certificates, it breaks compatibility.
Are there any known solutions for this?
Newer ssl lib with a workaround addressing this problem?
Is it possible to import precompiled packages from openwrt to dd-wrt as a workaround? How?
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Mon Nov 29, 2010 11:04 Post subject:
wpa supplicant nor hostapd uses openssl.
TLS is enabled in both. (openwrt uses the same hostapd/wpa_supplicant version) _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Mon Nov 29, 2010 11:21 Post subject:
the hostapd log would be interesting too here, assuming you're trying to use your device as accesspoint with wpa enterprise _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Mon Nov 29, 2010 11:41 Post subject:
i tested now EAP-PEAP authentication using WR1043 in WPA Enterprise mode and freeradius 2.1.8.
all is working without issues. no SSLV3 errors are shown.
so i can just assume, that your freeradius installation has a problem or your local openssl installation
[eap] EAP packet type response id 233 length 119
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
TLS Length 109
[peap] Length Included
[peap] eaptls_verify returned 11
[peap] (other): before/accept initialization
[peap] TLS_accept: before/accept initialization
[peap] <<< TLS 1.0 Handshake [length 0068], ClientHello
[peap] TLS_accept: SSLv3 read client hello A
[peap] >>> TLS 1.0 Handshake [length 002a], ServerHello
[peap] TLS_accept: SSLv3 write server hello A
[peap] >>> TLS 1.0 Handshake [length 0820], Certificate
[peap] TLS_accept: SSLv3 write certificate A
[peap] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone
[peap] TLS_accept: SSLv3 write server done A
[peap] TLS_accept: SSLv3 flush data
[peap] TLS_accept: Need to read more data: SSLv3 read client certificate A _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
I flashed back to the original firmware - Enterprise-WPA2 works perfectly that way.
My radius setup is quite identical to the debian defaults and works well with both dd-wrt and cisco firmwares on wrt54gl, wrt160n (v2) and even an old DI-624.
The error first occured, when TP-Link WR-1043ND joined the setup with the above stated build.
Since the TP is now in production environment, cannot do any further tests with it this year.
What firmware did you use?
Did you test it with Windows XP? That´s the only constellation in which the error occurs.
(Windows XP SP3, freeradius, DD-WRT build on WR1043ND as stated.)
The client on which the problem showed up was equipped with an Intel ProWireless 2200BG card - just in case it´s of any relevance.
Last edited by epek on Mon Nov 29, 2010 18:35; edited 1 time in total
the hostapd log would be interesting too here, assuming you're trying to use your device as accesspoint with wpa enterprise
I had remote logging activated, but cannot see any relevant data from my dd-wrt experiments. I tested openwrt too, but it left the router crashed on updating to rc4 - so I did not test it further due to lack of time.
Your assumption is correct, but it´s wpa2/aes or wpa2/aes+tkip.
Freeradius even got new certs while debugging.
I guess, that´s the only relevant part of the logs:
Nov 27 16:53:40 192.168.1.240 syslog: cron : cron daemon successfully stopped
Nov 27 16:53:42 192.168.1.240 syslog: cron : cron daemon successfully started
Nov 27 16:53:46 192.168.1.240 syslog: vpn modules : vpn modules successfully unloaded
Nov 27 16:53:46 192.168.1.240 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
Nov 27 16:53:46 192.168.1.240 syslog: vpn modules : ip_nat_proto_gre successfully loaded
Nov 27 16:53:46 192.168.1.240 syslog: vpn modules : ip_conntrack_pptp successfully loaded
Nov 27 16:53:46 192.168.1.240 syslog: vpn modules : ip_nat_pptp successfully loaded
Nov 27 16:53:47 192.168.1.240 syslog: wland : WLAN daemon successfully stopped
Nov 27 16:53:48 192.168.1.240 syslog: vpn modules : vpn modules successfully unloaded
Nov 27 16:53:48 192.168.1.240 syslog: vpn modules : ip_conntrack_proto_gre successfully loaded
Nov 27 16:53:48 192.168.1.240 syslog: vpn modules : ip_nat_proto_gre successfully loaded
Nov 27 16:53:48 192.168.1.240 syslog: vpn modules : ip_conntrack_pptp successfully loaded
Nov 27 16:53:48 192.168.1.240 syslog: vpn modules : ip_nat_pptp successfully loaded
Nov 27 16:53:49 192.168.1.240 syslog: wland : WLAN daemon successfully started
Nov 27 16:53:50 192.168.1.240 syslog: NAS : NAS lan (wl0 interface) successfully started
Nov 27 16:53:50 192.168.1.240 syslog: klogd : klog daemon successfully stopped
Please tell me how I can help. I plan on getting some more of the WR-1043NDs in order to replace the unsupported devices.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Mon Nov 29, 2010 23:46 Post subject:
by the way .the TLS handshaking is done between your client and the radius server. the hostapd is just passing it through. i tested various peap configurations today. all are working without issues. authentication successfull. you can start hostapd manually on your device (after killing it) with option "-dd" too see more log messages. but this message you have seen on your radius server was caused by your client device / client device operating system since hostapd is not doing the authentication work.
the client authenticates against your radius server and the radius server informs hostapd, that the client was acknowledged
by the way. never use TKIP on a 802.11n device, this will disable 802.11n and switches back to 802.11g by wifi specification. pure AES is always best an secure _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
by the way .the TLS handshaking is done between your client and the radius server. the hostapd is just passing it through...
... but this message you have seen on your radius server was caused by your client device / client device operating system ...
I don't doubt that the client is doing a specific request, but there has to be something else.
What I do not fully understand is, why the authentication fails only in the setup involving that specific DD-Wrt build , but not when using another router or the same router with another firmware or even former dd-wrt versions on other routers (in AP mode).
Could it be that hostapd (in some of the builds) is rather acting as a proxy then passing the request through?
As I wrote before, the only exchanged component in the setup is the router/ap firmware. Hence I would not start debugging in the radius.
BrainSlayer wrote:
by the way. never use TKIP on a 802.11n device, this will disable 802.11n and switches back to 802.11g by wifi specification. pure AES is always best an secure
Thanks for the information, I did not yet know that. Usually I tend to use AES, but for compatibility reasons with older clients I chose the combined method. I now understand why newer devices never offer the mixed mode (TKIP+AES).
