14 ms·
WPA3 Enterprise 192-bit mode at home
- JohnFen 3y ago> However, if you want a home network that’s simple to configure, easy for your guests to borrow, hassle-free, and that all of your Smart Home gadgets can connect to, then you should close this tab now Or do what I do: run multiple APs. I have my primary one, which is very tightly secured and monitored, and only gives access to my local VPN. I have a guest one, which is only as secure as any average AP and gets you internet access, but no access to my LAN. If I used "smart" gadgets that I couldn't really control and trust, I'd set up a subnet just for them alone.
- tylerflick 3y agoThis is exactly what I do. IoT stuff sits on its own AP attached to a jailed LAN.
- scottyah 3y agoSo do you have to switch the wifi on your phone to access the IoT stuff?
- umeshunni 3y agoI'm guessing it's the same wifi network, just on a different vlan
- andrewaylett 3y agoNo -- not the GP, but I have a separate IoT SSID and VLAN with a distinct subnet. I run an mDNS repeater (or rather, my Unifi controller runs it for me) to allow discoverability across subnets. The benefit, such as it might be, is in the ability to use a stateful firewall between the subnets and that I can have a relatively secure PSK that I don't need to rotate when I rotate any of my other SSID PSKs. Relevant to the article, I also have a WPA-3 Enterprise SSID, a WPA-3 PSK SSID and a WPA-2/3 PSK guest/children's SSID. The different subnets have different sets of rules for what they may access and which DNS settings are applied by default.
- jmole 3y agoYou can run multiple SSIDs on the same AP and segment your networks with VLANs. No need to buy multiple APs unless you need the coverage.
- outworlder 3y agoAnd in this case the coverage would be even worse unless they duplicated all APs for both networks. It's probably much more cost effective to do what you suggest, and that's exactly what I do. Multiple SSIDs (one for the household, another for IOT stuff, another for work and another for guests) and control access via VLANs.
- lolinder 3y agoIs there a reason you split IoT stuff off of the guest network? On my network we just have a guest network which denies LAN access to anything connected to it, but I'm wondering if there's a good reason to split IoT off entirely.
- iforgotpassword 3y agoI guess it depends on what kind of friends you have, but assuming iot devices are insecure rubbish, I wouldn't want them on the same network as guests. But then again you might want to turn on client isolation for the guest network, so that wouldn't really be an issue.
- lolinder 3y agoYeah, I have guests all isolated from the LAN already.
- iforgotpassword 3y agoClient isolation means the clients on the network can't reach each other. This would prevent them from attacking each other or your insecure iot devices. Otherwise your friends will backdoor your security camera. ;-)
- sneak 3y agoAnyone can have access to my LAN. It’s not a security boundary, and pretending like it is means you can never safely connect to airport or hotel wifi.
- slicktux 3y agoYea I wish I could run my router with PMF enabled and WPA2…so many devices do BOT support such options…specially WPA3
- transpute 3y agoA 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 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 their guest isolation. As for Multi-PSK -- the use case is creating micro-segmentation in a network with zero-trust, where the identity on the network is rooted in that password. Without Multi-PSK, if it's not clear, every device that has the WiFi password can sniff encrypted traffic with WPA2, make a Rogue AP to attack WPA3 in case its in use, and can perform ARP spoofing on the network to interfere with other devices.
- zamadatix 3y agoI wish more consumer devices supported multiple PSKs on the same SSID. It's a handy feature much better for airtime than creating multiple separate SSIDs and much better for sanity than 802.1x user or cert auth.
- bscphil 3y ago> I wish more consumer devices supported multiple PSKs on the same SSID Could you name any enterprise APs that do this, short of running your own custom AP software? As far as I know (would love to be corrected on this), Unifi APs can't do this, and they're at the very least "prosumer".
- amluto 3y agoRuckus: https://docs.ruckuswireless.com/unleashed/200.3/c-ZeroITandDPSK.html https://docs.ruckuswireless.com/unleashed/200.3/c-ZeroITandD...
- soraminazuki 3y agoIt seems that feature has been added in a recent update. https://community.ui.com/releases/UniFi-Network-Application-7-5-187/408b64c5-a485-4a37-843c-31e87140be64 https://community.ui.com/releases/UniFi-Network-Application-...
- londons_explore 3y agoI 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 necessary, and single use passwords could be used too. That would give all the same benefits as WPA Enterprise (after the initial pairing), and all the ease of use of a preshared key.
- toast0 3y agoIt'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.
- nighthawk454 3y agoCouldn'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
- bongodongobob 3y agoI'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.
- klyrs 3y agoIs there any obstacle to having a centralized server these APs talk to, which manages authentication? I'm not seeing a hard obstacle, just another piece of network kit and it's cheaper to keep a clunky UX
- 3y ago
- sandworm101 3y agoTS 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.
- radicaldreamer 3y agoDoes the NSA use WiFi at all other than for clandestine collection systems in the field?
- Rebelgecko 3y agoYeah, they put out an article a few years ago talking about how a limited number of SCIFs have WiFi now
- sandworm101 3y agoDo they broadcast an SSID? They can't have "NotYourSCIF". That's my home network. Someone else is the building is using "FSB_BugsNet". Another local one i see is "CEyeA".
- sneak 3y agoSCIFs are already shielded for EM, so any Wi-Fi inside of them shouldn’t make it outside of them anyway.
- forward1 3y agoIt's not official until you change the MAC OID to 00:20:91 as well.
- Rebelgecko 3y agoTo be compliant with NSA TEMPEST regulations, the SSID has to be set to FBI_SURVEILLANCE_VAN_69
- 3y ago
- Animats 3y ago> 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?
- forward1 3y agoThe article borders on irresponsible by not explaining the full implications and risk of trusting a root CA, even if you're its sole private key custodian.
- mmalone 3y agoI work at Smallstep. In this case you're getting an industrial-grade CA with a properly managed private key, etc. Still, fair. We usually include warnings about this, but looks like we forgot this time. Curse of knowledge. I'll see about getting a warning on there asap.
- e12e 3y agoYeah, this isn't really "running at home" - which is a bit disappointing as smallstep does good work on the foss/self-host side of things (I guess this shows their seller side). FreeRadius can help: https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
- mmalone 3y agoI work at smallstep. Yes. This also works with FreeRadius! We decided to integrate RADIUS into our product since setting up FreeRadius is complicated and, if you're just doing EAP-TLS for Wifi, you don't need all of the features. You don't need to use our hosted RADIUS though.
- e12e 3y agoRight. I think it makes a lot of sense to integrate Radius in your product. But the only way giving full trust to a third party ca could be dubbed "NSA-grade" - would be that it puts you within the reach of the NSA by way of an NSL to that third party? (I'm not generally aiming to mitigate state level actors, but you put "NSA-grade" in the headline...).
- spr-alex 3y agoEAP-TLS is generally a great practice, as EAP-PEAP is vulnerable to MITM issues (fix proposed in https://www.ietf.org/archive/id/draft-josefsson-pppext-eap-tls-eap-10.txt https://www.ietf.org/archive/id/draft-josefsson-pppext-eap-t... but never adopted). For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it, it mainly only solves authentication. The outer layer is not wrapped with TLS and is instead based on an ephemeral session key. Additional work is needed to stop the spoofing. The RFC states explicitly that channel binding, which would help stop the MAC spoofing, is not implemented https://datatracker.ietf.org/doc/html/rfc5216 https://datatracker.ietf.org/doc/html/rfc5216. What it does prevent is a client from being man-in-the-middled. What's even wilder is that on some access points, when set to bridge mode, with an upstream Radius Authentication Server, as described, they may be vulnerable to ARP spoofing of the upstream radius server IP. This is something we've reported to vendors and were told "won't fix". Names include Netgear and TP-Link, though we don't suspect all routers from them are affected by this. We have not tested with the unifi access point referenced in the article. So to restate the attack, cause it's so ridiculous, you should know about it: an anonymous, unauthenticated wireless station associates without a password. Next it would begin the EAPOL negotiation but it instead then proceeds to perform ARP spoofing to claim the IP address of the upstream Radius that is supposed to only be routed over the uplink interfaces. Even without knowing the shared secret, it's possible for the client to pretend to be the radius server to the AP, and authenticate itself onto the network. One thing you want to be very sure of when setting up 802.1X Radius Auth, is that your access point is not going to be misconfigured to allow clients to do this.
- mmalone 3y agoIf you're doing EAP-TLS wouldn't the ARP attack you're describing fail at the client when it's unable to verify the RADIUS server's certificate?
- spr-alex 3y agoCorrect, a wifi station client would not be attacked this way. As for the radius client -- the answer is it depends. For many radius clients used by a common consumer AP, it's been possible for the spoofed radius to just say "okay, authenticated" to authorize itself -- and the shared secret is never used. It's worth noting that RADIUS may use MD5 with that shared secret, which is vulnerable to cracking attacks as well but I have not had to go down the rabbithole that far. It would be interesting to try this against the Unifi AP brand named in the article and see how it handles it. My understanding is they run a custom Openwrt image so maybe they provide source code.
- iforgotpassword 3y agoOn the topic of WPA3, I recently found that the old iPad 2 or 3 doesn't connect to wifi if it's set to WPA3+2, it only works in pure WPA2 mode. Tried on two different AP vendors, though I have no idea if they might use the same chip or driver or something. It's the only device that didn't work in this mode, everything else was fine, including some whacky iot devices like picture frames and an inverter.
- postpawl 3y agoYou’re sure it’s not actually the PMF setting causing that? More details here: https://www.reddit.com/r/Ubiquiti/comments/rq6jtr/psa_if_your_24ghzonly_devices_cant_connect_after/ https://www.reddit.com/r/Ubiquiti/comments/rq6jtr/psa_if_you...
- iforgotpassword 3y agoHm, in that post they say all of the 2.4ghz devices had the problem, while in my case it was just the iPad, and it was broken on both bands. But maybe it still was this (or a similar) issue. I only have access to one of the two APs right now, and there is pretty much nothing configurable regarding WiFi security apart from selecting from WPA1+2, WPA2 only, WPA2+3.
- BWStearns 3y agoI'm just amazed that there's SCIF approved wifi. I assumed I'd be dead of old age before that happened.
- CuriousCosmic 3y agoI'll believe it when I see it. They don't cite where it suggests in any capacity that Wi-Fi is ever acceptable for Secret or TS data transmission. If this was approved for anything it'd probably be CUI information at most (ignoring the many issues with their actual implementation).
- brendank310 3y agoAs someone noted above the Commercial Solutions for Classified program has been in existence for a long while (probably over a decade). This package is newer but not wildly newer. Installs of the various 'packages' do exist.
- CuriousCosmic 3y agoHuh interesting. I can't imagine where people would willingly use it.
- deleted 3y ago[deleted]
- BWStearns 3y agoThe white house scif is pretty laissez faire as far as SCIFs go and I imagine there's a whole pile of stuff from Maryland monitoring everything in another room nearby. I can see it being used for ipads for principals as it might be easier to police than stacks of paper.
- mysteria 3y agoIf you want do do this 100% locally it's pretty easy with Pfsense/Opnsense combined with the Freeradius plugin. You can create your CA, hook it up to Freeradius, and create accounts and certificates all from the GUI (if you know what you're doing). As a bonus you can use the same certs with say the built-in OpenVPN system, and revocation of certificates is handled seamlessly in the UI as well. Personally I found it much simpler than doing it by hand with OpenSSL commands, which I used in the past when I had a smaller deployment. The great thing with WPA Enterprise is that you can assign VLANs based on the client's login, just like a 802.1X switch. For instance my phone is sent to one VLAN, my company laptop to another, and my personal laptop to another. I can use a single SSID and get all the benefits of a multi-VLAN setup. For guests I provide a username and password for MSCHAPv2 authentication, while family devices are issued full certs. What about IOT devices? I generally only use commercial wired gear (IP phones, cams, etc.) anyways with no internet access, and I'm of the belief that if it doesn't support WPA-Enterprise it shouldn't be on the network in the first place :). So that rules out all those data-mining smart speakers and so forth.
- WatchDog 3y ago> In the “When using this certificate” dropdown, select “Always Trust.” 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)?
- mmalone 3y agoI work at smallstep. Not sure about the RADIUS server, but connections to the CA use TLS for SCEP and/or ACME DA so the CA root cert needs to be trusted for TLS. There may be some way to configure more narrow trust for just this one interaction, but I'm not aware of any such mechanism in the current releases of macOS/iOS/iPadOS/tvOS.
- pcthrowaway 3y agoOn Mac (which the author appears to be talking about), I believe agreeing to Always Trust when connecting to a WPA3 network only enables it for the "X.509 Basic Policy" setting. I don't know much about how the different trust policies on OSX work though, and it makes me very uncomfortable that trusting self-signed root certificates may become more common for connecting to wifi networks. If you do trust the root cert for everything, couldn't the access point MITM all your traffic?
- forward1 3y agoNot only MITM traffic, but also run arbitrary software since it could also govern code signing.
- cynix 3y agoUnfortunately the article doesn't explain how to setup a RADIUS server for EAP-TLS.
- e12e 3y agoBut there's a link so you can lease one in the cloud... If you want to self-host, see eg: https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configuration https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
- WatchDog 3y ago> Why is NSA-grade Wi-Fi called "192-bit mode"? 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%20Recommendation%20for%20Applications%20Using%20Approved%20Hash%20Algorithms,%202009-02%20(2).pdf https://csrc.nist.rip/library/NIST%20SP%20800-107%20Recommen...
- pieresqi 3y ago[dead]
- devin 3y agoI know the article is just "here's how", but I don't trust my wifi because of the hardware and software on it, so for me the protocol is irrelevant.
- mmalone 3y agoI work at smallstep. For home wifi this is totally overkill. Better security is always nice but, in this case, there's a significant usability & interop tradeoff for home use (though that may change over time... we'll see). For business / enterprise settings, this has real value. Distributing a password to everyone doesn't scale and alternative EAP methods have huge security problems. For managed devices, certs can be pushed and EAP-TLS can be configured easily. And it's all seamless for end users[1]. For example, EAP-TLS mitigates "evil twin" attacks, where a rogue access point broadcasts your SSID. If you're using something like EAP-PEAP, which is password based, the user is sending a password to the RADIUS server. If they connect to a rogue AP, they just sent their password to the bad guy. If the password is their LDAP/AD/Okta password, that could be very bad. There are a variety of mitigations for this sort of attack but, without getting into details, EAP-TLS is widely considered the most secure option. So, yea, if you're relying exclusively on wifi for security you're doing it wrong. But that doesn't mean you don't need to secure your wifi. [1] https://www.youtube.com/watch?v=KSL_Ke7HcpU https://www.youtube.com/watch?v=KSL_Ke7HcpU
- andrewaylett 3y agoPEAP can still require a trusted server certificate -- getting set up with MDM is a pain, and scaling by hand is also a pain, but you can (and I do) set up my devices to require a specific valid SAN on the RADIUS connection. No extra certificate trust required, if the RADIUS server has a certificate that chains up to the default trust store. I remain disappointed that there's no standard mechanism for mapping between an SSID and a domain name to know which SAN to trust.
- mmalone 3y agoJust to clarify, are you describing EAP-PEAP or EAP-TTLS wrapping PEAP? I'm still learning a lot of this stuff... but, my understanding is that PEAP doesn't do TLS but TTLS + PEAP does. Right? Fact remains, though, that users will probably bypass any certificate warnings (if allowed) and send their passwords to rogue APs. EAP-TLS mitigates this. Definitely pros & cons, but that's a clear win for EAP-TLS. There are a lot of things that'd be nice to see in Wifi. Binding the SSID is an interesting one, though I suspect the folks working on this stuff were reluctant to rely on (and trust) the Web PKI CAs. If you're gonna push your own root cert, you might as well push a RADIUS SAN along with it, I guess.
- demondemidi 3y agoThis is how DefCon provides WiFi.
- xoa 3y agoPersonally I've essentially given up on depending on WiFi auth for anything important. For general access, segmenting various users, IOT etc for performance, monitoring and light privacy WPA-EAP and PPSKs with VLANs does some work as an initial first layer fine and in a simple reliable way that works with everything. It's a low pass filter. But for all sensitive access I use internal Wireguard now. WiFi auth gets a client onto a restricted VLAN in the first place, but from there only a VPN will get to management webguis, sensitive services, or unrestricted internet access. Regrettably the design process for WPA3 was the same old mediocre industry affair. It's not worth trying to put many bandaids on vs just moving things to a higher level. As a practical matter WiFi also just isn't that fast vs high performance clients, it's not like WG has to handle tens of gigabits, so there isn't even any downside in performance. WiFi auth at this point kinda feels like a polite lock on the screen door. Not useless at all, but anything really important should have other layers in front that are more secure by design from the ground up.
- ghostpepper 3y agoWould love to hear more about how you provision wireguard. I have a simple VLAN setup where I can open a tunnel from my "guest/home" network to my "lab" network (ie. docker hosts, desktop PCs that I use for development, etc) and a second tunnel from the lab network to the network that can access mgmt interfaces, however it's all mostly manual (ie. sudo wg-quick up in a terminal)
- spr-alex 3y agoSomewhat related -- with the project I work on, https://github.com/spr-networks/super https://github.com/spr-networks/super, we do support wireguard peers (and also support combining that wireguard identity with a wifi peer identity as well). Devices are provisioned by assigning or generating a wireguard keypair in the API. Next the peers are routed together by policy and by default can't access one another. There's support for bidirectional network groups or one-way firewall rules with NAT. One area of improvement is multicast support with wireguard, it's doable, just not ready yet.
- xoa 3y ago
- slowhadoken 3y agoA do it yourself guide to stuff you shouldn’t do.
- wkat4242 3y ago> Because you need certificates, your Smart Home devices won’t support WPA3 Enterprise. Home printers won’t support it. A lot of things won't support it. In fact, it’s a miracle that some consumer-grade routers and access points support it at all. It's not really a miracle. It's just much easier to do from the access point side because the whole authentication process is basically offloaded to the radius server. It doesn't add a lot of complexity to the actual access point or router. The radius server itself is usually not included with these solutions, they're just capable of talking to one. It's just an easy to achieve bullet point for a feature list. On client devices however it's a huge pita building a mechanism to manage client certificates, the verification chain and related requirements. It also has to be able to verify the radius server's identity so it needs a full list of fully up to date root CAs (including private PKIs and a way to add them too) and be able to check their revocation. And you need accurate time while not actually having internet access yet. And then there's automatic issuing. Most businesses don't just hand you a certificate, it's issued on the fly by a company HSM after the client device first generates its private key and then installed automatically by MDM after it determines your device is trusted enough. Like obeying security settings like encryption, having the required Antimalware installed and updated etc. It's also automatically revoked if that is no longer the case. If you just hand it to a user and let them use it wherever they want it's not a lot better than a password really. So nobody actually does this in the real world. So the endpoint needs to be able to talk to various MDMs which is certainly feasible on a phone or computer but not on a simple printer, IP cam or smart device.
- simoncion 3y ago> On client devices however it's a huge pita building a mechanism to manage client certificates... Yep. This is why "replacing" PSK-protected WiFi with EAP-PEAP, and open WiFi with EAP-TLS was absolutely THE way for the WiFi people to go. (With EAP-PEAP you have the option of setting (and revoking) per-device credentials. With EAP-TLS, you get an open-to-anyone network with data encrypted over the air.) Despite what the nerds at Google would have you believe, using either EAP mechanism without verifying the cert of the RADIUS server is totally, completely supported by the spec. It's nuts that Google didn't (and maybe still doesn't?) let you operate in the "don't bother verifying the RADIUS server cert" mode, because in the EAP-PEAP mode it's no worse than standard PSK, and in the EAP-TLS mode it's strictly better than Open WiFi.
- amluto 3y agoIt makes me sad that even WPA3 doesn’t have a native provisioning mechanism. In a better world, a device would present its MAC address, some description of itself, a public key, and optional extra data (e.g. an attestation of the hardware security backing its keypair, and the network operator could, at its leisure, accept this device. Then printers, smart devices, etc could join without needing to each support an MDM or other proprietary provisioning system. Also, if you care about availability, don’t use a cloud RADIUS server — if the server or your ISP or your route or the relevant part of your network goes down, there goes your WiFi. If you’re using 802.1x, your wired network is toast, too.
- pierat 3y ago> It makes me sad that even WPA3 doesn’t have a native provisioning mechanism. And that's how you get spoofing management frames, deauthing, and all sorts of fun attacks. Cause the moment you talk to unauthenticated and unencrypted machines, well, yeah. Payday. So you cant do that, even if you really want to.
- amluto 3y agoHuh? Almost every cryptographic session protocol starts out with the parties sending unauthenticated data of some sort to each other. Having a way for a party to send a blob as part of its request to be let in is straightforward. Plus we’re taking about WPA, which, AFAIK, still uses a horrible hack for EAP even in WPA3, and as you can see mentioned elsewhere in the comments, EAP makes a pretty strong showing in its quest to be the worst widely-used example of giving an unauthenticated party actual access to the network as part of the authentication flow. Doing this right is not that complicated.
- tonetegeatinst 3y agoTheir was a defcon or a blackhat talk on this issue. Even though the data might be encrypted....developers can leak so much metadata via the handshake that you can build profiles and track devices
- cvalka 3y agoUse EAP-TTLS
- fiddlerwoaroof 3y agoDo these enterprise modes have any advantages when it comes to connection reliability?
- parl_match 3y agoYou're not going to increase connection reliability/extend your wifi range by enabling radius. If you have any understanding of what's happening here, you wouldn't even ask this question.
- fiddlerwoaroof 3y agoWhat I’m wondering has nothing to do with signal strength. I’m wondering if the protocol differences have any effect on reliability in situations where the wireless connection is less reliable. Because, for example, there’s less negotiation on reconnecting to the network or something. After all, reliability is a cross-cutting concern :)
- zamadatix 3y agoUnfortunately it's hard to beat a PSK based exchange in terms of quick connection, particularly with something like this where the authentication server is moved external. The difference in reconnection time is, in general, extremely marginal though. If the Wi-Fi is bad enough your client thinks it actually needs to reconnect instead of retransmit the only meaningful respite is to solve that problem directly.
- andrewaylett 3y agoAbsent 802.11r, they might improve hand-off between APs. The disadvantage of WPA Enterprise though, especially with a hosted RADIUS server, is that it's somewhat more difficult to gain access to the network to fix things if they're broken -- if your internet connection is down then you can't authenticate, and if you can't authenticate then you can't fix whatever broke to bring the connection back up. I suspect you can guess how I discovered that problem :). So overall: no. There might be a small increase in reliability in regular use (although I've not been able to tell the difference), but the reliance on an extra service makes for less reliable connections overall.
- wwarner 3y agothis guy is a good writer
- xyst 3y agoI would like to see something like this for “home” setups but it would have a much better user experience: 1) user attempts to connect to “home-wifi” 2) owner of “home-wifi” gets notification to confirm or deny access request 3) owner can optionally verify further 4) if approved, then between AP and client device it will create the client certificates with short expiration dates 5) if denied, then no access granted. 6) if user tries to connect multiple times and gets denied for all of them, then their device is blacklisted. No notification. No more passwords. Minimal friction to adoption.
- hunter2_ 3y agoWardrivers with sufficient randomization to avoid any denylist you implement will get very annoying if you let those notifications interrupt you. Maybe only receive such requests while you expect guests.
- Klathmon 3y agoYou could just not have notifications. I'd be fine with a system where when someone tries to connect to my network, I need to open an app or go to a web page and pick from the list of attempts to allow. It's not perfect, and it still leaves open a DoS by filling the DB with spam, but at that point you know something is wrong.
- wishfish 3y agoThat would be the best way. Turn on notifications when you're expecting a new device. Turn off notifications and auto-deny the rest of the time.
- wahnfrieden 3y agoHi- Did you release your edtech iOS app (the SwiftUI one you posted about)?
- wishfish 3y agoJust saw your reply today. That's an excellent memory you have. Surprised anyone remembers me talking about it. I am still working on it. Just in my spare time. Maybe a release later this year if everything else works out and I can keep focus. Keeping focus is the difficult part, of course.
- dontupvoteme 3y ago>NSA >Wi-Fi No.
- boringuser2 3y agoI think this is generally barking up the wrong tree and addressing the wrong attack vectors for home wifi. An actual over-engineered home wifi looks like this: 1. Use, at the very least, prosumer grade router access points. I use *sense and Aruba access points, but you don't need to get this serious. 2. Use heavy DNS filters. This will block a lot of malware by itself. Quad9 DNS is a good starting point. 3. Use a secure wifi password. 4. Don't enable upnp, etc. 5. Don't enable ssh or any kind of remote access. 6. Don't open any ports to the outside. This is the default ruleset for pretty much any firewall. 7. If you ever have guests who require wifi, segment these users on a guest wifi or vlan. 8. Reduce your reliance on wifi-powered devices. Favor zigbee smart home devices over wifi devices. 9. (Optional) segment your IoT devices on a vlan. 10. (Optional) use some kind of security package that includes layer 7 monitoring on your LAN. 11. (Optional) use some kind of security package that includes IPS/IDS.
- sneak 3y agoItems 4-9 accomplish nothing. Your LAN is not a security perimeter. This ain’t token ring.
- boringuser2 3y agoYou work with reality as it is, not as you'd prefer it to be. A home router is generally protected on the WAN side. Your threat model is to secure connections originating from the LAN side, which is the only way a threat actor can establish a connection into a default deny network.
- sneak 3y agoConnections into hosts on your LAN doesn’t gain an attacker anything, otherwise it would be unsafe to connect your laptop or phone to hotel, coffee shop, or airport wifi, and it’s not.
- boringuser1 3y ago[dead]
- stephen_g 3y agoI haven't gone quite this crazy, but I do have three SSIDs broadcast from my UniFi APs - my main network (WPA3 PSK), a guest one, and a devices network for IoT devices. All these are on different subnets/VLANs and firewalled off from each other. A lot of the IoT stuff doesn't work with WPA3 or 5GHz, so it's useful even for that reason, but the main thing is screening them off from everything else. I am setting up a NUC as a little home Proxmox server (for some other stuff mainly) but for "fun" I can actually see myself setting up a Samba 4 Active Directory domain controller and hooking FreeRADIUS up to that to do Enterprise for my main SSID, but we'll see!
- sneak 3y ago> Once you’ve installed the profile, we once again need to manually tweak trust settings. This time to explicitly enable Full Trust for the Smallstep RADIUS server’s root CA. Again, this is not true for a full MDM enrollment. Do not download and install and fully trust root CAs from anyone on your iPhone.
- tonetegeatinst 3y agoTLS 1.2 and not 1.3? Could a swore we moved to 1.3 a while ago Also many I'm just not familiar enough with cryptography but that key size seems kinda small.....am I wrong? Ik RSA uses a different algorithm but RSA it isn't uncommon to see keys 1024 or larger in size. I generated a key of 65,536 and 131,072 bits a few times to see if it would work or break any applications I was using. Also just to I can say "yeah back in my day we generated keys way bigger" cuz I know at least 1 other person in the world did it. Is their any standard for securing a network both wired and WiFi using a post quantum algorithm? Also where can I easily find switches that support these standards? AFAIK wpa3 enterprise dosnt always mean this standard is supported....or that some other standard is supported. Is their some database that lists every router/AP and the supported features?
- serendipitous 3y agoTo get 192-bit security with RSA you'd need 7680-bit RSA key and with ECC you need 384-bit key as mentioned in the article. That assumes classical attacks only. For quantum attacks, the smaller key sizes used with ECC do make it weaker.
- tamimio 3y agoI try not to use wifi as much as possible, but when I do, I connect through it to my home VPN or similar and take it from there, so even if the wifi is compromised, there’s an extra layer of protection there.
- WirelessGigabit 3y agoWell, that means I couldn't use my iPhone from work at home as it blocks installing certificates. But, while not NSA approved, WPA3 itself has support for per-device passwords with WPA-SAE [0] (which isn't called WPA-METRIC outside of the USA...). [0] https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals#WPA3 https://en.wikipedia.org/wiki/Simultaneous_Authentication_of...
- deleted 3y ago[deleted]
- teunispeters 3y agoInstructions ... yeah, not bad. It's essentially WPA3-Enterprise with possibly 192 bit set up. I like WPA3-Enterprise, it's really sufficient for most people when one moves to discontinuous permissions on a network. That said, after developing WPA3/Enterprise/192 for a platform out there, it's really very very restricted - and there were very few clients at the time that supported the combinations of security authentications required. Oh, also roaming clients is somewhat restricted (by no fast roaming protocols, at least as of the last time I went through the specs). Here's specifics, using hostap/wpa_supplicant style configuration: key management WPA-EAP-SUITE-B-192. (but then they talk about that); pairwise=GCMP-256, group_mgmt=BIP-GMAC-256; EAP=TTLS; I mean RADIUS support isn't that hard - freeradius will do. TLS - well, need valid certs that work for EAP. (it's not as specialized as Passpoint/Hotspot-2, which requires custom certs that must be validated by a specific CA, but it still takes some steps). My own experiments across a number of clients showed that GCMP-256 support for pairwise and group management weren't that common before Wifi-6 took off. Suite-B 192 though isn't so hard to reach. Hostly, I prefer WPA3-Enterprise with Fast Roaming. Sadly, typical household devices didn't work well with it (mixed with android devices, generally no for printers and other IOT), so I went back to two networks - WPA2/Personal with PMF=optional for those annoying devices that don't have working PMF, and WPA3/Personal for most devices - at least for household operations.
- tialaramex 3y agoBecause the requirements of "192-bit mode" for WPA3 Enterprise fall on not only the actual WiFI but also the backend identity providers, you are explicitly not allowed to do this for Eduroam unless you also provide a parallel WPA2-style (thus WPA3 compliant but not "192 bit mode") WiFi for everybody whose home institution isn't the US government. Lots of institutions have Eduroam set so that students (and academics, and everybody else like me) are just authenticating against their Windows domain controllers, so going to "192-bit mode" would mean ripping out a bunch of stuff, replacing it, writing fresh documentation, testing thoroughly and then authorising, but since we're talking about the backend every educational establishment in the world would need to do this before you can ship WPA3 192-bit mode. So, that's not going to happen.
- 4ad 3y ago??? This is a dude playing with his home wifi. 192-bit WPA3 Enterprise is not for every use case, nor does the author or anyone else make this claim. Your comment seems misplaced.
- tialaramex 3y agoSure, it's just interesting because this seems like just a straight up good idea for authenticated WiFi, but because of the need to significantly change the identity backends it's actually not practical for large federated systems like Eduroam.
- bArray 3y ago"NSA grade" irks me - to think these guys have your best interest at heart. In the 1970's they weakened DES [1]. In 2015 the NSA created a backdoor and pressured companies into installing it [2]. In 2016 you had the leaked tools stolen and used by the Shadow Brokers / Equation Group [3]. More recently the NSA made arguments against double encryption to combat weaknesses in potential quantum-safe encryption algorithms [4]. The point is that "NSA grade" likely means "NSA accessible". The major difference between WPA2 and WPA3 is the individual encryption. My guess would be that there is some backdoor during SAE and they could force a complete reconnect by temporarily jamming/disrupting all users on a network. [1] https://arstechnica.com/information-technology/2013/09/the-nsas-work-to-make-crypto-worse-and-better/ https://arstechnica.com/information-technology/2013/09/the-n... [2] https://twitter.com/matthew_d_green/status/1433470109742518273 https://twitter.com/matthew_d_green/status/14334701097425182... [3] https://en.wikipedia.org/wiki/The_Shadow_Brokers https://en.wikipedia.org/wiki/The_Shadow_Brokers [4] https://blog.cr.yp.to/20240102-hybrid.html https://blog.cr.yp.to/20240102-hybrid.html
- ransom1538 3y agoNSA. Is that the organization of unemployed mathematicians that thinks it is 1989? The group that can't crack the super secret algorithm of "https". Yeah, that is the one, the group that is puzzled by large prime numbers.
- batch12 3y agoI know I shouldn't, but... https isn't an algorithm.
- ransom1538 3y agolol. I know. I should have used "for"
- DateThing 3y agoOn your first point, I’m not aware of NSA weakening of DES. Only in-fact strengthening it against differential crypto analysis. Your link seems to echo that. Were you thinking of something else? Of course, the fact the NSA was aware of differential crypto analysis some years before the rest of us is another thing…
- 1letterunixname 3y agoJust run FreeRADIUS yourself. If you need your own PKI to generate certs in a manageable way, there is OPNsense [0] or smallstep's FOSS step-ca [1]. Friends don't let friends delegate AAA to an external provider like Smallstep or SSO to Okta. While outsourcing to a third party is fine for a limited test, it's not fine for anything enduring. Once upon a time, when open, spoofable WiFi was the norm, there was a collective WiFi sharing app that took control of retail WiFi routers with WPA1 enterprise RADIUS support called Radiuz. [2] 0. https://opnsense.org https://opnsense.org 1. https://github.com/smallstep/certificates https://github.com/smallstep/certificates 2. https://web.archive.org/web/20040617153148/http://radiuz.net/logon.jsp https://web.archive.org/web/20040617153148/http://radiuz.net...