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.

Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.

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 ;)

[1] https://en.wikipedia.org/wiki/Commercial_National_Security_A... [2] https://www.cnss.gov/CNSS/issuances/Policies.cfm

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

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.

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.

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.

We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).

[1] https://github.com/smallstep/certificates

[2] https://github.com/smallstep/cli

[3] https://smallstep.com/certificate-manager/

But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.

Obviously this is all addressable in theory, but now you’d need some kinda policy system baked in pretty much everywhere.

I’m on iOS and don’t have an Android or ChromeOS device handy. I don’t see a way to remove a cert from Apple’s iOS trust store (settings just tells me what store version I’m running). There may be a way to do it using mobile device management (MDM) tools.

I wouldn’t say the centralization of Web PKI is by design so much as it is (was?) by necessity. There’s a crypto conjecture called Zooko’s Triangle that says there are three desirable properties for a naming system: human-meaningful, secure, and decentralized. Zooko’s conjecture is that you can only have two. Web PKI picks secure & human-meaningful. Simple PKI (like TOFU) picks secure & decentralized (the names aren’t actually human-meaningful since you’re really trusting a public key which is a big random number, not a domain name). DNS picks human-meaningful and decentralized.

More recently, Aaron Schwartz realized you can “square the triangle” using blockchain. So it appears to be technically possible to have all three now, but there are other hurdles. In any case, simple public keys aren’t a silver bullet. Just a different set of compromises.

I’ll also add that certificate transparency (CT) is another mechanism designed to mitigate malicious cert issuance by a CA. A CT log is an public, append-only data structure. It doesn’t actively prevent anything, but it does ensure that a malicious issuance is easily detectable. In practice it seems to be a pretty effective deterrent against nation-state attacks: they won’t go undetected for long.