Higher Education

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted
Moderator

Re: educating users about .1X config

I don't believe they can do the Apple workaround, but they can install your CA cert and/or trust the public CA cert.



If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Frequent Contributor I

Re: educating users about .1X config

ClearPass QuickConnect

We have never heard of this product... I will contact my rep and ask him about it.  We were only told about the much more expensive piece...

Highlighted
Moderator

Re: educating users about .1X config

Here's some sample screenshots of CP QuickConnect

 

qc-web.PNG

 

qc-win.png



If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
New Contributor

Re: educating users about .1X config

Tim, can you point to some good reading material on this vulnerability?

 

Thanks,

Jim

Highlighted
Moderator

Re: educating users about .1X config

Attached is the presentation on 802.1X from Airheads. I went over MiTM and 802.1X. Also, you can just run a google search for "802.1X man in the middle" and you'll find a plethora of information.

 

 



If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Frequent Contributor I

Re: educating users about .1X config

doing a man in the middle is quite easy if you do not verify certs.  Setup a linux box with free radius hook on an AP setup the identical SSID, and then capture any authentication requests, then hack the hashed passwords.

 

But we have found that depending on who is behind the computer - even if you enforce verification, etc... If the OS allows you to still connect people simply ignore the message and connect anyway...

Highlighted
Moderator

Re: educating users about .1X config

The supplicant can be configured to not prompt users to accept new
servers/certificates.


If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
All-Decade MVP 2020

Re: educating users about .1X config

Getting back to the topic of this thread can anyone please tell me what they do to nudge users to the SSID which helps them onboard (configure) for the .1X SSID? Tim, your screenshot implies users need to go to a different SSID (brandeis_guest) to launch QuickConnect to configure for .1X.

 

My original question is how are people spreading the word tio their user community that they must go to the "onboarding" SSID first to configure for the ".1X" SSID. Our users are not doing this inuitively. They are connecting to the "SECURE" (.1X) SSID first. Because most devices lack the basic ingredients for EAP-TTLS they never successfully authenticate. At that point they either quit and connect with the open SSID permanently or they go to the Help Desk who (surpise!) tells them to run the config tool by going to the "onboarding" SSID.

 

Mike

 

 

Highlighted
Contributor II

Re: educating users about .1X config

Mike-

 

We use three SSIDs.  We struggled with using an additional SSID for onboarding - but for us, it has been worth it; particualrly if you disable low data rates for beacons.

 

*HWS-Private is our PEAP/MSCHAPv2 SSID

*HWS-Public is an Open Auth SSID with Captive portal "click to accept terms" button.  Not perfect but annoying enough to keep Students going to the HWS-Private SSID instead of staying on the Authed SSID and guests from just autoconnecting all the time.

*HWS-Get-Connected is our Open Auth with Captive Portal SSID.  We use DHCP fingerprints to steer clients to a Captive portal unique to their platform (as close as we can get) or fallback to a "generic" Captive portal.  The user profile has no access to anything but the CP.  In all plaforms , the initial captive portal pages have two buttons: "Guests/Visitors" and "Student/Facuty/Staff".  Each button is a link to instructions to connect for their platform/faqs  or an onboarding tool which does supplicant configurations (including setting valid Radius server name/cert chain).  If we registered devices, this SSID would be the natural place to put this.

 

It has worked pretty well for us.  I suspect if we registered devices and/or had Clearpass, we could consolidate down to two SSIDs... but we don't at the moment.

 

I'm going to go on a tangent here thought: As Tim points out, it still doesn't protect us from the user connecting directly to the PEAP/MSCHAPv2 SSID and setting up a weak supplicant profile, not neccesarily validating the radius server.  In this case it depends entirely on the default OS behavior.  In the iOS case, I've found it stores the Radius *cert* (not name) with the wifi network config after the user "accepts" the installation of the cert (and if memory serves me, the cert will show as unverified regardless of the CA).  Unfortunately, this means that when the Radius cert legitimately needs to be replaced if it is due to expire (or, you know... is a little Heartbleed-y) - the user will be prompted to accept a new copy of an updated certificate (and thusly prompted again).  I see two things wrong here - a) the wireless profile is not actually validating the server by it's name - it's looking for an identical certificate as was installed when the wireless profile was set up by the OS supplicant.  I *think* (call me out if I am wrong) MITM should be avoidable by validating the server name through it's CA chain - regardless of the individual certificate thumbprint/serial.  In my observations this is how the MS stack handles server validation; as does on iOS in the case of a properly installed profile via Mobileconfig. b) By storing the cert and forcing users to constantly "accept" a cert as it changes (even when both are legitimate); we continue to train people to just click "accept" - more or less invalidating server validation and opening up users to the same MITM risks as not enforcing server validation.

 

Kevin Schoenfeld

Highlighted
All-Decade MVP 2020

Re: educating users about .1X config

Thanks Kevin,

 

The thought of an "onboard only" SSID occurred to us but that would put the campus-wide SSID to four and I hoped to keep the count to  three. Still, this may be a potential solution.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: