Hostapd: WPA3 EAP-TLS with TLS v1.3

openwrtuserx · February 19, 2026, 4:56pm

Has anyone managed to get WPA3 with EAP-TLS or EAP-TTLS working while using TLS 1.3 for the TLS connection? Preferrably I would like to use this with the internal radius server.

As far as I understand, currently the hostapd implementation for TLS 1.3 is experimental but should work if the client devices support it. Is there any reason not to use it besides potential client compatibility issues?

I already tried a bunch of things, but I think this line in the internal radius implementation prevents it from working, even if it’s enabled for hostapd:

github.com/openwrt/openwrt

package/network/services/hostapd/src/hostapd/radius.c

main


      
          	user->phase2 = phase2;
          
          	return 0;
          }
          
          static int radius_setup(struct radius_state *s, struct radius_config *c)
          {
          	struct eap_config *eap = &s->eap;
          	struct tls_config conf = {
          		.event_cb = radius_tls_event,
          		.tls_flags = TLS_CONN_DISABLE_TLSv1_3,
          		.cb_ctx = s,
          	};
          
          	eap->eap_server = 1;
          	eap->max_auth_rounds = 100;
          	eap->max_auth_rounds_short = 50;
          	eap->ssl_ctx = tls_init(&conf);
          	eap->pwd_group = 19;
          	if (!eap->ssl_ctx) {
          		wpa_printf(MSG_INFO, "TLS init failed\n");

My primary use case would be encrypted client certs (with TLS 1.2 the certs are always sent in the clear, including device/user identifiers) and the other security improvements of TLS 1.3 like PFS.

Edit: I tried with wpad-mbedtls and wpad-openssl and patching hostapd config trying to disable older TLS versions. The connection always used TLS 1.2 though.

anon63541380 · February 19, 2026, 6:25pm

You sure bout it?

openwrtuserx · February 19, 2026, 7:11pm

Yes, I checked with Wireshark. The client identity and the client certificate (i.e. public key, not the private key) is transmitted unencrypted.

openwrtuserx · February 20, 2026, 8:50pm

Update: After recompiling hostapd/wpad with the line above removed, a TLS v1.3 handshake is successfully made and certificates are no longer exposed. Although, when using wpad-mbedtls the connection fails immediately after the TLS handshake and CTRL-EVENT-EAP-SUCCESS2, before the WPA 4-way handshake. With wpad-openssl everything just works, but it seems I can’t force TLS 1.3 only from the server side.

I tried different combinations of

list hostapd_options 'tls_flags=[ENABLE-TLSv1.3][DISABLE-TLSv1.2]'
list hostapd_options 'tls_flags=[ENABLE-TLSv1.3]'

but I didn’t seem to make a difference. Sometimes, probably depending on the client’s settings it still connected with TLS 1.2.

openwrtuserx · February 21, 2026, 3:18am

Update 2: After further testing I’m 99% sure that it had nothing to do with my changes, but was rather just the difference between wpad-mbedtls and wpad-openssl. So for now the solution seems to be just using wpad-openssl for TLS 1.3. The correct version may still need to be configured on the clients. I successfully tested it with Linux and Android.

I’m still interested if someone has additional insight as to why it doesn’t work with Mbed-TLS and if it’s possible to disable TLS v1.2 for the server so that only TLS v1.3 can be used.

anon63541380 · February 21, 2026, 8:33am

Thank you for confirming
Reference: https://git.w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n1363 (tldr: tls13 support is experimental in hostapd ymmv)

system · March 3, 2026, 8:33am

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