iOS mysterious issues on Freeradius 3.0.14

[Brian Julin]

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