11–20 of 31 posts
The next time I update (wifi) routers I'm responsible for, I think I'm going to go fully Internet Only DMZ, and Wireguard 'VPN' for entry to the LAN.
That sounds nice on paper, but will make common things like accessing Plex-servers from apps on the set-top box, Chromecasting and what not a royal pain in the ass.
The next time I update (wifi) routers I'm responsible for, I think I'm going to go fully Internet Only DMZ, and Wireguard 'VPN' for entry to the LAN.
That sounds nice on paper, but will make common things like accessing Plex-servers from apps on the set-top box, Chromecasting and what not a royal pain in the ass.
Earlier quoted context omitted.
That sounds nice on paper, but will make common things like accessing Plex-servers from apps on the set-top box, Chromecasting and what not a royal pain in the ass.
I thought this would be the case, but I have most of my WiFi-enabled devices using WireGuard, and don't have a problem accessing my self-hosted services, nor with casting. This is the case even with phones using WireGuard. I can cast, use Jellyfin, and cast from Jellyfin just fine. edit: I should mention that I don't have an internet-only DMZ, just WireGuard for the LAN.
Earlier quoted context omitted.
I thought this would be the case, but I have most of my WiFi-enabled devices using WireGuard, and don't have a problem accessing my self-hosted services, nor with casting. This is the case even with phones using WireGuard. I can cast, use Jellyfin, and cast from Jellyfin just fine. edit: I should mention that I don't have an internet-only DMZ, just WireGuard for the LAN.
I can't get any casting to work when my phone is connected with WireGuard. I have exclude private IP's on for the one I'm connected to. It'll show for instance in the YouTube app but not actually be able to cast. Disabling VPN and retrying works immediately.
Possibly had to do something on the OpenWRT side, as well, but it's been a while since I initially configured my network to work with WireGuard.
Earlier quoted context omitted.
I thought this would be the case, but I have most of my WiFi-enabled devices using WireGuard, and don't have a problem accessing my self-hosted services, nor with casting. This is the case even with phones using WireGuard. I can cast, use Jellyfin, and cast from Jellyfin just fine. edit: I should mention that I don't have an internet-only DMZ, just WireGuard for the LAN.
I can't get any casting to work when my phone is connected with WireGuard. I have exclude private IP's on for the one I'm connected to. It'll show for instance in the YouTube app but not actually be able to cast. Disabling VPN and retrying works immediately.
Earlier quoted context omitted.
Since the bug is apparently in FullMAC devices, it would be a firmware fix in most cases (unless someone is running a FullMAC device as SoftMAC for whatever reason). Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned: I remember reading that many FullMAC devices contain their own firmware in a ROM and have some room in on-chip RAM for patches (…
Thanks for your detailed post. > Also, the boundaries between firmware, hardware and (driver) software are pretty murky as far as Wi-Fi drivers are concerned Yeah, this is why I ask if it can be fixed via software. I've been utterly surprised at the amount of bugs that exist in firmware but can be mitigated on the seemingly software-side of things. I have a device that used the brcmfmac driver on Linux until today, a…
No need to shelve the device, just don't treat WiFi as a "trusted zone" and use better encryption on top of WPA2. You should anyway, and this vulnerability is just another small reason why. What this vulnerability does -- as I understand it -- is, when a device dissociates with the network, send the rest of the tx buffer with a zero'd out encryption key. And thus leaks a small amount of data. Not good, however if you apply common best practices to your network I wouldn't lose any sleep over it.
An interesting attack on WPA2 on unpatched devices. This reminds me of the WPS reaver attack, which is a complete facepalm from an implementation perspective. Only 11,000 possible combinations, and trying 1 key every other second would net you the WPA password in "In 2011, a security researcher named Stefan Viehböck discovered a flaw in this implementation. The concept he introduced was based on the following facts:…
An attacker can trigger a dissociation between the device and the access point. The dissociation causes the device to zero its temporary encryption key called the TK (transient key), which is the key used to encrypt traffic between the device and the access point. Unfortunately, some data frames still on the device could then be encrypted with this zero key and sent anyway. Because the key is known to be zero, the attacker can decrypt these few data frames (a couple of kilobytes) trivially. Since the attacker can trigger this at will, they can leak an unbounded amount of data.
It's essentially a race condition in hardware between clearing keys and finishing sending off the last few packets inside the transmission buffer. Nasty!
This is going to require you to patch your firmware.
An interesting attack on WPA2 on unpatched devices. This reminds me of the WPS reaver attack, which is a complete facepalm from an implementation perspective. Only 11,000 possible combinations, and trying 1 key every other second would net you the WPA password in "In 2011, a security researcher named Stefan Viehböck discovered a flaw in this implementation. The concept he introduced was based on the following facts:…
Yea makes you wonder about the bozos at Wi-Fi Alliance who designed that shit... How can you make a blunder like that?
An interesting attack on WPA2 on unpatched devices. This reminds me of the WPS reaver attack, which is a complete facepalm from an implementation perspective. Only 11,000 possible combinations, and trying 1 key every other second would net you the WPA password in "In 2011, a security researcher named Stefan Viehböck discovered a flaw in this implementation. The concept he introduced was based on the following facts:…
Best of all, WPS was enabled by default on most access points and there was no delay on retries.
What makes it even worse is this happened after the whole WEP debacle. You'd think the Wi-Fi Alliance would do some security auditing, but they were obviously more focused on collecting certification fees.