On 07/03/2011 21:42, John Dennis wrote:
I changed "default_eap_type=md5" to "default_eap_type=ttls" and now the
Macs are able to authenticate without Certs or any configuration on their
side!!
...remember though that working != secure [necessarily]. Clients defaulting
to accept any radius server cert, or those that default to prompt the user,
are vulnerable to rogue AP/credential stealing attacks etc. This may be
acceptable in your environment, but if not, you'll still need to actively
configure the client.
I've seen statements on this list in the past asserting that if you have a
server cert signed by a public CA (e.g. a CA the client is preconfigured
to trust) it is a security vulnerability because clients will blindly
trust they are connecting to server they expect when in fact it could be a
rouge server impersonating the server. The above comment seems to fall
into the same category.
I have never understood this advice or it's rationale. I was hoping
someone could explain it because it does not match my understanding of
PKI, here's why:
When a client negotiates a SSL/TLS session it's supposed to validate the
server cert. In simplicity this is a 2 step process.
1) It validates the server cert to assure it's signed by a CA it trusts
(possibly via a cert chain).
2) It then validates the certificate subject to make sure the server it
thought it was connecting to appears in the certificate (either as the
certificate subject or one of the certificate subject alternate names).
If either 1 or 2 fails it should abort the connection.
If it were possible on an SSL/TLS connection to impersonate another server
then most of PKI would be a complete failure.
So why does this group think PKI doesn't work?
Hi John,
Ok, first your (1) - matching a presented server cert to a pre-trusted CA
cert on the client. This "works" and does exactly that. Consider this:
* The client will validate my cert against the CA I signed it with.
* The client will also validate a cert that "badPerson" has purchased from
e.g. verisign
Why - because an unconfigured EAP client will likely trust *all* root CAs
(~like your web browser does by default).
So, to mitigate this I can set my EAP client to only trust my CA e.g.
verisign.
... but "badPerson" bought their cert from verisign too! ... so we have to
move to the next level - your step (2), the CN.
So how do we configure the client to trust the appropriate CN.... just
that *configure it* ...an unconfigured/default config client will likely
trust any CN.
It is this step that is very different from the web. In the web world, the
client can check the cert CN matches the DNS name that the user typed, and
that this matches the reverse DNS of the IP that the cert came from.
In the EAP world, there is no DNS, no IP, no way to determine the source
of the cert at all.
...which is why there is nothing wrong with the mechanism, as long as you
configure it properly.
Some EAP clients do not let you specify a CN to match, so using a
self-signed cert, and setting the client just to trust that CA mitigates
the public CA vector.
-James
--
James J J Hooper
Network Specialist, University of Bristol
http://www.wireless.bristol.ac.uk
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
