You can roll your own with https://github.com/smallstep/certificates. We maintain major open source projects and contribute a lot to other projects. I don’t think that means everything we do has to be open source. Sorry this one wasn’t. Doing this in pure open source would be a book, not a blog post.
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.
> You need internal PKI for WiFi. [Let's Encrypt-issued certs are a terrible idea.]
If you're talking about Centrally-Managed Enterprise WiFi, sure, agreed. Feel free to stop reading this comment, as my objections are only relevant to the home WiFi scenario.
If you're talking about home WiFi, then no, absolutely not. With the state of the world as it is (particularly with the various inbuilt CA distribution mechanisms being in the state they're in) I could not disagree more.
Remember that in the home WiFi case, you're replacing a system that does absolutely no verification of the AP that the supplicant is connecting to. So, in the case of EAP-PEAP replacing non-RADIUS PSKs, you're no worse off, and the case of EAP-TLS replacing Open WiFi, you're strictly better off... even when the supplicant does not verify the identity of the RADIUS server it's speaking to.
If I could have my guest scan a QR code (or have me read a number to them for them to enter) to get my CA into their "only trusted for the SSIDs I assign it to and only those SSIDs" cert store, then, sure, passing along this overly-large PSK would be an acceptable burden. But as it stands now, if I don't choose to use a TLS cert issued by an already-trusted CA I have to do one of the following:
* Do some sort of corporate provisioning thing that requires a lot of configuration of the client device. ("Why is this so complicated? You know what? Forget it, I'll just use my cellular connection. What the fuck is wrong with you that you make this so complicated?")
* Have them use some alternate network connection to download my CA cert, then go through the multi-step process to load it into their trust store and blah blah blah. (See the previous bullet point for the guest reaction to this process.)
* Put the CA on removable storage, hope that their phone can USE that storage, and walk them through putting the CA where it belongs. (Again, the guest is simply not going to do this and think I'm an idiot for making it needlessly complicated.)
* (I'm not sure this one is even possible, but I mention it for completeness' sake) Use some Phone App that can pull down a CA from the servers of some VC-funded startup and load that into the phone's CA trust store.
While my guests might actually do thing #4, thing #4 is for me a non-starter. I live in a large city, have lived in small cities, and have also lived in The Country. The number of times I've had someone successfully attempt to impersonate my wireless network infrastructure is zero. The number of times I've had services provided by some company (whether a startup or a BigCo) be discontinued or otherwise changed to become entirely unsuitable for purpose is far, far larger than zero.
If we had a widely-deployed, reliable, inbuilt CA insertion mechanism that normies could (and would) use, then sure, these privately-generated PSKs would be not crazy to use in home networks that you expect normie houseguests to connect to. But with the sorry state of the inbuilt "Add a new CA cert" tools, the habit of companies that produce useful consumer-focused tools to either bait-and-switch, or just evaporate after a few years, and the real-world infrequency of folks doing attacks on home WiFi networks, using a cert signed by an already-trusted CA like Let's Encrypt is the best option... if your supplicants DEMAND that cert checking be enabled.
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.
PEAP 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.
Just 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.
I have EAP-PEAP wrapping MSCHAPv2[1]. You might still be learning, but I suspect you already know more than I do about this stuff because I pretty much just stuck the right settings into the Unifi controller and poked at it until it started working :).
On Android, I set "use system certificates" and "Domain: radius.jumpcloud.com"[0]. On Mac, I'm given the option to verify the certificate and I can see that it chains up to their publicly-trusted CA. The vendor seems to assume that I'll be hard-coding their certificate in my MDM, but I've not needed to. The Mac wasn't happy when the certificate was rotated, but the Android and Linux devices I have were perfectly content.
My AP controller also has a valid certificate, but it's not in play. As a user, I need a username and password for MSCHAPv2, and to convince the client that the certificate is OK -- which is easy, when the client is willing to use the system trust store :). I'm not provisioning client certificates, so I don't need to generate a root for that purpose. And it's for home, so I only need to worry about provisioning for two people.
I really don't like setting trust bits on root certificates, even ones that I generated myself. Been there, would prefer a bit more certainty that I'm not being spoofed by my own leaked root certificate. I'm much happier trusting Web PKI than I am trusting anything of my own that's sufficiently accessible as to be usable for this kind of thing.
[0]: Yep, I'm using a hosted provider that's not your employer, sorry :P.
[1]: WPA-3 SAE is nice, and it would be really nice if we could use something including that for the EAP. SAE solves the spoofing issue for non-Enterprise use-cases, unless someone trusted with the key goes rogue. Per-user SAE could mean that the rogue user can only spoof themselves, I think?
I 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.
Right. 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...).
Well... the title is hyperbolic (as titles are wont to be), but the goal was to configure Wifi that aligns with the CNSA Suite[1] / CNSSP 15[2], which I think is fair to call "NSA-grade" since they wrote the standard.
If the NSA wants to get a certificate that your system trusts there are already dozens of organizations with root certs in your system trust store that they can strongarm. Most organizations can't afford to have the NSA in their threat model. You better not be using public clouds, GSuite, Okta, Azure AD/Entra, etc. This is a difficult security posture to maintain, especially at scale.
For most organizations, delegating the operation of sensitive security infrastructure to a third party results in better security, not worse. Yes, you're trusting a third party. But you're also outsourcing sensitive security operations to experts.
And, we also have on-prem and open source if you really need something air-gapped ;)
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.
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.
> For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it
The idea would be to rely on the client certificate authentication and not use MAC filtering at all. For example, you could have an EAP-TLS network that's unrestricted and not let Mallory on it. Or you could use RADIUS reply attributes to put Mallory on a restricted vlan.
Why not just set up multiple SSIDs then? The devices connected to different SSIDs belong to different VLANs. Then you don't have to consider MAC spoofing or even deploy EAP-TLS: just give different devices a different password.
I'm sure there are simpler ways to deal with the use case in mind, but I think this article just wants to have fun with NSA-grade WiFi.
Right, although the article did not mention how to stop the spoofing. I started this thread to raise awareness and point out that the details around RADIUS can really matter here when not using a secure AP because some of the security assumptions about radius clients do lead to hilarious security failure
Correct, 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.
What would happen if you tried to reconnect to the network and the AP didn't have the pre-shared key? Presumably, you'd prompt the user and ask them if they want to connect. This is the same pattern as trust-on-first-use (TOFU) for SSH, except for non-expert users. It's a good thought but I think it'd fall apart in practice. You'd still be vulnerable to phishing / evil twin APs.
This is not a technical limitation though. It's a policy limitation.
In theory, a name-constrained intermediate for `.example.com` has no more authority and poses no greater risk than a wildcard leaf certificate for `.example.com`. In both cases the private key can be used to authenticate as any subdomain of `example.com`.
But, name constraints are verified by relying parties (the clients and servers that are actually authenticating remote peers using certificates). It's hard to be certain that everything has implemented name constraints properly. This is, ostensibly and as far as I know, the reason CA/Browser forum hasn't allowed name constrained intermediates.
At some point it probably makes sense to just pull the bandaid off.
CABF and root programs allow NC'd CAs - they're just a pain to operate.
The infra itself, keeping up with compliance and root program changes (which happen with more frequency now!), CT logging, running revocation services (not easy at scale).
Plus then things to consider like rotation of the NC'd CA. You'd have to rotate at least once a year, perhaps less given domain validation validity periods. You'd also likely need to have the chain ('chain' used loosely, we know it's not really a linear chain) be four deep like: root->CA->your NC'd CA->leaf, 'cos the root should be offline and unless you're not doing these in much volume I assume you'd want to automate issuance and not gather your quorum of folk to sign from the offline roots. That might not be an issue for many, but it certainly is for some.
(Full disclosure, I work for a CA for almost 2 decades and have pretty intimate knowledge in this area, sadly).
It's interesting to hear that there's already a NC protocol today, but most in this thread are aiming at "should" not "can". The point is that a 90-day, name-constrained CA has no more authority than 90-day wildcard cert if both are issued via DNS-01 validation (modulo nested subdomains), so it shouldn't be subject to the same regulations as a public CA with no restrictions (which require CT logging, audits, revocation services, security requirements, etc as you enumerated), or really any more restrictions than those necessary to be issued a wildcard cert. This would be very beneficial for private networks and would have even better security properties than wildcards. Is there any reason why this shouldn't be possible?
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.