The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Martin Pauly <pauly AT hrz.uni-marburg.de>]

Am 17.08.21 um 14:46 schrieb Patrick Oberli:
> So it seems that Windows doesn't validate anything (for a correctly
> signed and not outdated certificate) on the first connect, as long as
> the end-user clicks on the connect button.
Yes, this is the wiedespread TOFU policy (Trust On First Use -- then stick to 
this very cert).
> I haven't tested if Windows would complain if the thumbprint of the
> certificate now would change, but I hope it does.
Yes it should complain, and ask for TOFU again for any new cert.

> I assume this is different if the profile has been pre-provisioned in
> any way through an MDM or similar.
Yes, "similar" may mean to run the CAT tool (or geteduroam) on the device 
before connecting.
The CAT tools in fact provide a kind of minmal MDM only for the bit of 
functionality
that handles eduroam connectivity.

> In the case of Android 11, which was already connected to this SSID
> with the previous valid certificate, my phone didn't complain at all
> about the new "valid" certificate (although even the Root CA
> switched). Probably because the new one was still signed for the same
> domain (CN = radius.ost.ch) and I entered ost.ch in the Wi-Fi profile
> properties.

If the root cert really differs, this should worry you.
Was the Android set to check cert data and server name?
Then it MUST refuse the connection. Otherwise you have to suspect that
it is not checking anything -- as is the case for the majority of Android 
devices in eduroam.

But if the new cert has been signed by the root cert your Android already was 
set up to expect,
everthing is fine. As long root cert and server name do not change,
the verification process is exactly the same, and hence the result is the 
same.
Have a look a the settings in the Android to clarify what it expects.


One more thing: I wrote about web browsers and the like:
> these technically do the same kind of check, but apply the rules in a much 
> more liberal way
> - Accept any PKI whose root cert is in /etc/ssl/certs (or its 
> Windows/MacOS/Whatever equivalent)
> - Infer the server name to check for from the HTTP/IMAP/etc. request the user 
> has issued,
>   not from some predefined config

Android as provided by Google (e.g. AOSP, Pixel phones) has adopted this 
policy for WiFi 802.1X
logon as a sort of default. The old, really dangerous "Do not validate" 
setting is gone.
The most liberal way to go is called "Use system defaults". This means:
 - Accept any PKI whose root cert is in Android's JAVA certs store (Android 
equivalent of /etc/ssl/certs).
Since the supplicant still has no clue as to the servername to expect, it 
accepts anything.
So by using this setting you end up with a pretty weak cert check which is
- much worse than the "waterproof" config you would like to have (and is the 
goal of the CAT/geteduroam tools)
- much better than the old "Do not validate" setting.

To complicate things even more, Samsung re-introduced "Do not validate",
so you even have it in their Android 11 devices. Most poeple will use it
unless you force them otherwise (force, not advise).

> I wonder now why I did all the fuss about a certificate for all servers in the past, as long as all servers have the same certificate, regardless of the CN and Subj-Alt-Names. 
Yes you can simplify your life here.

Please do not simplify your life with regard to the Android phones,
this is the tough thing as long as PEAP/MS-CHAPv2 and EAP-TTLS/PAP
logons are needed for e.g. Windows clients.

What would help? Prevent client configs that hand out the clear
password or the slightly obfuscated NTLM Hash to an Evil Twin:
1. EAP-TLS
2. EAP-PWD as THE single auth method in your network, NO PEAP, NO 
EAP-TTLS/PAP (EAP-PWD finally delivers the promise of MS-CHAP)
3. Require something "special" despite providing PEAP with passwords. The 
only thing I know about in a BYOD+self-service
   environment like ours is requiring a special outer ID. In our empirical 
investigation which involved a real attack,
   not a single client configured to our requirements would fall victim to 
our Evil Twin,
   but 100+ Android devices configured "naively" did.

Fortunately, CAT does support putting a special outer ID in your profile,
so #3 is our real-world way to go for now.

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