Is OWE Actually Working?

Enhanced Open has a peculiar failure mode: it can be switched on everywhere and still do nothing. There is no lock icon, no password prompt, no error. A capable client joins, the controller reports “OWE enabled,” and everyone assumes the air is encrypted. Sometimes it is not.

At the Wi-Co community session in Brussels last spring, someone put the question bluntly: how do you actually know OWE is working on a given client, and how do you prove it? It is a fair question, because the honest answer is “not from the UI.” I found that out the hard way on a project a week before go-live, where every setting in the GUI was correct and the network still misbehaved in two opposite ways, one of which would have locked every legacy device off a production network. Neither was visible from any dashboard. The only place they showed up was a packet capture. This post is the walk-through: how OWE works, how transition mode quietly breaks, and how to prove in the air whether it is really on.

How OWE works, in one screen

OWE (Opportunistic Wireless Encryption) is defined in RFC 8110 and certified by the Wi-Fi Alliance as Wi-Fi CERTIFIED Enhanced Open (2018). It adds encryption to an otherwise-open network with no credential, PSK, or 802.1X. An unauthenticated Diffie-Hellman exchange runs during association, a PMK is derived from the shared secret, the ordinary 4-way handshake installs the PTK, and from there the traffic is CCMP/GCMP-encrypted like any RSN network. Every client gets a unique pairwise key, so a sniffer sitting on the same SSID cannot read your frames the way it can on legacy Open.

One thing to get straight up front, because it trips people up: OWE is not only a 2.4/5 GHz feature. It runs on every band, and on 6 GHz it is effectively mandatory, since plain Open is not allowed there at all. What is limited to 2.4 and 5 GHz is Transition Mode, the compatibility trick below, because it depends on an Open BSS that 6 GHz forbids. On 6 GHz you run pure OWE and non-OWE clients simply cannot join.

Two facts matter for the rest of this post, because they are the tells you look for in a capture:

● The AKM suite selector 00-0F-AC:18 (“OWE”) appears in the RSNE. The cipher is CCMP-128 or GCMP-256, and PMF (802.11w) is mandatory.

● The Diffie-Hellman Parameter element (element ID 101) rides in the Association Request and Response. Unless PMK caching is in play, both frames carry it, and its presence is what separates an OWE association from a plain Open one.

What OWE does not give you is authentication. There is no proof you are talking to the legitimate AP, so an evil twin can still stand up the same SSID and machine-in-the-middle you. OWE protects you from eavesdropping on an open network, it does not make that network fully secure. Worth saying plainly to customers before they assume otherwise.

The one element that makes, or breaks, transition mode

Pure OWE breaks every legacy client that does not understand it, so real deployments on 2.4 and 5 GHz almost always run OWE Transition Mode: two co-located BSSes advertised at once. An Open BSS with the visible SSID, whose beacon and probe responses carry an OWE Transition Mode element pointing at the companion OWE BSS, and a hidden OWE BSS with a wildcard SSID, carrying its own element pointing back. Legacy clients see only the Open BSS and connect unencrypted. OWE-capable clients read the element, find the hidden OWE BSS, and silently move there with encryption, while still showing the friendly Open name in the UI.

That element is the entire discovery mechanism. In a capture it is a vendor-specific element, tag number 221, OUI 50:6F:9A (Wi-Fi Alliance), OUI type 28, and it contains the BSSID and SSID of the companion OWE BSS. Wireshark labels it “Wi-Fi Alliance: OWE Transition Mode.” Two things have to be true for the mechanism to work: the Open BSS must advertise the element pointing at the OWE BSS, and the client must suppress the OWE BSS SSID so the user sees only one network.

Which means transition mode can fail in two opposite directions, and both are invisible to the controller. Too much: the OWE BSS SSID is not suppressed, so users see two networks where they should see one (and in some cases it is the client failing to suppress, not the AP). Too little: the Open BSS stops carrying the transition element, so capable clients never learn the OWE BSS exists and quietly stay on Open, in the clear. On my project I managed to hit both, in sequence (nice..).

A week before go-live: two failures, one SSID

The design was a textbook OWE Transition Mode SSID. The visible Open network was named #freewifi, paired with a companion OWE BSS the platform had auto-named owe_#freewifi_cd4b. In the GUI every setting was correct. Go-live was one week out, and the SSID name was frozen.

Symptom one, too much. The partner reported that their devices were seeing both networks, here reproduced in my lab: #freewifi and owe_#freewifi_cd4b. In transition mode the client is supposed to suppress the OWE BSS SSID and show only the Open one, so two visible entries is already wrong. Nothing in the GUI was misconfigured.

Symptom 1: the hidden OWE BSS is not suppressed. Both #freewifi and owe_#freewifi_cd4b show in the client's network list.

The change that made it worse. To clean up the double entry, I edited the Open SSID’s display name in my lab (not the broadcast SSID itself) and removed the # character, because the “#” was the prime suspect for the odd behaviour.

Symptom two, too little. After the update, owe_#freewifi_cd4b vanished from the list and only #freewifi remained. Looks like the workaround fixed it, right? Not really. Removing the # stopped the Open BSS beacon from carrying the OWE Transition Mode element, so even though the OWE BSS was still up and beaconing, no client would ever be pointed to it. The visible symptom was gone; the encryption was gone with it.

Symptom 2: after removing the #, only #freewifi remains. The OWE BSS is still on the air, but now unreachable.

This is where you stop trusting the network list and open a capture. On the visible #freewifi beacon, Privacy is 0 and there is no RSN element, so it is genuinely Open, and there is no vendor tag 221 / OUI 50:6F:9A anywhere in it. The companion OWE BSS is still there, hidden behind a null SSID, still advertising AKM 18 with PMF required, still pointing back at #freewifi. The pairing had gone one-directional: OWE to Open, but not Open to OWE. With the only pointer to the OWE BSS missing from the side clients actually see, the encrypted network became an island nobody could reach.

Here you can see the working SSID with transition enabled. (how it should look like)

And here is the part that makes it concrete. My iPhone fully supports OWE, so if anything was going to use it, this would. In the capture it shows up under a randomised private MAC and does this, three times over: no encryption, just the good old Open network.

No RSNE, no Diffie-Hellman element, and no EAPOL handshake anywhere afterward. A fully OWE-capable client silently downgraded to plain Open and sat there in the clear, showing a cheerful “Connected” with no lock and no warning. That single association trace is the whole failure in one client.

What is worth stressing is that the GUI configuration was correct the entire time. The problem lived only in what the AP actually put on the air, which is exactly why the beacon capture, and not the settings screen, was the only reliable way to tell which of the two failures I was looking at.

How to prove it yourself, in the air and how does it look like?

The lesson generalises well past this issue. A correct GUI proves intent, not on-air reality, and OWE hides its failures better than almost any other feature because nothing breaks visibly. So when it matters, take a monitor-mode capture on the AP’s channel while a client joins and run four checks in order. If all four pass, OWE is genuinely in use. If the first one fails, you have found a transition problem before your users do.

Here you can see the actual flow in wireshark, here you can clearly see the way how transition mode works, first it probe’s the freewifi and then because of the present Transition Element it probes the OWE SSID and goes through its motions (removed the Ack for clarity):

Another test I have performed is how to see if you are running on OPEN or the more ‘secure’ OWE network?

The client UI is fine as a first glance, as long as you treat a positive as “probably,” not “proven.” Each OS shows something a little different, and each has a way of misleading you: (all these devices are proven to be connected through the transition-mode OWE secure on my test lab)

Here the output from my Mac (with some nice wireshark colors shining in the back):

One honest caveat on check 3: PMK caching legitimately removes the Diffie-Hellman element from later associations, so a missing DH element on a returning client is not automatically a failure. Confirm on a fresh, uncached join. And if you take nothing else from this: whenever OWE and reality seem to disagree, trust the capture over the settings screen. The beacon does not know how to lie.

The takeaway

OWE is a genuinely nice feature. Free over-the-air encryption on an open network, no onboarding, no password, is exactly what public and guest Wi-Fi should have had a decade ago. But its greatest strength as a user experience, that it is completely invisible, is also its biggest operational trap. When it works you cannot see it, and when it fails you cannot see that either.

In my case the controller says “enabled” in both cases. So verify it the only way that is honest. Put a client on the air, capture the beacons and the association, and check for the transition element, the OWE AKM, the DH exchange, and the Protected bit. Do it before go-live, and again after every SSID change, because as I found out, the edit that makes the complaint disappear can be the exact same edit that switches your encryption off. One capture would have told me. Eventually, one did.

And on a last note…what also surprises me, is that in 2026 Apple is not able to tell me if my device has joined through OWE or not. It does make a difference in my opinion. But then again if I am somewhere abroad and joining a public hotspot…it's all free game right ;-).

PS: credit to Gareth, who also helped troubleshoot this one.