--cafile enabling system-trust nevertheless?

[David Woodhouse]

On 11 September 2024 18:22:51 BST, Martin Pauly <pauly at hrz.uni-marburg.de> wrote:
>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.

You skipped over an important detail there without calling it out explicitly:

We choose EAP methods which involve handing our password in plain text (even if over EAP-(T)TLS) to the server we happen to be talking to.

I feel that warrants more attention.


>   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
>
>