Secure RADIUS protocol when using Splash page Sign-on with my RADIUS server

[Danut]

Hello everyone,

I've made great progress into implementing the RADIUS servers into our network especially to be able to authenticate users connecting to the WiFi network. Everything works great and all the functionality test have passed with little or no problems.

After the functionality tests, I started a few penetration tests to check how well the security is in place and I've got some bad results. I've solved many of this security problems and I am left with one problem that I have no idea how to workaround so far, and that problem is the RADIUS protocol itself, which sends data in clear-text. (I know I should have taught this from the beginning but I didn't know I would get to sent the RADIUS authentication packets to the cloud).

To be more specific, I have made some packet sniffing on UDP coming from the Meraki Cloud towards our internal RADIUS servers and found those clear text information there: SSID name, AP MAC address, calling endpoint MAC address, AP IP address, username and other less relevant information. The user password hash is also there, but is hashed using SSHA512 which is secure enough to be sent over the Internet.

As a security mechanism I didn't expose the RADIUS servers to the public side, I have just made some port forwarding on our gateways which allows only packets coming from the Meraki cloud to access those servers. I have also change the ports to obfuscate the sniffers a bit. But still, the packets (datagrams) are traveling across the Internet containing a lot of information which I am concern someone could use in the process of a reconnaissance attack.

I've looked many ways to secure this problem but I didn't found a solution so far. I saw this problem was previously discussed here, but it has no solution:
https://community.meraki.com/t5/Wireless-LAN/Sign-on-splash-page-with-radius-server-communication-no...

Also, changing the Network access to WPA2-Enterprise with my RADIUS server won't help much, as that will raise other problems I encountered and solved based on my previous post:
https://community.meraki.com/t5/Wireless-LAN/Second-RADIUS-Server-not-Contacted-for-Authentication/m...

Has anyone come to a workaround to this problem? Is Meraki giving some security solution that I am no aware of?


Thank you in advance!

P.S.: I am using FreeRADIUS as a RADIUS service.

[PhilipDAth]

If this is for a splash page - there is no way to secure it given the constraints.

The new trendy way to handle it is to use EAP-TTLS for the RADIUS authentication, but you can't use this with splash pages.  Only WPA2-Enterprise mode.  Lots of devices don't support EAP-TTLS yet.

Some people use two SSIDs.  One for doing the provisioning, and then another (using something like EAP-TTLS) for the actual connectivity.

If it is a closed network you can also use EAP-TLS.  But then you have the hassle of certificates to deal with.

If this is a BYOD environment you can use Systems Manager and the new Trusted Access to simply certificate deployment, but this feature is still a bit bleeding edge.  So unless you want some blood on your hands ...

[Danut]

Thank you for your reply @PhilipDAth 

It's to much work to do to implement EAP-TTLS. And as you mentioned, not all devices supports it.

I was hoping to be able to push the Splash page to the AP somehow and configure the AP to do the authentication via the RADIUS protocol.

I've noticed that the communication between the client and the Splash page hosted in the Meraki Cloud is encrypted via TLS1.2 and I taught it will be possible to have the page hosted on the AP to avoid the RADIUS protocol originating from Cloud and going to my RADIUS servers over the internet.

In the image below I created a flowchart with the actual behaviour (in a very very simple way and not detailed). The lines in red are the RADIUS protocol communicating over the internet with cleartext data.

In the second figure I was thinking of an alternative scenario if possible to implement. The change here would be the Splash page hosted on AP. The AP shall pull the page from cloud with an encrypted protocol (TLS1.2) and the RADIUS request for authentication shall be sent from Meraki AP to the RADIUS server (blue lines). This way, the cleartext data from RADIUS protocol would only travel through the private network which is more secure and prevents unauthorised people of "peeking" at this data.

I hope it makes sense for what I wanted to say, since I excluded some details to make this post shorter.

Also if the scenario I proposed is valid and is possible to implement, is there a document that describe the How-To?

Thank you in advance

[PhilipDAth]

Great ideas @Danut but alas you can't host pages on the AP itself, or have the AP send the RADIUS request itself when it is operating in splash page mode.

[Danut]

I know the AP can't host pages, but I was thinking of a handover done by the AP. Still struggling to find a solution to my initial problem.

[Danut]

I went a bit further and I taught I found a solution, but I ended up to the same scenario.

I was thinking to host the splash page locally with hope that the RADIUS request will eventually be sent through the splash page to the internal RADIUS servers avoiding clear-text messages over the internet.

Unfortunately the documentation makes it clear that the RADIUS messages will be sent to the Meraki first, then to the public RADIUS server.
Source: https://meraki.cisco.com/lib/pdf/meraki_whitepaper_captive_portal.pdf

Unfortunately I was not able to find a workaround to this. Currently this is a blocker in our network and we are force to use the WPA2 with pre-shared key authentication model. I was really hoping to use an enterprise model for WiFi authentication. Not sure if its worth opening a case, but I wanted to post these messages in case anyone else has this problems.