signed server certs

[James J J Hooper]

On 07/03/2011 22:18, Arran Cudbard-Bell wrote:
>
> On Mar 7, 2011, at 4:05 PM, James J J Hooper wrote:
>
>> 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.
>
> That's not really true, even windows requires the user confirm that they trust the CN in the certificate unless the CA has been *explicitly* trusted, and none are by default.
>
> The CA would have to fail to verify that the domain used in the CN of the CSR was actually owned by the entity requesting the certificate

Of course, that is true (on windows and mac) ... but Android? some linux? 
Windows Mobile? ...


> or the user would have to fail to manually validate the CN presented to them by the supplicant.

I forgive my cynicism, but users click 'yes connect me', for one of two 
reasons:
1) they don't read the popup, and 'yes' usually means 'make it work'
2) they have no clue what the CN should be, so bristol.com, 
bristol.wifi.com, uni-wifi.co.uk, eduroam.wireless.bris.ac.uk are all just 
as good.

	(2) isn't the end user's fault ...the admin or the setup wizard should 
configure the CN validation for the end user.


...or the user gets "popup panic" and call IT support. Which comes 
full-circle:  just configure it right in the first place ;-)

-James


-James