On 21/09/11 03:11, Christ Schlacta wrote:
Very true, thank you for pointing that out as well.
Note to anyone following:
If you use a certificate signed by a general authority (verisign for
example) then anyone with a verisign cert will be trusted in your place,
and able to "authenticate" your users, IE as a man in the middle.
They'll have access to the un-encrypted password payload (NT,
cleartext), which is a severe security compromise. That's why you
(should) always use an internal Certificate Authority, where you control
which certs are signed and distributed.
This is only minimally correct, IMO.
Many EAP clients will, in addition to trusting the cert, record the CN
of the cert on first connect. Some can even be pre-configured with the
CA cert & CN to expect (google "su1x"). So someone would have to:
1. Get a cert from the same CA
2. With the same CN
Assuming you get a cert from a reliable CA (and not one who, say, can
get tricked by some horrible authoritarian government into giving them a
wildcard cert...) this is much harder.
You are correct that, in an ideal world, using a private CA would be the
easy go-to option. However, with the notable exception of MacOS X and
iOS (which have sensible "first use confirmation" GUI), it's a massive
pain deploying private CA. It's entirely understandable that people make
the cost/benefit evaluation and come down in favour of a public CA.
All this could have been avoided if X.509 wasn't broken by design of
course, but that's a topic for another forum ;o)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
