TLS certificates authorities.
Hi, I'm using EAP-TTPS+PAP for authentication. Are there any way to prevent WiFi SSID spoofing without distributing my own CA certificate? Does it make a sense to sign my server key with any of the public CA and what should I supply as CN for such key? Thank you! -- Bogdan Rudas Head of Minsk IT Support Department Exadel Inc. http://www.exadel.com/ E-mail: brudas@exadel.com Skype ID: bogdan.rudas -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
On Sep 8, 2016, at 1:56 AM, Bogdan Rudas via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'm using EAP-TTPS+PAP for authentication. Are there any way to prevent WiFi SSID spoofing without distributing my own CA certificate?
No.
Does it make a sense to sign my server key with any of the public CA and what should I supply as CN for such key?
You should use a self-signed CA. It's just better. Alan DeKok.
Hi,
I'm using EAP-TTPS+PAP for authentication. Are there any way to prevent WiFi SSID spoofing without distributing my own CA certificate? Does it make a sense to sign my server key with any of the public CA and what should I supply as CN for such key?
use your own CA...as for distributing it - it wil be installed with an 802.1X profile deployment tool....which *especially* for EAP-TTLS/PAP you should be using (because clients REALLY need to be configured correctly/securely when using that method!) alan
Hi, Could you please clarify you warning regarding client configuration? Some systems allow my EAP-TTLS+PAP configuration out of the box, do you mean in could be insecure? Are there any way to prevent client authentication unless it have my CA installed? Thank you. On Thu, Sep 8, 2016 at 8:43 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
I'm using EAP-TTPS+PAP for authentication. Are there any way to prevent WiFi SSID spoofing without distributing my own CA certificate? Does it make a sense to sign my server key with any of the public CA and what should I supply as CN for such key?
use your own CA...as for distributing it - it wil be installed with an 802.1X profile deployment tool....which *especially* for EAP-TTLS/PAP you should be using (because clients REALLY need to be configured correctly/securely when using that method!)
alan
-- Bogdan Rudas Head of Minsk IT Support Department Exadel Inc. http://www.exadel.com/ E-mail: brudas@exadel.com Skype ID: bogdan.rudas -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Hi,
Could you please clarify you warning regarding client configuration? Some systems allow my EAP-TTLS+PAP configuration out of the box, do you mean in could be insecure? Are there any way to prevent client authentication unless it have my CA installed?
The TLS channel is the only line of defence against credential theft. If users choose to ignore security warnings related to the certificate, anyone can present an arbitrary certificate and the user's device will merrily deliver the password in cleartext to anyone who's asking. The situation is *slightly* less critical with TTLS-MSCHAPv2 or PEAP because at least they only transmit the NTHash of the user's password, not the cleartext. NTHash can meanwhile be broken rather trivially though, so this won't stop a determined attacker. Getting the cert validation done right really is the only working repellant against rogue AP+rogue RADIUS server attacks. Funny enough, this situation is explained extensively on www.freeradius.org :-) http://freeradius.org/enterprise-wifi.html (look at "User Device Configuration") Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Fri, Sep 9, 2016 at 10:52 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
Could you please clarify you warning regarding client configuration? Some systems allow my EAP-TTLS+PAP configuration out of the box, do you mean in could be insecure? Are there any way to prevent client authentication unless it have my CA installed?
The TLS channel is the only line of defence against credential theft. If users choose to ignore security warnings related to the certificate, anyone can present an arbitrary certificate and the user's device will merrily deliver the password in cleartext to anyone who's asking.
The situation is *slightly* less critical with TTLS-MSCHAPv2 or PEAP because at least they only transmit the NTHash of the user's password, not the cleartext.
NTHash can meanwhile be broken rather trivially though, so this won't stop a determined attacker.
Getting the cert validation done right really is the only working repellant against rogue AP+rogue RADIUS server attacks.
Thank you, Stefan. This is clear for me. Are there are any EAP flavor that uses strong hash and can handle SSID spoofing well? -- Bogdan Rudas Head of Minsk IT Support Department Exadel Inc. http://www.exadel.com/ E-mail: brudas@exadel.com Skype ID: bogdan.rudas -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.
Hello,
This is clear for me. Are there are any EAP flavor that uses strong hash and can handle SSID spoofing well?
EAP-TLS brings all the security you ever want with its use of client certificates. It also brings all the complexities of cert management you do not want though. EAP-pwd is password-based but the passwords never travel over the wire. probably this is what you want. It's comparatively "brand new" though, and you need to pay some attention if your envisaged client devices all support it. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
To add an experience about this... We 'used' to run EAP-TTLS with PAP (because of the Kerberos backend) for our secured wireless SSID. We have about 8,000 access points and over 70,000 wireless users daily. We had users configure their devices through Cloudpath (we now use SecureW2) to make sure that they require server certificate validation and that it was limited to a private CA. I became concerned at the security implecations for users that did NOT onboard with the proper configurator (those people who manually configure their device and don't enter in anything to prevent MITM attacks). I setup a honeypot with a freeRadius server on the backend by configuring a Linksys Router to broadcast our SSID. The freeRadius on the backend was not configured with any of our stuff, and I ran it in debug mode. Within 5 minutes, I have several credentials. We switched entirely to EAP-TLS within 6 months, and we've been that way for over 3 years now, onboarding hundreds of thousands of devices without issue in a large environment. I strongly urge folks to get off username/password EAP types for wireless. Too much risk. BTW... We are looking for a new Network System Architect (all things systems related around networking | DNS, DHCP, IPAM, Virtualization). The position is open until 9/27. I am having a difficult time getting applicants despite an advertised pay band of $95-$105k (in Chapel Hill, NC). If anyone is interested, please check out: https://unc.peopleadmin.com/postings/105582 Ryan Turner Manager of Network Operations ITS Communication Technologies The University of North Carolina at Chapel Hill r@unc.edu +1 919 445 0113 Office +1 919 274 7926 Mobile -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+r=unc.edu@lists.freeradius.org] On Behalf Of Stefan Winter Sent: Friday, September 9, 2016 3:52 AM To: freeradius-users@lists.freeradius.org Subject: Re: TLS certificates authorities. Hi,
Could you please clarify you warning regarding client configuration? Some systems allow my EAP-TTLS+PAP configuration out of the box, do you mean in could be insecure? Are there any way to prevent client authentication unless it have my CA installed?
The TLS channel is the only line of defence against credential theft. If users choose to ignore security warnings related to the certificate, anyone can present an arbitrary certificate and the user's device will merrily deliver the password in cleartext to anyone who's asking. The situation is *slightly* less critical with TTLS-MSCHAPv2 or PEAP because at least they only transmit the NTHash of the user's password, not the cleartext. NTHash can meanwhile be broken rather trivially though, so this won't stop a determined attacker. Getting the cert validation done right really is the only working repellant against rogue AP+rogue RADIUS server attacks. Funny enough, this situation is explained extensively on https://na01.safelinks.protection.outlook.com/?url=www.freeradius.org&data=0... :-) https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffreeradius.o... (look at "User Device Configuration") Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpgp.mit.edu%...
On Sep 9, 2016, at 9:48 AM, Turner, Ryan H <rhturner@email.unc.edu> wrote:
To add an experience about this... We 'used' to run EAP-TTLS with PAP (because of the Kerberos backend) for our secured wireless SSID. We have about 8,000 access points and over 70,000 wireless users daily. We had users configure their devices through Cloudpath (we now use SecureW2) to make sure that they require server certificate validation and that it was limited to a private CA. I became concerned at the security implecations for users that did NOT onboard with the proper configurator (those people who manually configure their device and don't enter in anything to prevent MITM attacks). I setup a honeypot with a freeRadius server on the backend by configuring a Linksys Router to broadcast our SSID. The freeRadius on the backend was not configured with any of our stuff, and I ran it in debug mode. Within 5 minutes, I have several credentials.
We've done similar tests. People just don't care about security, because it's not their area of expertise.
We switched entirely to EAP-TLS within 6 months, and we've been that way for over 3 years now, onboarding hundreds of thousands of devices without issue in a large environment. I strongly urge folks to get off username/password EAP types for wireless. Too much risk.
I agree. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Bogdan Rudas -
Stefan Winter -
Turner, Ryan H