iOS mysterious issues on Freeradius 3.0.14

[Alan DeKok]

On Mar 23, 2017, at 11:14 AM, Brian Julin <BJulin at clarku.edu> wrote:
> 
> ... 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.

https://news.ycombinator.com/item?id=11781915

  Symantec has been known to do it.

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

  The point is that the intermediate CA would be vetted.  But... that intermediate CA could be malicious, and *no one would know*.

  How many end users will look at the certificate chain when authentication fails?

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

  Or when you have multiple RADIUS servers, each with their own certificate.

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

  The point isn't to solve *all* of the security issues of the world.  The point is to explain how to solve security issues in our little corner, and what attacks are possible.

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

  Like CEOs who are well known for downloading viruses from certain (ahem) non-youtube video sites.

> I think the constant badmouthing of password-based methods both in the EAP and SSH realms
> is holding back progress in this direction

  It's bad-mouthed in EAP because it's a bad idea.  Until a better method is deployed, it's still a bad idea.

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

  It's pretty much trivial to create your own CA.  Putting it on 10K end user machines is a bit more difficult.

  Alan DeKok.