WPA2-Enterprise Client, 802.1x - How to allow weak SSL Ciphers?

Installing and Using OpenWrt
1

Using OpenWrt (24.10.0) as an 802.1x WPA2-Enterprise (Username/Password) WiFi Client (sta). Getting the following error messages on trying to associate.

daemon.notice wpa_supplicant[1740]: phy1-sta0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
daemon.notice wpa_supplicant[1740]: SSL: SSL3 alert: read (remote end reported an error):fatal:handshake failure
daemon.notice wpa_supplicant[1740]: OpenSSL: openssl_handshake - SSL_connect error:0A000410:SSL routines::sslv3 alert handshake failure
daemon.notice wpa_supplicant[1740]: phy1-sta0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

It appears the fix is to allow weaker ciphers on WPA Supplicant / OpenSSL. Other references have pointed to the following solution for desktop-oriented Linux clients.

Create a new file in: /etc/wpa_supplicant/wpa_supplicant.conf containing:

openssl_ciphers=DEFAULT@SECLEVEL=0

I have tried other packages (wpad, wpad-mbedtls, wpad-openssl, wpad-wolfssl), and all exhibited the same problem.

How can I use the UCI config files to set the WPA Supplicant to allow for weaker ciphers?

2

You can practice needed cypher string using openssl s_client

3

Basically I am looking for a way for dynamically generated config file: /var/run/wpa_supllicant-sta1.conf, to have UCI add a line to that file, "openssl_ciphers=DEFAULT@SECLEVEL=0". Without having to disable OpenWrt's managing of the WPA Supplicant config and process.

4

You need to install a wpad openssl variant (wpad-openssl will do fine) and patch the file /lib/netifd/hostapd.sh

Patch 1

Search for $country_str and add the lineopenssl_ciphers=DEFAULT@SECLEVEL=0
Example:

        wpa_supplicant_teardown_interface "$ifname"
        cat > "$_config" <<EOF
${scan_list:+freq_list=$scan_list}
$ap_scan
$country_str
openssl_ciphers=DEFAULT@SECLEVEL=0
EOF
        return 0
}

wpa_supplicant_set_fixed_freq() {
        local freq="$1"
        local htmode="$2"

Patch 2

Search for set_default auth MSCHAPV2 and add append network_data "phase1=\"tls_disable_tlsv1_0=0 tls_disable_tlsv1_1=0\"" "$N$T"

Example:

                                fast|peap|ttls)
                                        json_get_vars auth password ca_cert2 ca_cert2_usesystem client_cert2 priv_key2 priv_key2_pwd
                                        set_default auth MSCHAPV2

                                        append network_data "phase1=\"tls_disable_tlsv1_0=0 tls_disable_tlsv1_1=0\"" "$N$T"

                                        if [ "$auth" = "EAP-TLS" ]; then

Then execute wifi. Check the generated config at /var/run/wpa_supplicant-phy0-sta0.conf.

1 Like
5

First try the different SSL libraries because there are slight differences / bugs between them that sometimes one will not work with certain enterprise systems.

I thought there was a way to place an arbitrary option into the wpad config similar to hostapd_option and hostapd_bss_option.

6

This solved it. Thanks. @enmaskarado

7

@enmaskarado , It seems that could frequently affect users, operating as WPA2-Enterprise/802.1x clients, since OpenSSL tightened their minimums for supported crypto algorithms in the default security level. Do you think this should be added as a settable option via UCI / Luci?

Or patched, similar to hostapd was patched?

8

One this to note is that the Radius server is running an older version of SSL - which puts everything authenticating to that server at some level of risk...

9

Yes, agreed, the servers should upgrade their SSL negotiations or signed cert mechanisms. However, a lot of times these Radius servers are being run by services providers (i.e Comcast, AT&T, etc), and as a customer you can't get them to fix their SSL negotiation / cipher.

10

Interesting enough - I used to work for a service provider - we usually try to stay on top of things, and if we miss something, this happens...

if I were one of those service providers, I'd like to know, and we could reconfigure Radius as needed...

11

That's exactly what has happened - and this also applies towards things like TLS versions on HTTP servers and Web Clients - challenge is the handshake and things offered up...

services do get deprecated all the time, esp with crypto...

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.