

ca_cert = "/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem"



Normally, the access point is configured to use a specific radius server which will send the certificate to the client (I do not know if it is even possible to use WPA-Enterprise in any other way). This means that by not agreeing on one CA for the entire eduroam infrastructure, the user has to NOT configure any CA in his WiFi settings to be able to use eduroam in the way it was intended to. And with this, we have the first reason for eduroam being insecure by design.



wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with 00: 25 : 45 :b5: 38 : 22

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 3 subject = '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 2 subject = '/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully

wlan0: WPA: Key negotiation completed with 00: 25 : 45 :b5: 38 : 22 [ PTK =CCMP GTK =TKIP ]

wlan0: CTRL-EVENT-CONNECTED - Connection to 00: 25 : 45 :b5: 38 : 22 completed ( auth ) [ id = 0 id_str = ]





CA:

C =DE

ST =Some-State

O =h4des.org

CN =sqall



certificate for rogue access point:

C =DE

ST =Some-State

O =h4des.org

CN =some-rogue-access-point

emailAddress =sqall





ca_cert = "./CA.cert.pem"





wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with b0: 48 :7a: 88 :fc:7a

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 4 - > NAK

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Some-State/O=h4des.org/CN=sqall'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Some-State/O=h4des.org/CN=some-rogue-access-point/emailAddress=sqall'

EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request





wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with 00: 25 : 45 :b5: 38 : 22

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 3 subject = '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 2 subject = '/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully

wlan0: WPA: Key negotiation completed with 00: 25 : 45 :b5: 38 : 22 [ PTK =CCMP GTK =TKIP ]

wlan0: CTRL-EVENT-CONNECTED - Connection to 00: 25 : 45 :b5: 38 : 22 completed ( auth ) [ id = 0 id_str = ]





CA:

C =DE

ST =Some-State

O =h4des.org

CN =sqall



intermediate CA:

C =DE

ST =Some-Other-State

O =h4des.org

OU =intermediate

CN =it is sqall again



certificate for rogue access point:

C =DE

ST =Some-Other-State

O =h4des.org

OU =intermediate certificate

CN =again sqall





wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with b0: 48 :7a: 88 :fc:7a

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 4 - > NAK

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 2 subject = '/C=DE/ST=Some-State/O=h4des.org/CN=sqall'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate/CN=it is sqall again'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Some-Other-State/O=h4des.org/OU=intermediate certificate/CN=again sqall'

EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request





mschap: Sat Jan 11 19 : 42 : 27 2014



username: pawlxyz @ ruhr-uni-bochum.de

challenge: 43 :cd: 42 :0f:a6: 14 : 46 :4e

response: 0d:b8: 47 :c0: 11 :a6:c9: 10 :a2: 14 : 99 :af:1d: 15 :d6:ef:4a: 89 :d3: 95 :aa:ba:2d:2b

john NETNTLM: pawlxyz @ ruhr-uni-bochum.de: $NETNTLM $4 2cd490fa604464c $0 db486c012a6c910a21379ef1d15d6ff4a89d395baba2d2c





wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with b0: 48 :7a: 88 :fc:7a

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 4 - > NAK

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 3 subject = '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 2 subject = '/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/OU=xxx/CN=xxx'

EAP-TTLS: Invalid authenticator response in Phase 2 MSCHAPV2 success request





mschap: Sun Jan 12 01: 24 :03 2014



username: pawlxyz @ ruhr-uni-bochum.de

challenge: 28 :f5:bf:4d:3f:fe:bf:a2

response: 7a:ab: 24 : 87 : 35 : 82 : 46 : 40 : 33 : 73 : 89 :5a: 77 :bb:ee:c0:4b: 56 :8b:a8: 67 :af:e9: 94

john NETNTLM: pawlxyz @ ruhr-uni-bochum.de: $NETNTLM $2 8f5bb4d8ffaafa2 $7 aab248735824641d373895a77dbeec04b568ba867afe994





X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment

X509v3 Extended Key Usage:

TLS Web Client Authentication, E-mail Protection





wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with b0: 48 :7a: 88 :fc:7a

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication starte

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 4 - > NAK

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

TLS: Certificate verification failed, error 26 ( unsupported certificate purpose ) depth 0 for '/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall'

wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason = 0 depth = 0 subject = '/C=DE/O=Ruhr-Universitaet Bochum/CN=sqall' err = 'unsupported certificate purpose'

SSL: SSL3 alert: write ( local SSL3 detected an error ) :fatal:unsupported certificate

OpenSSL: openssl_handshake - SSL_connect error: 14090086 :SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed



This is not possible when different top CAs are used in each country (or perhaps even within a country). Or rather this is only possible when certificates are not checked. But when they are not checked, what is the point of using TLS/SSL?



wlan0: Trying to associate with SSID 'eduroam'

wlan0: Associated with 00: 14 :a8: 14 : 86 :f1

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 ( TTLS ) selected

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 3 subject = '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 2 subject = '/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 1 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=Ruhr-Universitaet Bochum CA/emailAddress=rubca@ruhr-uni-bochum.de'

wlan0: CTRL-EVENT-EAP-PEER-CERT depth = 0 subject = '/C=DE/ST=Nordrhein-Westfalen/L=Bochum/O=Ruhr-Universitaet Bochum/CN=radius.ruhr-uni-bochum.de'

EAP-TTLS: Phase 2 MSCHAPV2 authentication succeeded



This article seemed to inspire a student to write his Diploma thesis about the topic. After some coincidences, I was asked to help to write an academic paper about the investigation and results of the thesis. This paper was published at the ACM WiSec 2015 conference in NYC. If you are interested in the findings, I would suggest to you to read the paper " A Practical Investigation of Identity Theft Vulnerabilities in Eduroam " instead of this blog article. This blog article was just a quick look into the deployed eduroam network and not a researched study.A last fun fact: We had also a demo at the ACM WiSec 2015 were we used a self-signed certificate for a rogue eduroam access point. Even there the results were that over 50% of the attendees had wrongly configured eduroam devices and were therefore prone to an easy identity theft attack.Over Christmas I got a TP-Link TL-WN722N USB WiFi device which is supported by hostapd and finally I could test what I always wanted to test: eduroam.But first, what is eduroam? Eduroam is a WiFi network located at universities around the world with the goal to provide internet access to students and university staff on every university that supports eduroam ( https://en.wikipedia.org/wiki/Eduroam ). This means I can connect to the internet with eduroam at a university in France with my user credentials from my university in Germany. Sounds good, but how does it work? Well, the WiFi network uses WPA-Enterprise, which means you connect to an access point and the access point uses a radius server to authenticate you. Generally not a bad idea. But my tests have shown that the practical deployment of the eduroam network is broken by design.First things first. Some of my notes that I took from my tests can be seen here . I will provide them as a "POC||GTFO". But I stripped them to not provide a step by step tutorial in "how to pwn eduroam".I configured a VM with Debian Wheezy with an installation of hostapd. I never had configured a radiusd and wondered how I can get the user credentials if a client device would authenticate to my rogue access point. Well, I found this cool project https://github.com/brad-anton/freeradius-wpe.git . This does everything for me and I do not have to patch the radiusd myself. But honestly, I do not trust this modified radiusd entirely and after I configured everything I turned of the network interface of the VM which provides an internet connection to prevent the radiusd from leaking something of my tests to the internet.On my first test I just set everything up and started it. I started wpa_supplicant on my laptop and it does not connect to the rogue access point because the certificate is wrong. Ok, but what with my Android device. I activated the WiFi on my mobile phone and ... WTF I am connected to the rogue access point. In the log file of the rogue access point I can read my user credentials in PLAINTEXT. Ok, that is not good. But what went wrong? The certificate used by the rogue access point is still invalid. The configuration on my Android device is completly flawed. I configured my Android device like the tutorial on my universities website said. The tutorial said that I do not have to configure any CA and use PAP for the phase2 of the WPA-Enterprise authentication. Now you can say "Idiot, everyone can see that this is wrong!". But to my defense, I always thought that Android then uses its own installed CAs to check if the certificate of the access point is valid. Hell, even the network-manager on ubuntu warns you if you give no CA in the settings. And I used PAP (I knew it sends the user credentials in cleartext) because I thought of the tutorials of my university that eduroam does only support PAP for the phase2 authentication. But both thoughts were wrong.After I installed the "Deutsche_Telekom_Root_CA_2" CA on my Android device and used it in the WiFi configuration it no longer connects to the rogue access point.Also, when the wpa_supplicant configuration misses this line:it also ignores the invalid certificate of the access point and just connects to it.I wrote the helpdesk of my university about the wrong tutorial for using eduroam on Android devices. The helpdesk replied to me that they knew this problem with the CA but Android is not able to verify the certificate of the access point. This is obviously wrong. And the funny thing about this is, they used screenshots in their tutorial to make it easier for everyone to configure eduroam on Android devices. And on these screenshots you can see the "CA certificate" option which is just ignored. Also their reply told me some other interesting things about eduroam, which I checked in my next tests.As a summary for my first test: always configure the CA for eduroam (and in general for all WPA-Enterprise WiFi networks) and always use MSCHAPv2 instead of PAP. Even if your device connects to a rogue access point the adversary only gets challenge-response values and has to brute-force this. When your password is strong enough, the adversary can not use your credentials (at least he has to spend time brute-forcing MSCHAPv2 ...).In the eMail reply of the helpdesk of my university they wrote me that when the user added the CA to his WiFi settings, this would destroy the idea behind eduroam (to be able to connect to every eduroam access point in the world). First, I wondered about the "destroy the idea behind eduroam" part but then I thought "They would not be so stupid, would they?". I always thought that they agreed to use the "Deutsche_Telekom_Root_CA_2" CA for eduroam. But this is not the case. A friend of mine was in Belgium and had to change the configured CA in his WiFi settings to connect to eduroam there. I searched through some websites for eduroam tutorials of universities of other countries than Germany and they all used different CAs.The eMail also stated that even if the user added the CA to his WiFi configuration, this would not help. An adversary could get a certificate signed by the CA and could therefore set up a rouge access point. This statement is true. But this holds for every public key infrastructure. For HTTPS for example a CA should not sign my certificate for "gmail.com" (unless I can prove that this is my domain/address). And at this point a question comes to mind. The client gets the certificate by the access point and then checks with the configured CA if it is valid. But valid for what address? Normally, the CN (common name) in the certificate is checked with the used address. But with what address is the certificate provided by the radius server checked?A valid connection to the eduroam WiFi at my university with wpa_supplicant looks like this:The address given in the CN is "radius.ruhr-uni-bochum.de". But I never configured this anywhere. So in my next test I created my own CA and signed my own certificate with it. The certificate for the rogue access point and the CA got the following values:You can see, that the CN field got "some-rogue-access-point" as value, which is no address for a radius server at all.First I tried wpa_supplicant with my newly created CA certificate in the configuration file:And what happened? wpa_supplicant connects with the rogue access point without any problems and discloses my user credentials as MSCHAPv2 challenge-response values. The output of wpa_supplicant shows that the radius server uses my newly created certificate.Next I tested it on my Android 4.0.4 device. I installed my own CA on the device and changed the eduroam WiFi settings to check for this CA. The device connects with the rogue access point without any problems and also discloses my user credentials.As a summary for this test: the certificate for the rogue access point just have to be a valid certificate signed by the used CA. It does not matter for which address the certificate was issued, it just have to be valid. Normally, the problem for forging a valid host in an TLS/SSL connection (such as the HTTPS example for "gmail.com" I gave earlier) is, that a CA does not sign your certificate request unless you own the domain/address (or rather the CA should not). But if you can use any address in the CN, it is no problem to get a signed certificate. Here lies the second reason for eduroam being insecure by design. I do not know if the vendor got a service to sign your own certificates with the "Deutsche_Telekom_Root_CA_2" certificate. But normally they do. And if the vendor does, there is absolutely no problem to configure a rogue access point which can not be distinguished from a valid one.It should be mentioned, that the address of the radius server can be configured in the iDevice profiles. But I have no iDevice and so I can not check if the CN of the certificate provided by the radius server is checked against the configured address. In wpa_supplicant for example I did not found any configuration option for the address of the radius server. But I found the option to match certain criteria of the accepted server certificate with "subject_match". Android 4.0.4 does not provide any such options.After an arbitrary signed certificate was tested, the next interesting thing is a certificate signed by an intermediate CA. When we look at the wpa_supplicant output when connecting to a benign access point:we can see, that the certificate is signed by the CA of my university (and not the "Deutsche_Telekom_Root_CA_2" CA). Actually, the chain is "Deutsche_Telekom_Root_CA_2" -> "DFN-Verein PCA Global - G01" -> "Ruhr-Universitaet Bochum CA". So my idea at this point was, it could be difficult (and perhaps costly) to get a signed certificate by the "Deutsche_Telekom_Root_CA_2" CA, but a signed certificate by the university is very easy as student or university staff. So, I created my own intermediate CA signed by my formerly created CA and generate a new certificate for my rogue eduroam access point. The values for all these CAs and the certificate are:Again, wpa_supplicant is tried first. The settings are the same as for the test before (this means wpa_supplicant uses the certificate of the CA to check the validity of the rogue access point). The output of wpa_supplicant shows, that the rogue access point offers my new certificate signed by the intermediate CA and that the client connects without any problems:The log file of my modified radius server shows me the MSCHAPv2 challenge-response values:Next I tested my Android 4.0.4 device. Like the wpa_supplicant client, it connects without any problems (because the access point is now considered valid).As a summary for this test: the client accepts certificates that are signed by intermediate CAs. In this constellation, it is the third reason for eduroam being insecure by design. It might be difficult to get a signed certificate by the main CA. But when intermediate CAs are in place, it could be a lot easier to get a valid certificate. The "Deutsche_Telekom_Root_CA_2" CA signed the "DFN-Verein PCA Global - G01" intermediate CA and this signed the CA of my university. I think that the "DFN-Verein PCA Global - G01" intermediate CA signed a lot of university CAs. And a lot of universities (like mine) offer the service to sign your server certificate (when it is inside the namespace of the university). When you are able to get a certificate that is signed by anyone of the CAs in the chain, you can forge a valid eduroam access point.Ok, all the talk about "uhh, it is insecure with this used public key infrastructure!" and "it is theoretically possible to ...", let's break it! I helped the university to set up some servers. So I have access to a certificate signed by the university CA. And I configured my rogue access point to use this certificate. This certificate obviously does not have "radius.ruhr-uni-bochum.de" as CN value. It is valid for other addresses which I censored out. We saw in the tests above that the value in the CN field does not matter.First I tried wpa_supplicant. Now with the settings that should be used for a valid eduroam access point. This is the output:And we can see that the client thinks it is a valid eduroam access point. The log file of the modified radius server shows my MSCHAPv2 credentials:The same goes for my Android 4.0.4 mobile phone. A client is not able to distinguish a benign eduroam access point from my rogue access point.A fun fact that happened when I just started my rogue access point with the valid certificate: the mobile device of one of my neighbors connected instantly to my rogue access point (his or her login credentials are from a different university than mine). One has to love all the folks that have their WiFi always turned onMy university has the service to provide any student with a client certificate signed by the university's CA. My idea was "most clients do not provide options for the radius server address, perhaps they do not check if the certificate is only for clients". Beforehand, I can tell you that wpa_supplicant and Android 4.0.4 do (I did not test others).I used a certificate with this key usages and signed by my university's CA:So, when I try to connect with wpa_supplicant I get this output:So we can clearly see, that wpa_supplicant checks the certificate purpose. The same goes for Android 4.0.4. It just tells me authentication error.To summarize this part: this does not have anything to do with the design or security of the eduroam network. This is only an implementation thing of the used client software. I just tested it with the hope to find a "fuck up" of some WiFi clients, but was disappointedIn this part I conclude my short security audit of the eduroam WiFi network. In my opinion it has a huge design flaw which is not to fix without changing the whole public key infrastructure. For me it seems that when they were designing the whole eduroam network they just thought "We need some public key cryptography for eduroam. The protocol supports TLS/SSL for authentication. It is used by the internet. So let us just use it too!". Using different CAs in different countries which signed a lot of intermediate CAs is not a good idea when the clients do not/can not check the address of the radius server which provides the certificate. Every certificate that is signed by one of the intermediate CAs or the used top CA is valid for any client that tries to connect to the eduroam WiFi. Furthermore, the idea of eduroam was to provide a network to which a client from a different country could also connect (for example, a client from Germany could connect to an eduroam access point when he is in Belgium).The next thing is, a lot of universities (like mine) provide flawed tutorials to configure WiFi clients for eduroam. Even when MSCHAPv2 is available, the tutorials often used PAP to authenticate the client. PAP sends all user credentials in plaintext whereas MSCHAPv2 provides a challenge-response procedure. Furthermore, a lot of tutorials do not set up the CA to check the server certificate. Without this setting the client connects to any eduroam access point without checking the validity of the server certificate. This means, when an user configured her client with the help of the flawed tutorials and uses eduroam, she could just as well shout out her credentials everytime she is connecting to the WiFi network.The really bad thing about this is, when an adversary gets the user credentials of someone, he often has the user credentials for other services of the university as well because the same account is used (in the case of my university for the email account, the MSDNAA account, ...). I heared of some universities that even use these credentials to let the student subscribe/unsubscribe for exams of the offered courses.The only way a client can protect herself against this attack is by using MSCHAPv2. When MSCHAPv2 is used, the adversary still has to brute force the password when he successfully forges an eduroam access point. This means the security comes from the strength of her password (and the strength of MSCHAPv2 ... which uses DES and can be cracked relatively fast with services like https://www.cloudcracker.com/ :/ ).In my opinion, the only way to really fix this issue is to use an own public key infrastruture for the whole eduroam WiFi design. When an own CA is used for eduroam (perhaps with intermediate CAs for universities to use only for certificates that are used by the eduroam infrastructure) there is no way to forge a valid eduroam access point for an attacker, because he can not get a signed certificate for it. When the clients set up the CA in their eduroam settings, they would not connect to rogue access points. Even if the client is configured to use PAP instead of MSCHAPv2, the user credentials are secure in a way. But the own public key infrastructure would only work when the clients are configured correctly and this means that the universities have to fix their tutorials for the eduroam WiFi first.I wrote my university about this issue and they fixed some tutorials (for example for Android). But not all are fixed (for example for wpa_supplicant) and I do not think that they will fix all of them. But even so, fixing the tutorials will not help when a lot of students and university staff already applied the flawed configurations.In the time of writing this article, I have not tested this statement. I just based it on the settings you can made in an access point, the statement of my university and the statement my friend had made. However, yesterday night I drove to the next city to test this statement at an other university (the TU Dortmund). Honestly, I did not expect this result:The wpa_supplicant output shows that even when I am at another university in Germany and use eduroam there, the CA chain looks the same as at my university. This means that my WiFi client still connects to the radius server of my university. I did not expect that (and have not really an idea how this infrastructure works exactly). Unfortunately, I have no way to test it with an university in a foreign country. Nevertheless, my conclusion which states that an own CA should have been used for the eduroam infrastructure remains the same. @fadenb send me this link via twitter . It shows a nice compatibility matrix for eduroam WiFi clients. This site states (like this article) that Android is not able to check the certificate of the radius server against an address. Also a lot of other clients are tested.I also want to mention that my university updated almost all tutorials for the eduroam client configuration on their website by now. Unfortunately, not many of them check the radius server address in their configuration. I send them my wpa_supplicant configuration file (which checks the certificate with "subject_match") and they uploaded it to their website. At least some people which use these tutorials have a secure configuration now.