Et connectes a eduroam amb Android? Canvia't el password!

Submitted by Jaume Moral on Fri, 14/07/2017 - 11:08

From June 13 to 15, the Rediris Technical Conference was held in Santander, bringing together ICT staff from all Spanish universities. This article is not intended to be a chronicle of the days, but a reflection on one of the first and most interesting talks that could be seen.

The talk carried the promising title of "edurogue: Capturing institutional credentials from Android terminals". Alberto Martínez, the speaker of the talk, came with a laptop with Linux with a modified version of freeradius and hostapd to mount an access point. Then he warned that he would proceed to capture the usernames and passwords of all those who were connecting to eduroam in an unsecured manner. To do this, they simply temporarily shut down the access points that gave access to eduroam from the auditorium and launched the relevant software on their laptop (I insist: a simple laptop, without any additional hardware). After a few seconds, on the screen of the auditorium, began to appear properly obfuscated the access credentials of many of the users in the room, without our mobile display any warning or error screen apart momentarily we were without internet connection.

How is it possible?

The reason for this ease in obtaining credentials is that when we define our connection to eduroam, it is mandatory to specify which protocols must be connected (TTLS + PAP, in the case of UPC) and a mail and password. From the domain of the mail, the access point sends to the client of eduroam the server of our university to validate the credentials. Then, our phone creates a secure, encrypted connection to TLS to authenticate but leaves hanging a very important step: By default the server certificate is not validated unless we expressly specify that we want to do so.

That is if our screen looks like this:

And the CA certificate field is blank, then our Android will connect to any Access Point that is advertised as eduroam (so far it's the default behavior), but then establish a connection to validate the credentials without checking if it presents a valid certificate that identifies it as the server of our university. In other words, we are giving our credentials to the first one who asks for it. And remember that these credentials in the case of the UPC are not only for the Wi-Fi, but for ALL the services provided by the UPC.

How to solve it?

The solution is obvious. Put to the connection information the CA certificate that allows us to validate the identity of the server. By default the list is empty and does not allow us to choose anything, which does not help to know what we have to do. In order for the list to appear something, we must first install the certificate to the system. In the case of the UPC, the certificate can be found here:

And once installed in our Android, we can choose and finish completing our settings correctly.

But there is an easier solution. We can download an official eduroam app that allows you to create profiles already prepared for each university with the correct settings. The application is visually awful, but it does its job to configure the connection with the certificates they play: Note that this app is not necessary to connect, but only to create the profile with all the data necessary to have a secure connection.

And if I do not have Android, am I protected?

It is possible to say that this behavior only occurs in Android. In other systems, the certificate is validated, either by specifying the certificate or by asking the first time if we trust, such as the browser does when we connect to a page with a not known certificate.

In the particular case of iOS... eduroam is configured by installing a profile file that already contains the certificates and therefore is already configured securely. It is possible to configure it so that it does not validate, but it's more difficult.

More information

If you have been curious about this subject, you can see the whole talk that Alberto Martinez, from the University of Deusto. There they will explain other issues such as how to force people to have the client correctly configured. An issue that, as I advance, is not trivial to solve.

And for those who are curious ... my cell phone was one of those that were misconfigured and therefore during the talk my password was "catched". That's why I wrote this article, to prevent that this does not happen to anyone else!


Follow us on

Els nostres articles del bloc d'inLab FIB


inLab FIB incorporates esCert


inLab is member of