mmalone

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.

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.

Correct.

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

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

I 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

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.

I 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.

I 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.

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.

If 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?

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.

It's a critique of OpenSSL, which also makes no attempt to think of user experience.

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.

I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.

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/

You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`.

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`.

Also, the Web PKI model has no real granular authorization when it comes to which CA can issue for which domain. A trusted CA can issue for any domain. So if you TOFU in my CA to connect to my website you’re also allowing me to issue for google.com.

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

Good question. I know you can add a root CA cert.

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.

That is correct.

Yea you’re correct. They were forcing people to add a CA. So this was not a great example.

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.

Neat. I had never heard of TLSA.

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.

Firefox is the only browser that ships with a built-in trust store. Other browsers use your operating system’s trust store and you can add & remove trusted CA certs from that trust store using OS-specific utilities.

The big three root store programs are run by Apple, Microsoft, and Mozilla/NSS. Most (all?) Linux distros are based on the Mozilla store. Until recently, Google also used Mozilla’s store for things like ChromeOS and Android. They just recently announced that they’re gonna start running their own program though.

FWIW the browsers seem to do a pretty good job of policing CAs. Probably better than most end-users would do.

Pretty sure CAA is supposed to be enforced by CAs, not by browsers. So, for instance, Let's Encrypt should refuse to issue a cert for your domain if you have CAA setup for digicert.

See my response to superkuh elsewhere in this thread. This would introduce new problems and, overall, would probably make Web PKI worse.

Counterpoint: this is also a big problem with SSH. When a host key changes with SSH you'll get a "Host Key Verification Failure" that basically says "yo, the key I expected for this host wasn't actually presented, you're probably being mitm'd". Then you have to go into your `~/.ssh/known_hosts` and delete a line. Then you get a new TOFU warning that you'll just type "yes" to and proceed.

So most SSH users (who, on average, are way more technically competent than browser users) will automatically 1) panic and think they're being hacked, or 2) blindly trust the new key when a key change occurs with SSH. Both of these responses are dangerous. The result is that, unless you have fancy stuff for managing known hosts for all of your users on all of your endpoints, you're probably just avoiding this scenario by not rotating host keys at all for SSH. Which is also problematic.

By using a CA you're delegating the key binding to a trusted piece of infrastructure that can be locked down and monitored by experts. You can't do that easily with key-bindings written to files on a bunch of different endpoints. With a CA, end users shouldn't need to care about key changes. The fact that the CA can issue a new certificate for some entity is a benefit: it makes credential rotation easier. If you do want to know when credentials rotate there are ways to monitor that yourself (and Web PKI has ways like key pinning and cert transparency).

I think TOFU would be really problematic for browsers & the Web PKI trust model. At this point Web PKI is dealing with attacks from nation-states and other advanced threats that end-users aren't really in a position to handle themselves.

Like, just last week the browsers had to remove a certificate authority from their root cert programs because Kazakhstan was issuing certificates to MiTM traffic. A TOFU model would make it a lot harder to detect and remediate this sort of attack and lots of other relevant attack vectors.

We'd also need to re-solve a bunch of adjacent problems like revocation, renewal/rotation, and transparency, which would probably mean re-introducing the sorts of centralized architectural components and processes that I'm assuming you're trying to eliminate with TOFU.

Sure the CA is a new attack vector. That doesn't make it inherently insecure or the same as cleartext transmission.

Is running an internal OAuth OIDC identity provider to issue signed identity tokens the same as using cleartext passwords?

Yea good question. You can email maxey at our domain, which is smallstep.com. He's running the contest. Blow up his inbox!

I work at smallstep and we're partnering with yubico to give away five build kits for this project. DM us at @smallsteplabs on twitter to enter.

See also: https://twitter.com/smallsteplabs/status/1341800787291168768

Counterpoint: if it hurts, do it more. That’s good operational hygiene. If you’re worried about certificate rotation failing, the surest way to make that process resilient is to do a lot of it. If you’re running the smallstep toolchain, you have an HA CA. That’s a sunk cost. That’s why it defaults to frequent rotation.

Furthermore, it’s not arbitrary. Credentials leak and services come and go. Having active keys around that aren’t in use is worse than not having them around. If someone accidentally commits a key to a GitHub repo or something, it’s nice to know that key will only be useful for a little while.

If you still want to rotate less frequently, change the default.

This really has very little to do with the topic at hand, so I’m not sure why we’re debating it. Do you want me to change the default certificate lifetime in step-ca? What do you think it should be?

There are many use cases for internal PKI. This is just one of of them. You’re nitpicking a default.

Credential rotation is good security hygiene. To suggest otherwise is malpractice. Our toolchain makes certificate rotation trivially easy. Why not rotate frequently?

Hopefully the threat model stuff made sense. It still feels like you actively want to disagree with me, and I’m still not sure why. But I agree that this is starting to feel unproductive.

I do appreciate the discussion. I understand your position on client certs better now. Your concerns are valid.

Maybe one day we can discuss over beers or something. It feels like that would be the right atmosphere.