Alan Dekok wrote:
Arran wrote a nice pwn tool which acted as a RADIUS server for any SSID you set up. When a user (e.g. BJulin@clarku.edu) connects, the tool goes to the clarku.edu web site, and downloads any HTTPS certificate it finds. It then uses the fields from that certificate to create a new server certificate that it presents to the user. Users who aren't sufficiently wary can click through any warning prompts. Because the certificate has *all of the correct humanly-readable fields*. There are some caveats. In it's current state, it only works for users who don't have WiFi pre-configured. So only they get the message of "unknown CA, do you wish to continue?"
With the exception of Android, which may eventually get its act together, If you are going to go through the trouble of installing a local CA on all your clients, you can just as well set up the SSIDs to properly demand that a particular CA root is used, and the DN is checked. Once you've made the commitment to touch all clients in this manner it is a sunk cost.
2) if they use a public CA, pay the $3K or so to get a signing certificate issued by that CA 3) use that signing certificate to create your own server certificate... using the fields stolen from the real server certificate in step (1)
... I don't think commercial intermediate signing certificates that allow you to place arbitrary domains in them are quite that easy to obtain... that would pretty much break the web. Granted there are real trust issues with CAs, but a CA that made a practice of issuing any random unvetted stranger a signing certificate would find itself kicked out of the root stores pretty quick.
a) most people use self-signed CAs for RADIUS, which prevents the attack b) even for people using public CAs, getting a signing cert costs money.
c) all the Apple devices pin the cert after first use... which is great until it needs to be replaced.
Anyone who uses a public CA for "ease of use" or "it's a public CA", or "it's secure" is doing entirely the wrong thing. Stop it, now. And I mean *now*.
Agreed on the two latter, public CAs are certainly not *more* secure than local on any technical level at all. But on the former, I think this is too harsh. Security needs vary by institution and by user category, and in some places, convenience is the only way to get certain classes of users to do anything other than find a random rogue access point named something like "FreePublicWiFi" rather than your institutional SSID. Some institutions cannot practically police their RF environment *at all*, so merely using confusable characters in look-like SSIDs can bypass all your efforts and yield a password dialogue into which users will gladly type their creds, regardless of which kind of CA you run. For those users where credentials are high value, they are likely using managed machines, and managed machines can be easily configured by administrators. Also they are subject to being required to attend meetings telling them how not to set up their WiFi insecurely on their BYOs. Anyway, "convenience" is the whole reason SSO systems are implemented. Addressing that slide presentation about TLS: until it gets a *live* password mechanism in addition to the PKI, it doesn't serve some important security needs. Having either TLS evolve in that direction or PEAP supplicants evolve towards accommodating client certs is probably the point at which I can get management to buy into maintaining our own CA, and if I had to guess which would reach the built-in supplicant base first, it would not be an extended TLS. I think the constant badmouthing of password-based methods both in the EAP and SSH realms is holding back progress in this direction (i.e. how hard really would it be for SSH to use a challenge method for passwords inside the tunnel? Obvious precaution, neglected for decades by people too obsessed with telling people to use the public-key method and doing crazy crap with agents in order to create contagious credentials.) In addition, having institutions rush into using bug-ridden turnkey CA products with no regard for the institutional/procedural work needed to properly administer a CA is in nobody's best interest.