We are trying to use the sign-on splash page using our own radius server. The authentication works well.
My question is - the communication between the client and Meraki is encrypted since the Meraki splash page is secured with SSL.
However from what I understand the requests made by the Meraki cloud to our RADIUS server does not seem to be encrypted? Password are sent via PAP in plain text? Isn't this a security risk?
The requests that my radius server receives from the Meraki cloud contain the password (no hash) and the authentication is done via PAP, so this is insecure unless I'm mistaken.
The communication between the Meraki cloud and a radius server would have to be secured using EAP somehow if we want this to be secure, right?
Passwords are sent in clear TXT, correct. There have been efforts to resolve this for other technologies like WiFi which allows PEAP, EAP-TLS, EAP-TTLS - but there is no way to do this for a portal login.
I just tested using tcpdump like you did. You're right the password is not passed in plain text, however try running freeradius in debug mode and you will see the unhashed password in the User-Password attribute of the request. I think Meraki simply XORs the password with the freeradius server secret, which is better than nothing, but still very insecure.
As I suspected it is using PAP, see https://wiki.freeradius.org/glossary/PAP
On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one- way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the Request Authenticator. This value is XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User- Password Attribute. If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first xor. That hash is XORed with the second 16 octet segment of the password and placed in the second 16 octets of the String field of the User- Password Attribute. If necessary, this operation is repeated, with each xor result being used along with the shared secret to generate the next hash to xor the next segment of the password, to no more than 128 characters. The method is taken from the book "Network Security" by Kaufman, Perlman and Speciner  pages 109-110.