signed server certs (was: Freeradius2 and OSX clients no TLS)

[John Dennis]

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

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/