31–40 of 201 posts
Shouldn't it be possible to only enable “Always Trust.” in the "X.509 Basic Policy" setting, instead of allowing the certificate to be used for everything(including SSL)?
TS information over wifi? Ok. Have fun with that. Im sure it is legally possible somehow, but it just creates a ridiculously large attack surface. And the internal hassles, making sure connected machines are inside defined perimeters ... just run some wires. It isnt like people need to be reading classified stuff on the treadmill.
[0]: https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...
Earlier quoted context omitted.
It's not unusual to run multiple APs on a single SSID. Your scheme doesn't work for that without coordination between the APs. Also, it means replacing an AP would require reconfiguring all the clients.
Couldn't it just fall back to the password version like it does every time now? Like optionally use the keys if present if not renegotiate
I want to know why WPA3 doesn't have a mode where a password is used for the initial connection , but then the client and AP generate a keypair and each store their half and use that for all future connections. For all future connections, the AP can validate every client, and the client can validate that it is connecting to the same AP. The AP could have an interface to 'revoke' access to any single client if necessa…
It's not unusual to run multiple APs on a single SSID. Your scheme doesn't work for that without coordination between the APs. Also, it means replacing an AP would require reconfiguring all the clients.
The parent suggestion is perfectly sound. More user-friendly means to mint certs would be grand. The caveat is that, if you can mint a cert from a low security password, what's to keep an attacker from attacking the password directly, rather than the cert? It might not let them snoop traffic, but it'd still let them on with the password.
> Toggle the switch on the Smallstep RADIUS Root CA to enable Full Trust. The Smallstep RADIUS Root CA is now trusted. What could possibly go wrong? How do you do this without trusting some external CA?
FreeRadius can help:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
Earlier quoted context omitted.
Couldn't it just fall back to the password version like it does every time now? Like optionally use the keys if present if not renegotiate
I'm guessing that's going to be an issue for handoffs between APs. Think walking around a multi-story office on a Wi-Fi call. Now picture 30 APs and 100 people on wifi calls/VoIP etc. with DHCP recycling addresses, randomized MACs and so forth.
A middle ground in complexity is WPA3 with a unique passphrase per VLAN, which allows grouping of devices by risk, or even giving each device a unique identity for access control and traffic management. OSS golang reference code is available, https://news.ycombinator.com/item?id=38402289 VLAN tagging per SSID is a valid approach as well if a router supports it. Thats a lot stronger than how many routers implement the…
My home network is so small I just use MAC VLAN policies on my managed switch. Same SSID and PSK for all devices makes it easy and they all go off onto the untrusted VLAN by default.
I'm honestly not sure if the second attack would work or if it would be AP specific, but I imagine most Wifi to wifi traffic through the same AP does not make a round trip through the Ethernet port. This wouldn't be an issue if the AP itself was applying and enforcing VLAN tags, but the MAC spoofing problem would still be an issue.
I want to know why WPA3 doesn't have a mode where a password is used for the initial connection , but then the client and AP generate a keypair and each store their half and use that for all future connections. For all future connections, the AP can validate every client, and the client can validate that it is connecting to the same AP. The AP could have an interface to 'revoke' access to any single client if necessa…
I believe this is due to the use of SHA-384, which is described as having 192 bits of "security strength"[0] against collision.
[0]: https://csrc.nist.rip/library/NIST%20SP%20800-107%20Recommen...