I work on https://supernetworks.org/. We propose a solution to these flaws with per-device VLANs and encourage per-device passwords as well.
More practically the risk for these attacks is as follows. A simple password makes sense for easy setup on a guest network, that's treated as untrusted. These passwords can probably be cracked from sniffing a WPA2 key exchange -- who cares says the threat model, the network is untrusted. But this attack lets the insecure network pivot out into the secure one.
I don't believe this is true. I expect that what's going on there is the WAN and LAN ports on the switch [0] are in separate bridges.
Why do you believe that they're using VLANs behind the scenes? It seems silly to add and remove a whole-ass VLAN tag to traffic based on what port it comes in on. Do you have switch chip or other relevant documentation that indicates that this is what's going on?
[0] or WAN and LAN interfaces, if the ports are actually separate, entirely-independent interfaces, rather than bound up in a switch
That said, this is in no way my area of expertise.
My concern is doing it asynchronously against things when no one is watching.
Basically it takes turn being the client and the AP both so that it can get the traffic from both. It is an evil twin attack doubled.
It might have broken EAP TLS.
If your wifi is off when you are not using it and you are not getting denial of serviced while using it and you have only one Mac for your SSID, this attack is not occuring.
Some people also have passwords easy to break. Friend of mine literally had "hunter22" as WiFi password.
The problem is not wardrivers. The problem is your neighbors running 24x7 cyber operations. It happens everywhere. When I moved to a house there was a persistent attacker, and finally I setup my own key and authentication infrastructure.
They broke everything.
Finally I had to go EAP TLS and rotate certificates every three months.
Evil twin attack that keeps switching sides... The first of its kind, soon to be automated into a single button if it isn't already.
Does the temporal key mechanisms prevent them from taking a key they denial of serviced their way to while I was work -- do the temporal mechanisms prevent them from sniffing all my packets when I get home. They will not use it to get data during the denial of service.... But if they can get that radius key and use it five hours later during some backups or something...
That is the question.
Both an apartment you lived in and a house you moved to had neighbors who cracked your WPA3 network and compromised your infrastructure?
Also: You use EAP TLS on your home network but not SSH keys?
You still have to be able to authenticate to some network: the spoofing only allows users who can access one network to MITM others, it doesn't allow somebody with no access to do anything.
In practice a lot of businesses have a guest network with a public password, so they're vulnerable. But very few home users do that.
I have been relying on EAP TLS via wifi so my phones could upload their photos and videos to Nextcloud.It was way cheaper than doing it via AWS, which is what I used to do and used ethernet LAN connections only. If this works asynchronously across time to allow authentication to my network which uses EAP TLS, will knock me out of being able to use Nexctloud on my mobile devices since plugging an ethernet in after I take photos is too cumbersome to do very often.
I love Nextcloud, but do not want to pay Amazon for EC2 etc.
My read is this allows them to mimic both client and access point to assemble the handshake and obtain radius authentication. Rather than have to verify a certificate on the client or crack complex passwords, they pretend to the client sending the response it sends when the certificate is verified. Then they switch MAC to the SSID MAC and send the next part to the client. Previous evil twin attacks were one sided rather than basic frame assemblers.
I read that paper as describing a successful reconstruction of the Radius authentication handshakes at layer 2 after the fact for use later rather than caring about actual certificate validations. Basically handing a three letter agency quality tool to the Kali Linux fan club.
I am hoping I read it wrong,
I would put that nextcloud instance on a private/vpn IP and not expose it. For the letsencrypt you can use DNS based approval. Cloudflare DNS is pretty easy to configure for example, they also support setting DNS records for private IPs which I understand is not standard. (If it's on a private IP you don't strictly need HTTPS anyway). Wireguard is ideal for this kind of thing and it works well on mobile as well.
If the above quoted piece is the entirety of your requirements there are a lot of other ways to solve the same issue. Tunnels, reverse proxies etc.
EDIT: Letsencrypt just recently add a new authentication method which uses a one time TXT entry into your DNS record.
> We verified that an attacker, having intercepted the first RADIUS packet sent from the enterprise AP, can brute-force the Message Authenticator and learn the AP passphrase.
I thought RADIUS fundamentally negotiates based on a PSK between the AP and the RADIUS box, which the attacker doesn't have? They're saying this gives you the ability to brute force that PSK, but if the PSK isn't weak (e.g. a dictionary word) that's hopeless.
Are you talking about the secret shared between the NAS and the RADIUS server? It's only used to scramble some attributes (like MS-MPPE-Send-Key), but not all of them. Message-Authenticator is one that's not scrambled. Looking at this FreeRADIUS dictionary file I have, I see 42 out of ~6000 attributes that are scrambled.
Anyway, yeah, if you have a bigass shared secret, it's going to be infeasible to guess. I'm pretty sure that the long-standing very, very strong suggestion for operators has been something like "If you don't co-locate your RADIUS server and your NAS, then you really need have a bigass shared secret, and probably want to be using something like IPSec to secure the connection between the two." [0][1]
[0] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.3.3>
[1] <https://datatracker.ietf.org/doc/html/rfc3579#section-4.2>