[WIP] Add IWD support to Linux backend

[Kangie]

• Rewrite existing IWD class
• call IWD functions so it's not just dead code
• use f-strings instead of string.format where sane to improve readability.
• embed CA pem into IWD configuration rather than referencing a file in some user's homedir

Closes: #201
Closes: #278

[Kangie]

Hi Everyone,

After some frustration with the eduroam CAT I took a look at the script and realised that some IWD code existed, but it was all dead code that's not called at all.

Now we search for the iwd backend in the NetworkManager config and write out based on that (or with a --iwd_conf config file option like wpa_suppplicant has).

I'm having some issues with testing this - It consistently chokes on the CA certificate provided by my institution regardless of whether that's the .pem installed to ~/.config/cat_installer or the currently-used-in-code (and preferable) embed style - I'm digging into why now because the certs all pass the sniff test, but I would really appreciate it if someone could get back to me with their results and help me rule out bad config for my institution.

Possible stretch goals:

• IWD uses dbus, we could query that instead of (or in addition to?) the NM config file
• Instead of relying on templating in the IWD configs, it should be possible to generate them from scratch using the institution config (i.e. use EAP method to generate the strings for phase2 (PEAP, TTLS, etc)

I'm very interested in any feedback, please reach out and I'll try and track down where IWD is choking on certificates now that I can generate configs.

[bcbnz]

I tested this by downloading the main.py from this pull request, getting the current eduroam.py for my institute from the CAT website, and pasting the Message and Config sections from the bottom into main.py. I also changed main.py line 850 to write the config to a temporary path so it didn't overwrite my current configuration.

The generated IWD config file is equal to the one I have been using for the last few years. On kernel 6.6 (Arch Linux LTS) it works.

On kernel 6.7 it doesn't work as support for certificates with SHA1 signatures has been disabled and so iwd -- which uses the kernel signature utilities -- cannot verify the certificate chain (Arch forum thread on this issue). If you have kernel 6.7 this might be causing your testing issues. For me, it is the root AAA Certificate Services from Comodo which is the problem.

[bcbnz]

One extra option could be to hash the user's password if mschapv2 is being used. Instead of EAP-PEAP-Phase2-Password, you can specify EAP-PEAP-Phase2-Password-Hash with an MD4 hash of the password (not a secure hash algorithm admittedly). As per the Arch wiki this can be achieved in a terminal with iconv -t utf16le | openssl md4 -provider legacy (press Ctrl-D after entering the password). Since hashlib is not guaranteed to have MD4 (it doesn't on my system), something like the MD4 class from https://gist.github.com/kangtastic/c3349fc4f9d659ee362b12d7d8c639b6 would need to be used; with that class, MD4("foo".encode("UTF-16LE")).hexdigest() gives the same hash as the terminal method. Maybe not worth the hassle given the limited additional security due to the weak MD4 algorithm, but something I thought I would mention for consideration.

[restena-sw]

Just to note that the signature on a root certificate has no trust value - it's a self-signature. Therefore, virtually all OSes have in the past only discontinued certificate verification with SHA-1 along the chain - i.e. for intermediates and end-entity certs.

It would be a very "interesting" move to cut off root CAs like that.

In the specific case of AAA Services though, there's an easy fix: The USERTrust intermediate CA certificate underneath AAA Services has been re-issued as a root certificate of its own long ago, and it signed itself with a SHA-384 sig. Every server that sends a cert chain ending in AAA Services can alternatively and preferably send a chain ending in USERTrust RSA (one cert and at least one round-trip in EAP less).

For a reason unknown to me, the cert provider Sectigo still ships the AAA Services CA by default as the trust anchor for its issued certificates, introducing incompatibility issues here and there. You should contact your eduroam IdP and tell them about the existence of the shorter USERTrust RSA root.

[bcbnz]

@restena-sw Thanks for that information! I have just been talking to our IT contact about this, and that is very useful to know.

[Kangie]

Great. I'm relatively happy with this and can chase down my CA issues - do you want to merge as-is, would you like me to pursue some of the stretch goals before that, or is there anything that I've overlooked?

[Kangie]

I can confirm my issues are 6.7.0/SHA1 related:

openssl x509 -noout -text -in .config/cat_installer/ca.pem| grep -i algorithm
        Signature Algorithm: sha1WithRSAEncryption

[twoln]

I have tested this installer. One thing probably not so great is that admin access is required to set up the connection.
The installer seems to work fine, but the connection is rejected, apparently due to the client being unhappy about the server certificate. The same configuration works fine with wpa_supplicant in place of iwd. It could be that Iam doing something wrong, as I dod not play with iwd before.

And one other thing, we really wanted to get rid of the python script and return to the bash script working with nmcli. Since the iwd approach seems to be just about creating the config file, this should probably be also doable in bash.

And one final remark. The geteduroam Linux client is being developed. There is a good chance that in time it will just replace the current installers - it works with CAT via its API.

[Kangie]

I have tested this installer. One thing probably not so great is that admin access is required to set up the connection.

I'll investigate talking to iwd over dbus and see if we can have iwd write the configuration itself, that should eliminate the need to elevate permissions (and probably get some free config validation at the same time)

The installer seems to work fine, but the connection is rejected, apparently due to the client being unhappy about the server certificate. The same configuration works fine with wpa_supplicant in place of iwd. It could be that Iam doing something wrong, as I dod not play with iwd before.

That's a shame. Since I'm well into the 6.7 series kernels I haven't had a chance to test, but I'll grab an LTS kernel and see if I can get past the root cert SHA1 issue.

And one other thing, we really wanted to get rid of the python script and return to the bash script working with nmcli. Since the iwd approach seems to be just about creating the config file, this should probably be also doable in bash.

I'm sure it that porting the logic will be straightforward when the time comes; I'll be sure to write thorough documentation.

And one final remark. The geteduroam Linux client is being developed. There is a good chance that in time it will just replace the current installers - it works with CAT via its API.

Fantastic, the future will be even better.