Is Opportunistic Wireless Encryption (OWE) susceptible to abuse and attacks, and if so, how?
This is the question that researchers Gabriel Ryan and Steve Deret asked in early 2019. They ended up implementing several working proofs of conceptual attacks that they demonstrated at DEF CON Wireless Village last summer. This series of posts describes the research and findings, and discusses how OWE fits into the current wireless threat model.
This series of articles contains a lot of information. Thus, we have broken it down into three sections that are designed to meet the needs of both non-technical audiences and audiences with varying levels of technical proficiency.
Part I: How We Got Here - the introductory part (this is what you are reading now). Historical context and background information that demonstrates why this research matters. Suitable for any audience. From beginner to advanced. This is perhaps the most important post in the series.
Part II: Understanding OWE - Dive into the technical details of OWE and OWE Transition. Suitable for a technically advanced audience.
Part III. Concept Attack Validation and Basic Techniques. Technical demos and walkthroughs for concept attacks.
Introduction
In January 2018, the Wi-Fi Alliance announced the upcoming release of WPA3. One of the key features disclosed in this announcement was support for custom data encryption, which would address longstanding security issues that affect open wireless networks. It was widely speculated that Opportunistic Wireless Encryption (OWE) would be used to implement this feature, and this was later confirmed when WPA3 certification began in June 2018.
By early 2019, the WPA3 implementation of OWE had been renamed Wi-Fi Certified Extension and converted into an optional stand-alone standard to be released alongside WPA3. Nonetheless, despite its status as a non-mandatory hardware certification requirement, OWE continued to be a major source of inspiration for wireless professionals and enthusiasts. By Spring 2019, several major device manufacturers announced current or future support for OWE, including Samsung, Cisco, and Aruba Networks. One of the authors of the Aruba Networks blog called OWE "the most important WPA3-related feature".
The OWE hype began to infiltrate the media. This question intrigued the author of our article, Gabriel Ryan. And together with Denver security researcher Steve Darracotta, they decided to find out: "OWE is susceptible to abuse and attacks, and if so, how?"
The initial question quickly led to the next question - what exactly is OWE? We started by doing extensive basic research trying to understand OWE at a technical level and the problems it is designed to solve. Due to the lack of publicly available written documentation, we spent a huge amount of time watching thinly veiled vendor advertising speeches on YouTube. After about a week, we decided that the best option was to act like "real" researchers and read the RFC (and we did).
In the end, the RFC turned out to be the most useful source of information about the protocol, although we also benefited from some of the comments made by Dr. Maty Vanhoeuf about OWE during his recent WPA3 posts. From these last two sources, we were finally able to come to a working hypothesis - since OWE does not provide a means of verifying the identity of the access point, wireless networks protected by OWE are susceptible to the same rogue AP attacks that have affected open networks over the past 20 years.
We were not the first to put forward this hypothesis. However, as far as they knew, no one had ever tried to test this hypothesis by creating a working proof of a conceptual attack. The researchers thought this would be a good start.
In the end, we were able to implement several working tests of concept attacks (all related to abuse of 802.11 roaming and network selection):
- Open Evil Twin vs. OWE: We are demonstrating that it is possible to force client devices that use wpa_supplicant to connect to fraudulent open access. We are currently not sure if this is an implementation-specific issue or a problem with the protocol itself.
- OWE Evil Twin vs. OWE: We are demonstrating that it is possible to force client devices that use wpa_supplicant to connect to a rogue OWE hotspot.
OWE transition mode attacks. We demonstrate that OWE transition mode is susceptible to attacks from transition mode and open access points, but not OWE access points.
We have also confirmed that the use of secure management frames (PMF), which is mandated by OWE, makes it difficult for AP rogue attacks to be performed. However, we note that the introduction of a mandatory PMF will invalidate existing threat containment methods.
How did we get here
In the end, OWE turned out to be a disappointment - not because it didn't solve the problem it was supposed to solve, but because it was trying to solve the wrong problem. Let's discuss the current wireless threat model.
To understand the threat model, we need to remember history.
Hacking WiFi: A Brief History
The 802.11 standard was released in 1999. Within a year, it was adopted by many major device manufacturers. Hence it was accepted by the general public. The standard came with two initial versions: 802.11a and 802.11b.
Initially, wireless security came in two flavors: unencrypted "open" networks and networks protected by Wired Equivalent Privacy (WEP). Interestingly, of these two initial options, only open networks are still in use today. This seems counterintuitive, since "open" networks are less secure than WEP, even by modern standards. Why is this so?
The answer to this question has as much to do with psychology as it has with safety. In particular, it is a human factor engineering problem. Both WEP and WPA / 2 (its successor) were designed to encrypt network traffic. Yes, we also use them as authentication mechanisms, but that's only because there are no more options available (you "authenticate" to WiFi networks by successfully encrypting and decrypting traffic).
Both WEP and WPA / 2 require users to authenticate to establish encrypted connections. Using HTTPS as an analogy, imagine if users need to authenticate to download web content over encrypted HTTPS. Simply put: Imagine if you need to enter a password every time you want to use encrypted HTTPS to access a new website like Google. Obviously, if that were the case, most people would gravitate toward the plaintext HTTP for convenience. But because HTTPS is capable of providing encryption in a completely transparent way to the user, its distribution has become widespread.
OWE was designed to meet a similar need. The vast majority of public wireless networks are not encrypted because it has historically been impossible to encrypt wireless traffic in a transparent and unobtrusive way. If open networks can be compared to HTTP, then OWE is the IEEE's answer to HTTPS for wireless networks.
Initial threat model (1999 to early 2000s)
Let's rewind history a bit and look at some of the security issues that surfaced in 1999. It didn't take long before offline analysis of passwords and data became a major problem. As we mentioned, using WEP to provide encryption on public networks doesn't make sense from a usability standpoint. Consequently, most of the public wireless traffic of that era was transmitted in the clear. Remember that Wi-Fi traffic is ultimately a form of radio communication, and when you transmit Wi-Fi packets, they can be captured by anyone nearby as long as they are listening to you. Without encryption, anyone who captures these packets can also view the transmitted data. This includes passwords, credit card information, and other sensitive information.
By 2002, attackers had figured out that 802.11 provided little guidance on how to choose an access point. Instead, the implementation of the process was left to the discretion of the individual device manufacturers. The algorithms that were developed to achieve this goal did not provide a real means of verifying the identity of nearby access points, making the access points susceptible to mimic attacks known as Evil Twin.
In Evil Twin, an attacker masquerades as a trusted access point in order to forcibly connect nearby wireless devices to the attacker's equipment.
Initial Threat Mitigation Measures (early 2000s to 2012)
These early wireless attacks, along with other common PITM attacks of the period such as ARP Cache Poisoning, served as catalysts for widespread application-level encryption. Simply put: The state of unauthenticated wireless security won't improve anytime soon, so application developers have made a commitment to implement their own encryption, deployed at the higher layers of the protocol stack.
By the early 2000s, the use of encrypted application layer protocols (such as SSH and HTTPS) had become an accepted best practice in the technology sector. The widespread adoption of application-level encryption soon followed, effectively ending the golden age of passive eavesdropping attacks.
These application tier mitigation measures have also eliminated the threat of Evil Twin attacks. However, Evil Twin attacks became a problem again in 2009 after the discovery of the Moxie Marlinspike HTTP Downgrade Attack. This technique allows attackers to use Evil Twin attacks to downgrade HTTPS connections to HTTP plaintext and has remained a serious and widespread threat for half a century.
Malicious attacks on access points remained the main threat to open wireless networks until 2012, when HTTP Strict Transport Layer Security (HSTS) was introduced. In fact, HSTS has not been widely adopted for a long time. Later, the Pinning certificate was accepted.
Current wireless security threat model
So. Our historical excursion ends, and we come to today's problems. Most public networks still use open Wi-Fi. HTTP downgrade attacks are largely irrelevant due to the widespread use of HSTS in the most important areas: online banking, email providers, and in general in any matter where a minimum level of security is important.
What works against open networks:
- The attacker creates a malicious access point to establish PITM and injects the payload into static web content. An attacker doesn't even try to downgrade HTTPS and doesn't need to - problems with mixed content are widespread.
- The attacker creates a malicious hotspot to send the victim to the authorization portal and uses the portal to install malware or to collect credentials using social engineering.
- An attacker can trick a user into installing a rogue CA certificate.
Finally, 20 years later, the Wi-Fi Alliance decides to deploy encryption for public Wi-Fi traffic. They call this new protocol Opportunistic Wireless Encryption (OWE).
In the next two articles in this series, we will look at how OWE works at a technical level, discuss our research methodology, and demonstrate proof of conceptual attacks against OWE.
The second part of our extensive exploration of attacks against WPA3 is on the air and today we will tell you how OWE works.
OWE is an encryption tool for open networks. And this is something that has not been in the 802.11 standard over the past 20 years. OWE is assumed to be indistinguishable from open Wi-Fi from the user's point of view - the user simply connects to the secure OWE network, and after a short key exchange, all subsequent communication is encrypted.
At first glance, this sounds great - until you find that OWE only protects against passive attacks.
OWE follows a five-step process that begins with network discovery and ends with the transfer of encrypted data between the client and the access point. We'll go over each of these steps in the following sections, and also discuss important additional information.
Sandbox
So, I've prepared a set of installation scripts to create a test environment.
Please note that these installation scripts are for Kali 5.3.7 and I have no plans to support them or provide support for any other operating system. The software is not static, this is in case you are reading an article in 2025 and the install script does not work, well ... you know ...
To create a test environment, first use git clone to get scripts from Github:
Code:
git clone https://github.com/s0lst1c3/owe-lab
Then run the install script:
Code:
cd owe-lab
./lab-setup
If the installation script completed successfully, you should have a directory that looks like this:
As you can see in the screenshot above, the installation script will create a test environment with each of the following components:
- Virtual access point and base station
- Wireshark Dev Branch
- EAPHammer
- AP and station configuration files
- Hardware simulator control scripts
I will briefly describe each of these components in the following sections.
Virtual access point and base station
These are only the latest versions of wpa_supplicant and hostapd with dependencies enabled and compiled with OWE and simultaneous peer authentication (SAE) support.
Wireshark Dev Branch
We will use Wireshark for both analysis and verification that everything in the lab is working as expected. For OWE and SAE support, we need the latest version of Wireshark, which can only be compiled from source. Luckily, the script will take care of this.
EAPHammer
OWE-enabled wireless attack suite for proof-of-concept (spin-off of this study).
AP and station configuration files
The test environment includes a conf-files directory containing a set of wpa_supplicant and hostapd configuration files for open networks, OWE and OWE Transition modes. At the time of our research, the OWE implementation in hostapd was still under development. Consequently, none of the configuration parameters required to create or connect to an OWE access point have been documented. With no publicly available documentation, we ended up referring to the hostap unit test whitebox code overview (over 100.00 lines of code) to create this relatively simple set of working configuration files.
Hardware simulator control scripts
The mac80211 Wi-Fi stack (the kernel subsystem that works with Wi-Fi) comes with a kernel module named mac80211_hwsim that can be used to simulate an arbitrary number of virtual wireless interfaces and pass virtual WiFi traffic between them. We exclusively use mac80211_hwsim.
To enable the mac80211_hwsim kernel module, use modprobe as shown in the example below. The radios variable is used to specify the number of virtual interfaces to create.
Code:
modprobe mac80211_hwsim radios = 3
Alternatively, you can simply run the enable-hwsim script:
Code:
./enable-hwsim
After enabling mac80211_hwsim, you can view the interfaces you created using the iwconfig command. In Kali (and any other Debian-based distribution for that matter), newly created interfaces will be created using the wlanX model, where X is a positive integer. You will also notice a new interface named hwsim0. It is actually a tap interface that can be used to capture traffic passing between wlanX interfaces.
To destroy the virtual environment, use the rmmod command, as shown in the following example:
Code:
rmmod mac80211_hwsim
Reference Information
Before we proceed, we need to go through some background information. If you are unfamiliar with how 802.11 works, I recommend checking out the following blog post:
posts.specterops.io
In addition, you need to briefly cover the following concepts:
Type Length Encoding (TLV)
Information elements
Elements of a Reliable Safety Network (RSN)
Authentication Key Management (AKM) Selectors
Element Encoding and Type-Length-Value (TLV)
Type-Length-Value (TLV) is an encoding scheme used in communications protocols to add information to individual messages (in this case, packets). TLV relies on data structures called items.
Information Elements (IEs) are elements used to add metadata to Management Frames (MFs). Beacons, test requests, test responses, and communication frames are created by adding IE to each other.
Let's focus on beacon frames. As you may recall, frames are periodically transmitted by access points (APs) to communicate their presence and capabilities to neighboring stations. IE is the data structure that makes this possible. To illustrate this, let's open a beacon-a frame in Wireshark and see how it works. Here I am using the following capture example from the wiki:
https://wiki.wireshark.org/SampleCa...&do=get&target=Network_Join_Nokia_Mobile.pcap
The very first packet to be captured is the beacon frame. Selecting this frame in Wireshark opens three drop-down menus (depending on the Wireshark configuration, these may already be expanded):
Expanding the bottom-most menu in the screenshot above opens up two new menus:
We are interested in a drop-down list marked "Parameters with tags". Expanding the Tagged Options menu, you will see a list of IE, which Wireshark is known as "tags":
To see how 802.11 uses TLV encoding in action, click the SSID Parameter Set IE to expand it as shown in the following screenshot:
The first IE field (tag number) indicates its data type, which in this case is the “SSID Parameter Set”. The next IE field is the length field of its value, which in this case is 9. The last IE field is its value, which we know is the 9 byte SSID because of the type and length fields in IE.
Most of the beacon-a frame metadata is stored in IE, which follows this Type-Length-Value format. Other control frames are similar.
OWE Phase 1: Network Discovery
Why have we talked so much about Type-Length-Value (TLV) coding and Information Elements (IE)? They are very important for understanding how OWE works at the package level. To see this, let's take a look at the OWE authentication process in Wireshark.
Start by enabling the simulated WiFi interfaces using the enable-hwsim script provided in the test environment:
Code:
./enable-hwsim
Then instruct Network Manager to relinquish control of your hwsim0, wlan0, and wlan1 interfaces and bring hwsim0, wlan0, and wlan1 interfaces online:
Code:
nmcli device set wlan0 managed off
nmcli device set wlan1 managed off
nmcli device set hwsim0 managed off
ifconfig wlan0 up
ifconfig wlan1 up
ifconfig hwsim0 up
Then open Wireshark from your environment directory and set it to listen on the hwsim0 interface as shown in the following screenshot:
Then create an instance of the OWE access point using hostapd. We will do this by providing hostapd with the following configuration file, which can be found in the conf-files directory:
Code:
# use interface wlan0
interface = wlan0 # set ssid to "owe"
ssid = owe # manually set BSSID
bssid = a6: 44: ce: d8: 61: 6f # set channel to 1
channel = 1 # require Protected Management Frames (PMF)
ieee80211w = 2 # enable full IEEE 802.11i / RSN
wpa = 2 # set key management element to OWE
wpa_key_mgmt = OWE # set RSN pairwise cipher to CCMP
rsn_pairwise = CCMP
To start the access point, simply pass hostapd the appropriate configuration file, as shown in the following command:
Code:
./hostapd conf-files / hostapd-owe.conf
Back in the Wireshark window, filter the beacon-a frames from your AP using the following filter:
Code:
wlan.fc.subtype == 0x8 && wlan.bssid == a6: 44: ce: d8: 61: 6f
After applying the filter, select one of the packages and expand the Tagged Options menu as shown in the following screenshot:
Then expand the RSN Information tag as shown in the following screenshot:
Then expand the "Authentication Key Management List> Authentication Key Management Package (AKM)" tags as shown in the following screenshot:
Here's the important part: notice the meaning of the Key Management Type (AKM) item. Access Points (APs) that support OWE advertise their protocol support using an Authentication and Key Management (AKM) Suite selector that is added to the RSN element of all beacons and test response frames that the AP issues. Base stations that support OWE recognize the presence of this element and use it to identify neighboring access points that support OWE.
Now let's take a look at what happens when we connect the base station to an access point. To do this, we will use the wpa_supplicant binary of our environment with the following configuration file:
Code:
# OWE network
network = {
ssid = "owe" # connect to SSID "owe"
frequency = 2412 # connect to channel 1 (center freq 2412)
key_mgmt = OWE # use OWE
proto = RSN # use RSN
ieee80211w = 2 # use Protected Management Frames (PMF)
pairwise = CCMP # set pairwise cipher suite to CCMP
}
To connect to the OWE access point, pass wpa_supplicant the appropriate configuration file, as shown in the following command:
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-owe.conf
The base station recognizes the access point as OWE-compliant and uses it to initiate authentication in an open system (authentication in an open system is just a fancy way of saying "authentication is not really happening"). You can see the authentication process in Wireshark using the following filter:
Code:
wlan.fc.type_subtype == 0xb
OWE Phase 2: Association
Once the client device has authenticated the open system with an access point (AP), the client and the AP proceed to the 802.11 association process. During the association, there is a Diffie-Hellman (DH) OWE key exchange and a four-way handshake.
Remember that OWE is a form of public key cryptography - both the client and the AP must be able to exchange DH keys with each other in order to communicate securely. As in the network discovery phase, this key exchange is facilitated by information elements (IEs) that are added to the association request and response frames. When the base station sends an association request to the access point, a DH parameter element is added to the probe request frame. This DH parameter element contains the base station's public key. The access point then responds with an association response frame, to which its public key is appended to its own DH parameter element.
Let's walk through this process by isolating the association process using the following filter (which filters to request association and response frames):
Code:
wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1
If we select the first package displayed (which is an association request), we notice that it contains an extended tag named "OWE Diffie-Hellman Option" as shown in the following screenshot.
The OWE Diffie-Hellman Paramater tag extension exposes the base station's public key:
Likewise, selecting the appropriate association response frame also reveals the presence of an extended tag named OWE Diffie-Hellman Parameter that contains the public key of the access point.
The process of exchanging public keys in this manner is known as Diffie-Hellman (DH) key exchange.
OWE Phase 3: Post-Association
Once the client and AP have completed the pairing process as well as the DH key exchange, a paired master key (PMK) is generated. The PMK is assigned a unique identifier known as the Paired Master Key Identifier (PMKID). The AP then initiates a four-way handshake with the client, in which the PMK is used to generate encryption keys.
You can see how this handshake happens in Wireshark by isolating EAPOL packets with the following filter:
EAPOL
OWE Phase 4: Data Transfer
At this point, the client and the AP have established an encrypted connection with each other, which will be used to protect all subsequent data transmission.
Note that there is one thing that is clearly missing from this whole process: certificates.
OWE transient
OWE Transition was designed to provide open network access for both new OWE-enabled devices and legacy devices that do not support OWE.
This is how it works. Access points configured to use OWE transition mode actually serve two Basic Service Sets (BSS) at the same time. The first BSS is an open access point with a visible ESSID. The second BSS is configured to use OWE and is assigned a randomly generated ESSID that is different from the open access point ESSID. This second OWE is also hidden, which means it can only be discovered by directed test requests.
To create an access point that matches this configuration, we use a configuration file similar to the one shown below. Note that this configuration file installs two BSSs of the same wireless interface - one open and one with OWE support. The owe_transition_ssid and owe_transition_bssid configuration parameters are used to link two BSSs. If this config file seems confusing, don't be afraid to move on. It will make more sense after learning what the AP and station are doing in Wireshark.
Code:
# general --- interface = wlan0
ssid = owe-hidden
bssid = a6: 44: ce: d8: 61: 6f
channel = 1
ignore_broadcast_ssid = 1
ieee80211w = 1 # owe_transition --- wpa = 2
wpa_key_mgmt = OWE
rsn_pairwise = CCMP
owe_transition_ssid = "transition"
owe_transition_bssid = fe: e1: de: ce: a5: ed # populate_owe_transition_open_bss --- bss = wlan0_0
ssid = transition
bssid = fe: e1: de: ce: a5: ed
owe_transition_ssid = "owe-hidden"
owe_transition_bssid = a6: 44: ce: d8: 61: 6fwpa = 2
wpa_key_mgmt = OWE
rsn_pairwise = CCMP
Let's take a look at what this config file actually does by using it to create an access point in OWE Transition mode and then analyzing it in Wireshark. Start by running hostapd with the configuration file shown in the following command:
Code:
./hostapd conf-files / hostapd-owe-transition.conf
Then filter the beacon-a frames in Wireshark using the following filter:
Code:
wlan.fc.type_subtype == 0x8
You should see a series of beacon-a frames transmitted by two different access points as shown in the following screenshot.
Note that about half of these beacons come from the BSS with the SSID set to "hop", while the rest come from the BSS whose SSID is hidden. Let's focus on the visible network, filtering out its BSSID:
Code:
wlan.ssid == transition
If we select one of the beacon-a frames and expand its checked options as shown in the following screenshot, we will see a vendor specific element of type "OWE Transition Mode".
This part is very important: the extension of this vendor-specific element shows the BSSID of the access point along with its SSID ("owe-hidden").
This vendor-specific element is one of the keys to OWE Transition Mode functioning - to connect to a transition AP, base stations first send a probe request to the open ESSID of the access point. Base stations that support OWE will check for the OWE transition mode element in the AP probe response, as well as any subsequent beacon frames transmitted by the AP. If the element is present, the station will then make a probe request for the hidden ESSID of the BSS to initiate a connection to it. Client devices that do not support OWE will ignore the OWE Transition mode element and simply connect to the open BSS.
Let's look at this process from the point of view of the station. We'll start by telling wpa_supplicant that our transient access point is treated as an open ESS by passing it the following configuration file:
Code:
# OWE network
network = {
ssid = "transition"
frequency = 2412
key_mgmt = NONE
}
Initialize wpa_supplicant using the following command and watch it connect to the hotspot in transient mode:
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-transition-open.conf
We can also see the station connecting to the AP from the AP's point of view:
We can use the following filter to isolate the connection process in Wireshark (replace your station's hardware address 02: 00: 00: 00: 01: 00).
Code:
wlan.addr == 02: 00: 00: 00: 01: 00 && wlan.addr == fe: e1: de: ce: a5: ed && wlan.fc.type == 0x0
As you can see in the screenshot above, the process is identical to what happens with an open network.
Now let's do the same analysis, this time passing wpa_supplicant a configuration file that tells it to treat our access point in transient mode as OWE ESS:
Code:
# OWE network
network = {
ssid = "transition"
frequency = 2412
key_mgmt = OWE
proto = RSN
ieee80211w = 2
pairwise = CCMP
}
You can see this process in action (from a client perspective) in the following screenshot, which shows the debug output generated by wpa_supplicant when it connects to the OWE Transition Mode hotspot.
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-transition-open.conf
In the screenshot above, wpa_supplicant first tries to connect to an open access point. It then learns that the open hotspot is actually an OWE transition mode network, and parses the ESSID of its hidden OWE BSS from a specific vendor tag. Finally, wpa_supplicant navigates to the hidden OWE BSS.
Output
The next and final post in this series will focus on the limitations of OWE.
So we came to the finish line, friends. Introducing the third part that concludes our exploration of attacks against WPA3. Today we will summarize and draw conclusions about OWE's ability to resist threats.
In terms of risk, OWE is virtually indistinguishable from an open protocol.
As a reminder, in Part 1 we established that the current wireless threat model is based on the following facts:
- The adoption of HTTPS is widespread. As a result, passive attacks have not worked reliably since 2005.
- HTTP Downgrade attacks have become largely obsolete due to the widespread use of HSTS.
- The creation of fake APs is still a problem as they can be used to carry out portal-based attacks and static content attacks (which HTTPS will not protect against).
Throughout our research, we identified two major OWE issues. These problems are described in the following subsections.
OWE does not provide a mechanism for access point authentication
As we mentioned in previous articles, OWE was not meant to complicate rogue access point attacks.
RFC requirements do not allow users to distinguish between encrypted and unencrypted connections. An analysis of RFC 8110 defining OWE specifications reveals an interesting solution. According to Section 6 of RFC 8110:
OWE is a replacement for 802.11 open authentication. Therefore, when OWE-compliant access points are found, users should not be shown any indication that the access point is secure, such as “padlock”, in the display of the access point name. To the user, the OWE SSID should look the same as the same as a normal open network.
In my personal opinion, widespread adoption of OWE will take years, and if attempts to abandon WEP become a sign of future success, it is unlikely that open WiFi will ever be completely forgotten. There is a reason why web browsers display a padlock when connecting to a server over HTTPS - users need to know when their data is secure and when it is being transmitted in its pure form.
Because RFC 8110 assumes that OWE does nothing to protect users from active attacks, displaying a lock icon can be confusing to users. Users who are not aware of the limitations of OWE may mistakenly believe that OWE offers robust protection against today's wireless threats.
It seems that device manufacturers took this issue into account and deliberately ignored RFC 8110 by displaying a distinctive icon (though not necessarily encrypting). For example, Android 9 on the Razer 3 allows users to differentiate between OWE and open hotspots:
However, it remains to be seen if this will be the case on all operating systems and devices.
Research methodology and results
In researching this topic, we have tried to stick to the scientific method.
Q: is OWE susceptible to attacks, and if so, how?
Hypothesis: OWE is susceptible to attacks
Experiment: we have broken it down into several stages, which are described below
Analysis: we analyzed the results
Conclusion: Our conclusion is that the hypothesis is correct and OWE does not provide significant advantages over open wireless networks.
Experiment
The experiment was broken down into the following stages:
- Trying to create a working OWE access point using hostapd
- Attempting to connect a station (wpa_supplicant) to an OWE access point
After confirming that the AP and station had implemented OWE correctly, we used Wireshark to inspect the traffic.
- An attempt was made to test conceptual attacks on the OWE access point.
We followed the same procedures when evaluating OWE.
Of these four phases, the first three actually turned out to be the most difficult and time consuming part of the entire project, mainly due to a lack of documentation. As a reminder, we started our research in April 2019. None of the configuration parameters required to create or connect to an OWE access point were publicly documented at the time. In fact, we ended up creating working configuration files for hostapd and wpa_supplicant by reverse engineering the hostap test suite, which consisted of over 100,000 lines of Python code. We then verified that our configurations were correct by following a process similar to that described in the second part of this series.
However, when we managed to overcome these problems, we were left with creating a fake hotspot that used OWE and not open WiFi. Thus, we would be able to prove our hypothesis.
OWE Evil Twin Attack
This walkthrough assumes that you have already completed the configuration steps in Part II:
From your owe-lab directory, create an OWE hotspot on wlan0 by copying the configuration file found in conf-files / hostapd-owe.conf to hostapd. Note that this is the same configuration file that we used in part two of this series. If you are wondering what this config file does, you can find a detailed explanation there.
Code:
./hostapd conf-files / hostapd.conf
Then confirm that hostapd created the OWE AP correctly as shown in the following screenshot (see Part II for a more detailed explanation of what we're looking for in Wireshark).
Then copy the configuration files from conf-files / wpa_supplicant-owe.conf to wpa_supplicant to connect wlan1 as a client device to the AP running on wlan0.
Code:
wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol
Then, using eaphammer, we create a twin of our OWE hotspot that runs on wlan0 (note that we are using wlan2 to create a fake hotspot).
Code:
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
The next tricky part is getting the station to work on wlan1 to connect to our fake access point running on wlan2. There are two ways to perform an attack:
Abuse of the 802.11 roaming process: only works when the station is already connected to the correct access point. We force the station to reconnect to a fake access point if our signal is stronger, or we force the station to connect to our point, denying access to the correct access point.
Network Selection Process Attack: Works when the station is not currently connected to any wireless network. We force the station to connect to our access point using the ESSID, which is in the preferred networks list (PNL) of the workstation.
If the target workstation is already connected to the AP, which means an attack on the 802.11 roaming process is most appropriate. However, OWE uses secure control frames, which prevents us from spoofing deauthentication packets to force station roaming [2]. Thus, we are forced to lure the station towards us, providing the most powerful signal.
The purpose of the action is not to prove that 802.11 roaming can be disrupted by an Evil Twin attack. We're going to illustrate this part of the experiment by simply disabling the correct access point that effectively simulates the consequences of a noisy attack or what happens if a station goes outside of a valid access point.
Code:
./hostapd conf-files / hostapd-owe.conf
When the correct access point is no longer available, the station running on wlan1 starts looking for another access point with the same ESSID to connect. Our Ewil Twin, running wlan2, responds to the request and the station connects to it, as shown in the next two screenshots.
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-owe.conf
Code:
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
Finally, we can check with Wireshark:
Code:
(wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol) && wlan.bssid == 00: 11: 22: 33: 44: 00
That's it - we successfully launched an attack on the OWE-protected network.
Proof of Concept Results: OWE Transition Mode
We also made similar attacks on OWE Transition mode. A detailed description of these conceptual attacks is not provided. However, our results should be sufficient to replicate. In addition, the EAPHammer Wiki provides instructions for performing AP attacks on OWE Transition Mode:
github.com
Output
The implementation of the OWE WiFi Alliance is the right move as it will help support encryption for unauthenticated wireless networks. However, by not providing access point authentication solutions, the OWE WiFi Alliance is unable to mitigate the threat of malicious attacks on open networks. Therefore, the OWE WiFi Alliance cannot mitigate the risk associated with unauthenticated wireless communications. The fact that the use of Mandatory Protected Management Frames (PMFs) is mandatory is a plus as it makes attacks on fake access points more difficult.
Everything new is well forgotten old. And with the new standards, nothing new was even invented. OWE is vulnerable. Q.E.D.
This is the question that researchers Gabriel Ryan and Steve Deret asked in early 2019. They ended up implementing several working proofs of conceptual attacks that they demonstrated at DEF CON Wireless Village last summer. This series of posts describes the research and findings, and discusses how OWE fits into the current wireless threat model.
This series of articles contains a lot of information. Thus, we have broken it down into three sections that are designed to meet the needs of both non-technical audiences and audiences with varying levels of technical proficiency.
Part I: How We Got Here - the introductory part (this is what you are reading now). Historical context and background information that demonstrates why this research matters. Suitable for any audience. From beginner to advanced. This is perhaps the most important post in the series.
Part II: Understanding OWE - Dive into the technical details of OWE and OWE Transition. Suitable for a technically advanced audience.
Part III. Concept Attack Validation and Basic Techniques. Technical demos and walkthroughs for concept attacks.
Introduction
In January 2018, the Wi-Fi Alliance announced the upcoming release of WPA3. One of the key features disclosed in this announcement was support for custom data encryption, which would address longstanding security issues that affect open wireless networks. It was widely speculated that Opportunistic Wireless Encryption (OWE) would be used to implement this feature, and this was later confirmed when WPA3 certification began in June 2018.
By early 2019, the WPA3 implementation of OWE had been renamed Wi-Fi Certified Extension and converted into an optional stand-alone standard to be released alongside WPA3. Nonetheless, despite its status as a non-mandatory hardware certification requirement, OWE continued to be a major source of inspiration for wireless professionals and enthusiasts. By Spring 2019, several major device manufacturers announced current or future support for OWE, including Samsung, Cisco, and Aruba Networks. One of the authors of the Aruba Networks blog called OWE "the most important WPA3-related feature".
The OWE hype began to infiltrate the media. This question intrigued the author of our article, Gabriel Ryan. And together with Denver security researcher Steve Darracotta, they decided to find out: "OWE is susceptible to abuse and attacks, and if so, how?"
The initial question quickly led to the next question - what exactly is OWE? We started by doing extensive basic research trying to understand OWE at a technical level and the problems it is designed to solve. Due to the lack of publicly available written documentation, we spent a huge amount of time watching thinly veiled vendor advertising speeches on YouTube. After about a week, we decided that the best option was to act like "real" researchers and read the RFC (and we did).
In the end, the RFC turned out to be the most useful source of information about the protocol, although we also benefited from some of the comments made by Dr. Maty Vanhoeuf about OWE during his recent WPA3 posts. From these last two sources, we were finally able to come to a working hypothesis - since OWE does not provide a means of verifying the identity of the access point, wireless networks protected by OWE are susceptible to the same rogue AP attacks that have affected open networks over the past 20 years.
We were not the first to put forward this hypothesis. However, as far as they knew, no one had ever tried to test this hypothesis by creating a working proof of a conceptual attack. The researchers thought this would be a good start.
In the end, we were able to implement several working tests of concept attacks (all related to abuse of 802.11 roaming and network selection):
- Open Evil Twin vs. OWE: We are demonstrating that it is possible to force client devices that use wpa_supplicant to connect to fraudulent open access. We are currently not sure if this is an implementation-specific issue or a problem with the protocol itself.
- OWE Evil Twin vs. OWE: We are demonstrating that it is possible to force client devices that use wpa_supplicant to connect to a rogue OWE hotspot.
OWE transition mode attacks. We demonstrate that OWE transition mode is susceptible to attacks from transition mode and open access points, but not OWE access points.
We have also confirmed that the use of secure management frames (PMF), which is mandated by OWE, makes it difficult for AP rogue attacks to be performed. However, we note that the introduction of a mandatory PMF will invalidate existing threat containment methods.
How did we get here
In the end, OWE turned out to be a disappointment - not because it didn't solve the problem it was supposed to solve, but because it was trying to solve the wrong problem. Let's discuss the current wireless threat model.
To understand the threat model, we need to remember history.
Hacking WiFi: A Brief History
The 802.11 standard was released in 1999. Within a year, it was adopted by many major device manufacturers. Hence it was accepted by the general public. The standard came with two initial versions: 802.11a and 802.11b.
Initially, wireless security came in two flavors: unencrypted "open" networks and networks protected by Wired Equivalent Privacy (WEP). Interestingly, of these two initial options, only open networks are still in use today. This seems counterintuitive, since "open" networks are less secure than WEP, even by modern standards. Why is this so?
The answer to this question has as much to do with psychology as it has with safety. In particular, it is a human factor engineering problem. Both WEP and WPA / 2 (its successor) were designed to encrypt network traffic. Yes, we also use them as authentication mechanisms, but that's only because there are no more options available (you "authenticate" to WiFi networks by successfully encrypting and decrypting traffic).
Both WEP and WPA / 2 require users to authenticate to establish encrypted connections. Using HTTPS as an analogy, imagine if users need to authenticate to download web content over encrypted HTTPS. Simply put: Imagine if you need to enter a password every time you want to use encrypted HTTPS to access a new website like Google. Obviously, if that were the case, most people would gravitate toward the plaintext HTTP for convenience. But because HTTPS is capable of providing encryption in a completely transparent way to the user, its distribution has become widespread.
OWE was designed to meet a similar need. The vast majority of public wireless networks are not encrypted because it has historically been impossible to encrypt wireless traffic in a transparent and unobtrusive way. If open networks can be compared to HTTP, then OWE is the IEEE's answer to HTTPS for wireless networks.
Initial threat model (1999 to early 2000s)
Let's rewind history a bit and look at some of the security issues that surfaced in 1999. It didn't take long before offline analysis of passwords and data became a major problem. As we mentioned, using WEP to provide encryption on public networks doesn't make sense from a usability standpoint. Consequently, most of the public wireless traffic of that era was transmitted in the clear. Remember that Wi-Fi traffic is ultimately a form of radio communication, and when you transmit Wi-Fi packets, they can be captured by anyone nearby as long as they are listening to you. Without encryption, anyone who captures these packets can also view the transmitted data. This includes passwords, credit card information, and other sensitive information.
By 2002, attackers had figured out that 802.11 provided little guidance on how to choose an access point. Instead, the implementation of the process was left to the discretion of the individual device manufacturers. The algorithms that were developed to achieve this goal did not provide a real means of verifying the identity of nearby access points, making the access points susceptible to mimic attacks known as Evil Twin.
In Evil Twin, an attacker masquerades as a trusted access point in order to forcibly connect nearby wireless devices to the attacker's equipment.
Initial Threat Mitigation Measures (early 2000s to 2012)
These early wireless attacks, along with other common PITM attacks of the period such as ARP Cache Poisoning, served as catalysts for widespread application-level encryption. Simply put: The state of unauthenticated wireless security won't improve anytime soon, so application developers have made a commitment to implement their own encryption, deployed at the higher layers of the protocol stack.
By the early 2000s, the use of encrypted application layer protocols (such as SSH and HTTPS) had become an accepted best practice in the technology sector. The widespread adoption of application-level encryption soon followed, effectively ending the golden age of passive eavesdropping attacks.
These application tier mitigation measures have also eliminated the threat of Evil Twin attacks. However, Evil Twin attacks became a problem again in 2009 after the discovery of the Moxie Marlinspike HTTP Downgrade Attack. This technique allows attackers to use Evil Twin attacks to downgrade HTTPS connections to HTTP plaintext and has remained a serious and widespread threat for half a century.
Malicious attacks on access points remained the main threat to open wireless networks until 2012, when HTTP Strict Transport Layer Security (HSTS) was introduced. In fact, HSTS has not been widely adopted for a long time. Later, the Pinning certificate was accepted.
Current wireless security threat model
So. Our historical excursion ends, and we come to today's problems. Most public networks still use open Wi-Fi. HTTP downgrade attacks are largely irrelevant due to the widespread use of HSTS in the most important areas: online banking, email providers, and in general in any matter where a minimum level of security is important.
What works against open networks:
- The attacker creates a malicious access point to establish PITM and injects the payload into static web content. An attacker doesn't even try to downgrade HTTPS and doesn't need to - problems with mixed content are widespread.
- The attacker creates a malicious hotspot to send the victim to the authorization portal and uses the portal to install malware or to collect credentials using social engineering.
- An attacker can trick a user into installing a rogue CA certificate.
Finally, 20 years later, the Wi-Fi Alliance decides to deploy encryption for public Wi-Fi traffic. They call this new protocol Opportunistic Wireless Encryption (OWE).
In the next two articles in this series, we will look at how OWE works at a technical level, discuss our research methodology, and demonstrate proof of conceptual attacks against OWE.
The second part of our extensive exploration of attacks against WPA3 is on the air and today we will tell you how OWE works.
OWE is an encryption tool for open networks. And this is something that has not been in the 802.11 standard over the past 20 years. OWE is assumed to be indistinguishable from open Wi-Fi from the user's point of view - the user simply connects to the secure OWE network, and after a short key exchange, all subsequent communication is encrypted.
At first glance, this sounds great - until you find that OWE only protects against passive attacks.
OWE follows a five-step process that begins with network discovery and ends with the transfer of encrypted data between the client and the access point. We'll go over each of these steps in the following sections, and also discuss important additional information.
Sandbox
So, I've prepared a set of installation scripts to create a test environment.
Please note that these installation scripts are for Kali 5.3.7 and I have no plans to support them or provide support for any other operating system. The software is not static, this is in case you are reading an article in 2025 and the install script does not work, well ... you know ...
To create a test environment, first use git clone to get scripts from Github:
Code:
git clone https://github.com/s0lst1c3/owe-lab
Then run the install script:
Code:
cd owe-lab
./lab-setup
If the installation script completed successfully, you should have a directory that looks like this:
As you can see in the screenshot above, the installation script will create a test environment with each of the following components:
- Virtual access point and base station
- Wireshark Dev Branch
- EAPHammer
- AP and station configuration files
- Hardware simulator control scripts
I will briefly describe each of these components in the following sections.
Virtual access point and base station
These are only the latest versions of wpa_supplicant and hostapd with dependencies enabled and compiled with OWE and simultaneous peer authentication (SAE) support.
Wireshark Dev Branch
We will use Wireshark for both analysis and verification that everything in the lab is working as expected. For OWE and SAE support, we need the latest version of Wireshark, which can only be compiled from source. Luckily, the script will take care of this.
EAPHammer
OWE-enabled wireless attack suite for proof-of-concept (spin-off of this study).
AP and station configuration files
The test environment includes a conf-files directory containing a set of wpa_supplicant and hostapd configuration files for open networks, OWE and OWE Transition modes. At the time of our research, the OWE implementation in hostapd was still under development. Consequently, none of the configuration parameters required to create or connect to an OWE access point have been documented. With no publicly available documentation, we ended up referring to the hostap unit test whitebox code overview (over 100.00 lines of code) to create this relatively simple set of working configuration files.
Hardware simulator control scripts
The mac80211 Wi-Fi stack (the kernel subsystem that works with Wi-Fi) comes with a kernel module named mac80211_hwsim that can be used to simulate an arbitrary number of virtual wireless interfaces and pass virtual WiFi traffic between them. We exclusively use mac80211_hwsim.
To enable the mac80211_hwsim kernel module, use modprobe as shown in the example below. The radios variable is used to specify the number of virtual interfaces to create.
Code:
modprobe mac80211_hwsim radios = 3
Alternatively, you can simply run the enable-hwsim script:
Code:
./enable-hwsim
After enabling mac80211_hwsim, you can view the interfaces you created using the iwconfig command. In Kali (and any other Debian-based distribution for that matter), newly created interfaces will be created using the wlanX model, where X is a positive integer. You will also notice a new interface named hwsim0. It is actually a tap interface that can be used to capture traffic passing between wlanX interfaces.
To destroy the virtual environment, use the rmmod command, as shown in the following example:
Code:
rmmod mac80211_hwsim
Reference Information
Before we proceed, we need to go through some background information. If you are unfamiliar with how 802.11 works, I recommend checking out the following blog post:
Modern Wireless Tradecraft Pt I
Basic Rogue AP Theory — Evil Twin and Karma Attacks
In addition, you need to briefly cover the following concepts:
Type Length Encoding (TLV)
Information elements
Elements of a Reliable Safety Network (RSN)
Authentication Key Management (AKM) Selectors
Element Encoding and Type-Length-Value (TLV)
Type-Length-Value (TLV) is an encoding scheme used in communications protocols to add information to individual messages (in this case, packets). TLV relies on data structures called items.
Information Elements (IEs) are elements used to add metadata to Management Frames (MFs). Beacons, test requests, test responses, and communication frames are created by adding IE to each other.
Let's focus on beacon frames. As you may recall, frames are periodically transmitted by access points (APs) to communicate their presence and capabilities to neighboring stations. IE is the data structure that makes this possible. To illustrate this, let's open a beacon-a frame in Wireshark and see how it works. Here I am using the following capture example from the wiki:
https://wiki.wireshark.org/SampleCa...&do=get&target=Network_Join_Nokia_Mobile.pcap
The very first packet to be captured is the beacon frame. Selecting this frame in Wireshark opens three drop-down menus (depending on the Wireshark configuration, these may already be expanded):
Expanding the bottom-most menu in the screenshot above opens up two new menus:
We are interested in a drop-down list marked "Parameters with tags". Expanding the Tagged Options menu, you will see a list of IE, which Wireshark is known as "tags":
To see how 802.11 uses TLV encoding in action, click the SSID Parameter Set IE to expand it as shown in the following screenshot:
The first IE field (tag number) indicates its data type, which in this case is the “SSID Parameter Set”. The next IE field is the length field of its value, which in this case is 9. The last IE field is its value, which we know is the 9 byte SSID because of the type and length fields in IE.
Most of the beacon-a frame metadata is stored in IE, which follows this Type-Length-Value format. Other control frames are similar.
OWE Phase 1: Network Discovery
Why have we talked so much about Type-Length-Value (TLV) coding and Information Elements (IE)? They are very important for understanding how OWE works at the package level. To see this, let's take a look at the OWE authentication process in Wireshark.
Start by enabling the simulated WiFi interfaces using the enable-hwsim script provided in the test environment:
Code:
./enable-hwsim
Then instruct Network Manager to relinquish control of your hwsim0, wlan0, and wlan1 interfaces and bring hwsim0, wlan0, and wlan1 interfaces online:
Code:
nmcli device set wlan0 managed off
nmcli device set wlan1 managed off
nmcli device set hwsim0 managed off
ifconfig wlan0 up
ifconfig wlan1 up
ifconfig hwsim0 up
Then open Wireshark from your environment directory and set it to listen on the hwsim0 interface as shown in the following screenshot:
Then create an instance of the OWE access point using hostapd. We will do this by providing hostapd with the following configuration file, which can be found in the conf-files directory:
Code:
# use interface wlan0
interface = wlan0 # set ssid to "owe"
ssid = owe # manually set BSSID
bssid = a6: 44: ce: d8: 61: 6f # set channel to 1
channel = 1 # require Protected Management Frames (PMF)
ieee80211w = 2 # enable full IEEE 802.11i / RSN
wpa = 2 # set key management element to OWE
wpa_key_mgmt = OWE # set RSN pairwise cipher to CCMP
rsn_pairwise = CCMP
To start the access point, simply pass hostapd the appropriate configuration file, as shown in the following command:
Code:
./hostapd conf-files / hostapd-owe.conf
Back in the Wireshark window, filter the beacon-a frames from your AP using the following filter:
Code:
wlan.fc.subtype == 0x8 && wlan.bssid == a6: 44: ce: d8: 61: 6f
After applying the filter, select one of the packages and expand the Tagged Options menu as shown in the following screenshot:
Then expand the RSN Information tag as shown in the following screenshot:
Then expand the "Authentication Key Management List> Authentication Key Management Package (AKM)" tags as shown in the following screenshot:
Here's the important part: notice the meaning of the Key Management Type (AKM) item. Access Points (APs) that support OWE advertise their protocol support using an Authentication and Key Management (AKM) Suite selector that is added to the RSN element of all beacons and test response frames that the AP issues. Base stations that support OWE recognize the presence of this element and use it to identify neighboring access points that support OWE.
Now let's take a look at what happens when we connect the base station to an access point. To do this, we will use the wpa_supplicant binary of our environment with the following configuration file:
Code:
# OWE network
network = {
ssid = "owe" # connect to SSID "owe"
frequency = 2412 # connect to channel 1 (center freq 2412)
key_mgmt = OWE # use OWE
proto = RSN # use RSN
ieee80211w = 2 # use Protected Management Frames (PMF)
pairwise = CCMP # set pairwise cipher suite to CCMP
}
To connect to the OWE access point, pass wpa_supplicant the appropriate configuration file, as shown in the following command:
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-owe.conf
The base station recognizes the access point as OWE-compliant and uses it to initiate authentication in an open system (authentication in an open system is just a fancy way of saying "authentication is not really happening"). You can see the authentication process in Wireshark using the following filter:
Code:
wlan.fc.type_subtype == 0xb
OWE Phase 2: Association
Once the client device has authenticated the open system with an access point (AP), the client and the AP proceed to the 802.11 association process. During the association, there is a Diffie-Hellman (DH) OWE key exchange and a four-way handshake.
Remember that OWE is a form of public key cryptography - both the client and the AP must be able to exchange DH keys with each other in order to communicate securely. As in the network discovery phase, this key exchange is facilitated by information elements (IEs) that are added to the association request and response frames. When the base station sends an association request to the access point, a DH parameter element is added to the probe request frame. This DH parameter element contains the base station's public key. The access point then responds with an association response frame, to which its public key is appended to its own DH parameter element.
Let's walk through this process by isolating the association process using the following filter (which filters to request association and response frames):
Code:
wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1
If we select the first package displayed (which is an association request), we notice that it contains an extended tag named "OWE Diffie-Hellman Option" as shown in the following screenshot.
The OWE Diffie-Hellman Paramater tag extension exposes the base station's public key:
Likewise, selecting the appropriate association response frame also reveals the presence of an extended tag named OWE Diffie-Hellman Parameter that contains the public key of the access point.
The process of exchanging public keys in this manner is known as Diffie-Hellman (DH) key exchange.
OWE Phase 3: Post-Association
Once the client and AP have completed the pairing process as well as the DH key exchange, a paired master key (PMK) is generated. The PMK is assigned a unique identifier known as the Paired Master Key Identifier (PMKID). The AP then initiates a four-way handshake with the client, in which the PMK is used to generate encryption keys.
You can see how this handshake happens in Wireshark by isolating EAPOL packets with the following filter:
EAPOL
OWE Phase 4: Data Transfer
At this point, the client and the AP have established an encrypted connection with each other, which will be used to protect all subsequent data transmission.
Note that there is one thing that is clearly missing from this whole process: certificates.
OWE transient
OWE Transition was designed to provide open network access for both new OWE-enabled devices and legacy devices that do not support OWE.
This is how it works. Access points configured to use OWE transition mode actually serve two Basic Service Sets (BSS) at the same time. The first BSS is an open access point with a visible ESSID. The second BSS is configured to use OWE and is assigned a randomly generated ESSID that is different from the open access point ESSID. This second OWE is also hidden, which means it can only be discovered by directed test requests.
To create an access point that matches this configuration, we use a configuration file similar to the one shown below. Note that this configuration file installs two BSSs of the same wireless interface - one open and one with OWE support. The owe_transition_ssid and owe_transition_bssid configuration parameters are used to link two BSSs. If this config file seems confusing, don't be afraid to move on. It will make more sense after learning what the AP and station are doing in Wireshark.
Code:
# general --- interface = wlan0
ssid = owe-hidden
bssid = a6: 44: ce: d8: 61: 6f
channel = 1
ignore_broadcast_ssid = 1
ieee80211w = 1 # owe_transition --- wpa = 2
wpa_key_mgmt = OWE
rsn_pairwise = CCMP
owe_transition_ssid = "transition"
owe_transition_bssid = fe: e1: de: ce: a5: ed # populate_owe_transition_open_bss --- bss = wlan0_0
ssid = transition
bssid = fe: e1: de: ce: a5: ed
owe_transition_ssid = "owe-hidden"
owe_transition_bssid = a6: 44: ce: d8: 61: 6fwpa = 2
wpa_key_mgmt = OWE
rsn_pairwise = CCMP
Let's take a look at what this config file actually does by using it to create an access point in OWE Transition mode and then analyzing it in Wireshark. Start by running hostapd with the configuration file shown in the following command:
Code:
./hostapd conf-files / hostapd-owe-transition.conf
Then filter the beacon-a frames in Wireshark using the following filter:
Code:
wlan.fc.type_subtype == 0x8
You should see a series of beacon-a frames transmitted by two different access points as shown in the following screenshot.
Note that about half of these beacons come from the BSS with the SSID set to "hop", while the rest come from the BSS whose SSID is hidden. Let's focus on the visible network, filtering out its BSSID:
Code:
wlan.ssid == transition
If we select one of the beacon-a frames and expand its checked options as shown in the following screenshot, we will see a vendor specific element of type "OWE Transition Mode".
This part is very important: the extension of this vendor-specific element shows the BSSID of the access point along with its SSID ("owe-hidden").
This vendor-specific element is one of the keys to OWE Transition Mode functioning - to connect to a transition AP, base stations first send a probe request to the open ESSID of the access point. Base stations that support OWE will check for the OWE transition mode element in the AP probe response, as well as any subsequent beacon frames transmitted by the AP. If the element is present, the station will then make a probe request for the hidden ESSID of the BSS to initiate a connection to it. Client devices that do not support OWE will ignore the OWE Transition mode element and simply connect to the open BSS.
Let's look at this process from the point of view of the station. We'll start by telling wpa_supplicant that our transient access point is treated as an open ESS by passing it the following configuration file:
Code:
# OWE network
network = {
ssid = "transition"
frequency = 2412
key_mgmt = NONE
}
Initialize wpa_supplicant using the following command and watch it connect to the hotspot in transient mode:
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-transition-open.conf
We can also see the station connecting to the AP from the AP's point of view:
We can use the following filter to isolate the connection process in Wireshark (replace your station's hardware address 02: 00: 00: 00: 01: 00).
Code:
wlan.addr == 02: 00: 00: 00: 01: 00 && wlan.addr == fe: e1: de: ce: a5: ed && wlan.fc.type == 0x0
As you can see in the screenshot above, the process is identical to what happens with an open network.
Now let's do the same analysis, this time passing wpa_supplicant a configuration file that tells it to treat our access point in transient mode as OWE ESS:
Code:
# OWE network
network = {
ssid = "transition"
frequency = 2412
key_mgmt = OWE
proto = RSN
ieee80211w = 2
pairwise = CCMP
}
You can see this process in action (from a client perspective) in the following screenshot, which shows the debug output generated by wpa_supplicant when it connects to the OWE Transition Mode hotspot.
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-transition-open.conf
In the screenshot above, wpa_supplicant first tries to connect to an open access point. It then learns that the open hotspot is actually an OWE transition mode network, and parses the ESSID of its hidden OWE BSS from a specific vendor tag. Finally, wpa_supplicant navigates to the hidden OWE BSS.
Output
The next and final post in this series will focus on the limitations of OWE.
So we came to the finish line, friends. Introducing the third part that concludes our exploration of attacks against WPA3. Today we will summarize and draw conclusions about OWE's ability to resist threats.
In terms of risk, OWE is virtually indistinguishable from an open protocol.
As a reminder, in Part 1 we established that the current wireless threat model is based on the following facts:
- The adoption of HTTPS is widespread. As a result, passive attacks have not worked reliably since 2005.
- HTTP Downgrade attacks have become largely obsolete due to the widespread use of HSTS.
- The creation of fake APs is still a problem as they can be used to carry out portal-based attacks and static content attacks (which HTTPS will not protect against).
Throughout our research, we identified two major OWE issues. These problems are described in the following subsections.
OWE does not provide a mechanism for access point authentication
As we mentioned in previous articles, OWE was not meant to complicate rogue access point attacks.
RFC requirements do not allow users to distinguish between encrypted and unencrypted connections. An analysis of RFC 8110 defining OWE specifications reveals an interesting solution. According to Section 6 of RFC 8110:
OWE is a replacement for 802.11 open authentication. Therefore, when OWE-compliant access points are found, users should not be shown any indication that the access point is secure, such as “padlock”, in the display of the access point name. To the user, the OWE SSID should look the same as the same as a normal open network.
In my personal opinion, widespread adoption of OWE will take years, and if attempts to abandon WEP become a sign of future success, it is unlikely that open WiFi will ever be completely forgotten. There is a reason why web browsers display a padlock when connecting to a server over HTTPS - users need to know when their data is secure and when it is being transmitted in its pure form.
Because RFC 8110 assumes that OWE does nothing to protect users from active attacks, displaying a lock icon can be confusing to users. Users who are not aware of the limitations of OWE may mistakenly believe that OWE offers robust protection against today's wireless threats.
It seems that device manufacturers took this issue into account and deliberately ignored RFC 8110 by displaying a distinctive icon (though not necessarily encrypting). For example, Android 9 on the Razer 3 allows users to differentiate between OWE and open hotspots:
However, it remains to be seen if this will be the case on all operating systems and devices.
Research methodology and results
In researching this topic, we have tried to stick to the scientific method.
Q: is OWE susceptible to attacks, and if so, how?
Hypothesis: OWE is susceptible to attacks
Experiment: we have broken it down into several stages, which are described below
Analysis: we analyzed the results
Conclusion: Our conclusion is that the hypothesis is correct and OWE does not provide significant advantages over open wireless networks.
Experiment
The experiment was broken down into the following stages:
- Trying to create a working OWE access point using hostapd
- Attempting to connect a station (wpa_supplicant) to an OWE access point
After confirming that the AP and station had implemented OWE correctly, we used Wireshark to inspect the traffic.
- An attempt was made to test conceptual attacks on the OWE access point.
We followed the same procedures when evaluating OWE.
Of these four phases, the first three actually turned out to be the most difficult and time consuming part of the entire project, mainly due to a lack of documentation. As a reminder, we started our research in April 2019. None of the configuration parameters required to create or connect to an OWE access point were publicly documented at the time. In fact, we ended up creating working configuration files for hostapd and wpa_supplicant by reverse engineering the hostap test suite, which consisted of over 100,000 lines of Python code. We then verified that our configurations were correct by following a process similar to that described in the second part of this series.
However, when we managed to overcome these problems, we were left with creating a fake hotspot that used OWE and not open WiFi. Thus, we would be able to prove our hypothesis.
OWE Evil Twin Attack
This walkthrough assumes that you have already completed the configuration steps in Part II:
From your owe-lab directory, create an OWE hotspot on wlan0 by copying the configuration file found in conf-files / hostapd-owe.conf to hostapd. Note that this is the same configuration file that we used in part two of this series. If you are wondering what this config file does, you can find a detailed explanation there.
Code:
./hostapd conf-files / hostapd.conf
Then confirm that hostapd created the OWE AP correctly as shown in the following screenshot (see Part II for a more detailed explanation of what we're looking for in Wireshark).
Then copy the configuration files from conf-files / wpa_supplicant-owe.conf to wpa_supplicant to connect wlan1 as a client device to the AP running on wlan0.
Code:
wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol
Then, using eaphammer, we create a twin of our OWE hotspot that runs on wlan0 (note that we are using wlan2 to create a fake hotspot).
Code:
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
The next tricky part is getting the station to work on wlan1 to connect to our fake access point running on wlan2. There are two ways to perform an attack:
Abuse of the 802.11 roaming process: only works when the station is already connected to the correct access point. We force the station to reconnect to a fake access point if our signal is stronger, or we force the station to connect to our point, denying access to the correct access point.
Network Selection Process Attack: Works when the station is not currently connected to any wireless network. We force the station to connect to our access point using the ESSID, which is in the preferred networks list (PNL) of the workstation.
If the target workstation is already connected to the AP, which means an attack on the 802.11 roaming process is most appropriate. However, OWE uses secure control frames, which prevents us from spoofing deauthentication packets to force station roaming [2]. Thus, we are forced to lure the station towards us, providing the most powerful signal.
The purpose of the action is not to prove that 802.11 roaming can be disrupted by an Evil Twin attack. We're going to illustrate this part of the experiment by simply disabling the correct access point that effectively simulates the consequences of a noisy attack or what happens if a station goes outside of a valid access point.
Code:
./hostapd conf-files / hostapd-owe.conf
When the correct access point is no longer available, the station running on wlan1 starts looking for another access point with the same ESSID to connect. Our Ewil Twin, running wlan2, responds to the request and the station connects to it, as shown in the next two screenshots.
Code:
./wpa_supplicant -i wlan1 -c conf-files / wpa_supplicant-owe.conf
Code:
./eaphammer -i wlan2 --captive-portal --auth owe --essid owe
Finally, we can check with Wireshark:
Code:
(wlan.fc.type_subtype == 0xb || wlan.fc.type_subtype == 0x0 || wlan.fc.type_subtype == 0x1 || eapol) && wlan.bssid == 00: 11: 22: 33: 44: 00
That's it - we successfully launched an attack on the OWE-protected network.
Proof of Concept Results: OWE Transition Mode
We also made similar attacks on OWE Transition mode. A detailed description of these conceptual attacks is not provided. However, our results should be sufficient to replicate. In addition, the EAPHammer Wiki provides instructions for performing AP attacks on OWE Transition Mode:
s0lst1c3/eaphammer
Targeted evil twin attacks against WPA2-Enterprise networks. Indirect wireless pivots using hostile portal attacks. - s0lst1c3/eaphammer
Output
The implementation of the OWE WiFi Alliance is the right move as it will help support encryption for unauthenticated wireless networks. However, by not providing access point authentication solutions, the OWE WiFi Alliance is unable to mitigate the threat of malicious attacks on open networks. Therefore, the OWE WiFi Alliance cannot mitigate the risk associated with unauthenticated wireless communications. The fact that the use of Mandatory Protected Management Frames (PMFs) is mandatory is a plus as it makes attacks on fake access points more difficult.
Everything new is well forgotten old. And with the new standards, nothing new was even invented. OWE is vulnerable. Q.E.D.