Re: Check server name with or without wpa_supplicant.conf (WPA Enterprise)

["Darren Albers" <dalbers gmail com>]

On Fri, Jan 2, 2009 at 8:56 AM, Sergio Belkin <sebelk gmail com> wrote:
> 2009/1/2 Darren Albers <dalbers gmail com>:
>> On Thu, Jan 1, 2009 at 9:45 PM, Sergio Belkin <sebelk gmail com> wrote:
>>> Hi,
>>>
>>> I want to connect to a
>>> wireless network either WPA(2) Enterprise TTLS/PAP or WPA(2)
>>> Enterprise(2) PEAP/MSCHAPv2. I could connect using NetworkManager. But
>>> AFAIK NetworkManager lacks the capability of check server radius name,
>>> so there is somewhat insecure. I'd like provide a workaround using
>>> wpa_supplicant.conf .(that it seems has such a capability) that  along works
>>> with NetworkManager, (in fact I have the maybe wrong impression that
>>> it is not aware of wpa_supplicant.conf) but I don't understand how
>>> modern distros like Fedora or Ubuntu make interact those software with
>>> each other.
>>>
>>> How can I make things work?
>>>
>>> Thanks in advance
>>>
>>>
>>> --
>>> --
>>> Open Kairos http://www.openkairos.com
>>> Watch More TV http://sebelk.blogspot.com
>>> Sergio Belkin -
>>> _______________________________________________
>>> NetworkManager-list mailing list
>>> NetworkManager-list gnome org
>>> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>>>
>>
>> It does have the ability to validate that the cert used by the Radius
>> server was issued by Certificate Authority you trust so that helps
>> ensure that you don't send your credentials to any rogue AP.
>>
>> Network-Manager calls wpa_supplicant over dbus so in theory any
>> feature wpa_supplicant supports Network Manager can support (It does
>> not have the ability to interact with a local wpa_supplicant.conf).
>> The questions is likely the benefit of the addition.   I personally
>> don't see much benefit to this, if someone wants to spoof your
>> connection and all you are relying on is the Radius server name to
>> validate the wireless network then as an attacker
>
>
> But I'd want to add the verification of the radius server name to the
> existing certificate checking...
>
>  I am going to
>> connect to that AP and see what that radius server calls itself when
>> it passes me it's public key.
>
>  Then just mimic it so that your clients
>> will connect to me...   Unless I am missing something?
>>
>> To secure your Wireless network always use a certificate signed by a
>> trusted authority and ensure that all clients validate that before
>> sending their credentials.
>>
>
> Fix me if I am wrong, what if someone make a certificate from a same
> CA as radius server is using?
>

I see where you are going and it does make sense that Network Manager
should validate the name or at least the domain name somehow since an
attack could be to stand up a new wireless network using the same name
as a corporate network.   Find out that the corporate Radius server
uses a certificate issued by Verisign so then I go out and get a cert
from Verisign for my domain and use that.   Since NM only checks that
the cert was issued by a trusted authority I would be blindly sending
my credentials to an external network.

It would probably be sufficient to say something like:  "You are
connecting to foo.com, if this is the correct network please click
accept and save"    In theory that should be very difficult  (The
whole CA's using MD5 issue should be gone since RapidSSL and others
will no longer issue certificates using MD5) to get a valid
certificate for a domain you don't own since commercial CA's /should/
validate ownership of the domain they are issuing the certificate for.
  Using just the domain for validation would avoid confusing users
when they see the servername which can be confusing depending on the
environment.   I know this is not always the case so if you don't feel
comfortable trusting one of the external CA's then you can always
stand up your own CA and use that so you know that no rogue
certificates can be issued.

I always fail at user-interfaces so I will leave it at this but I do
agree that this is probably an issue....