Yeah, 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).
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 ;)
right!? i was hoping this would be a guide with something like freeradius and letsencrypt/acme to handle certs instead of yet another rando “free until we go under/get bought” saas service
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.
The 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.
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.
FreeRadius can help:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...