iOS mysterious issues on Freeradius 3.0.14

[Brian Julin]

Alan DeKok wrote:
>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.

You get to choose your CA.  Don't choose them.

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

It's a matter of trust.  In one case, you choose to trust a CA you think will
do proper vetting... or who never issues such certs.

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

My little corner is obviously not the same as yours.  If client installers
had been the only option for WPA2-enterprise, there's a good chance
we'd just about now be finally getting off WPA2-personal rather than
nine years ago, and the project would have gone through 3 failed
attempts involving many pitchforks.

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

So are user-agnostic public keys.

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

Technical creation of a CA server is trivial.  CAs are more than a server. Proper procedures to
ensure the CA is used in a way that does not subject it to compromise is... "a bit more difficult". 
So are disaster recovery precautions (e.g. what group of people are allowed to take airplanes together?)
There are whole books about it.

e.g. much as I like Aruba's gear, I'm no fan of CPPM, and it has had its fair share of
security issues because it is too much bloat crammed on one box.  How many guest
web portal dialogue boxes vulnerable to apache struts bugs does it take to have your
RADIUS private key leaked....

Everyone rushing to build an insecure CA infrastructure could be a pretty dangerous trend.