On Sun, Sep 8, 2024 at 1:10 PM Martin Pauly <pa...@hrz.uni-marburg.de> wrote:
> On 07.09.24 07:14, Daniel Lenski wrote:
> >> Ooh, interesting. Reading between the lines a bit here… "leaving a CA
> >> setting blank" in WiFi enterprise authentication (802.1x) resulted in
> >> "don't validate the RADIUS server's certificate at all." So your
> >> clients then connected to forged/spoofed APs+RADIUS servers!?
>
> Exactly. Especially Android devices used to do this in vast numbers (~30%),
> as of 2020 (had been even worse since at least 2008). During a change of
> root cert (preadating the one mentioned above) we were really troubled
> about our eduroam users, so many devices to set up/renew. But it went so
> smoothly
> that we got suspicious. We launched an investigation (including a real world
> attack)
> which confirmed our apprehensions. During the course of this investigation,
> the option "Do not validate" suddenly started to disappear from the Androids.
> Turns out, others had also understood the issue to its full extent and put it
> on their list.
> WPA3-R2 prohibits the presence of that option (thanks here to Stefan Winter).
> Now I compare this to
Interesting. eduroam is the only 802.1x-using wifi network that I've
ever configured *for myself*.
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. And if my device is sending any
non-e2ee'd-and-cert-validated traffic, it's already susceptible to
eavesdropping and MITM attacks by middleboxes on *any* network.
Am I missing something in this case?
I'd contrast this with a corporate or institutional wifi network
("BigCorp-Internal") where connecting to the internal network might
imply some actual trust boundary between inside and outside, and so a
forged AP would be of concern both to admins and to end users.
Daniel
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
