--cafile enabling system-trust nevertheless?

[Martin Pauly]

Am 11.09.24 um 05:29 schrieb Daniel Lenski:
> But as an end user of eduroam, why should I actually be concerned if
> I've connected to a "counterfeit" eduroam access point, as long as it
> gives me real internet connectivity? The eduroam network doesn't
> really give me access to any particular internal network. There isn't
> really a trust boundary with eduroam. 

It all depends, e.g. on the network segmentation of the institution at hand.
The 802.1X "Evil Twin" situation has been really bad due to a combination
of circumstances:
1. SSID is the same everywhere around the world (sounds trivial, but makes attacks even more effective)
2. Unlike HTTPS, IMAPS etc., here is no DNS step involved when the end device makes
    first contact with the local RADIUS server. It just starts EAP over LAN/WLAN
    negotiations; the EAP messages carry the TLS stuff. The wireless infrastructure forwards these
    as EAP over RADIUS to their local RADIUS server which acts as SSL server side, presenting its certificate.
    So at least the client MUST talk to anyone claiming to be "eduroam" from the start, including a rogue AP.
3. This will do no harm, IF the supplicant (client) checks the cert of the peer, Server Name + CA is sufficient.
    Both SHOULD be configured with the supplicant beforehand. If not, you will get a "Trust this server?" question
    on Windows and most Apple devices.
4. If the client skips cert validation, it will hand its password to whatever RADIUS server it is talking to.
    Turns out, this had been the case with ~90% of Androids in 2008, and ~30% of Androids in 2020.
    Due to the EAP-Success Bug of 2018, some iOS devices where also affected in 2020, but only a small fraction.

Why have Android supplicants been that ignorant?
First, users won't notice a difference, the gullible device connects to both correct and rogue eduroam WiFis.
Second, the CA and Server name settings for a particular SSID seemed to slip away at least with every update.
Also, a change to settings of some _different_ SSID could cause a silent reset to CA = Do not validate.
Third, the fallback to connect anyway is _much_ more dangerous than the "Trust on first use" approach
of other manufacturers. Phones are "always on", longing for a known SSID to send their password to.

All this adds up to a toxic mix and makes the attack trivial.
The real damage that comes out of this largely depends on what the attacker can do with a stolen
eduroam password. If it gives the attacker access to e.g. the home institution's VPN (which has been the case with
a great many institutions), the fun starts right away, as presumably happened to us.
OTOH, in the rare case of client-side certs (EAP-TLS), the credential won't leave the client,
and a rogue AP can hijack a single session at best.

As to the current state of affairs, I can only guess. While we could watch CA="Do not validate"
from most clients during 2020 because Google had removed it from AOSP, some manufacturers would happily patch in
their old codebase, and there it was again e.g. in Motorola phones.
I can send a detailed report to anyone interested. Interestingly, there are effective countermeasures
even if you use passwords with BYOD devices.

Cheers, Martin


-- 
   Dr. Martin Pauly     Phone:  +49-6421-28-23527
   HRZ Univ. Marburg    Fax:    +49-6421-28-26994
   Hans-Meerwein-Str.   E-Mail: pauly at HRZ.Uni-Marburg.DE
   D-35032 Marburg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4241 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20240911/9ef81119/attachment-0001.p7s>