Version: 0.9 (using KDE 4.6.0) OS: Linux The KNetworkManager GUI allows to specify many parameters to IEEE 802.1X security, but not the server name validation (CN). This is almost trivial to add, as it is perfectly possible to specify this parameter in wpa_supplicant.conf. It is network={ ... subject_match=thename } Being able to specify the exact expected server name is an important security property if *not* using self-signed certificates or private CAs. I'm an R&D engineer in a major 802.1X-based roaming consortium (www.eduroam.org) and a fan/former developer of KDE; and the lack of this feature has always been a bit of a grief for me. Would be nice if this could be changed in the future. (Somewhat unrelated to this bug: we are working on scripted installers for eduroam on many platforms - is there a command-line API to inject new configs into KNetworkManager? Or would I have to try and play directly with $KDEHOME/share/config/knetworkmanagerrc ? ) Reproducible: Always
(In reply to comment #0) > Version: 0.9 (using KDE 4.6.0) > OS: Linux > > The KNetworkManager GUI allows to specify many parameters to IEEE 802.1X > security, but not the server name validation (CN). > This is almost trivial to add, as it is perfectly possible to specify this > parameter in wpa_supplicant.conf. It is > network={ > ... > subject_match=thename > } I have executed 'grep -r subject_match *' in both NetworkManager 0.8.2 and 0.8.9997 source codes and it returned nothing, so it almost certain NM does not support this configuration. If NM does not support it there is nothing we can do. You should contact NM developers about this subject. Plasma NM does not edit system configuration files, it is NM that does that for us. > Being able to specify the exact expected server name is an important security > property if *not* using self-signed certificates or private CAs. > > I'm an R&D engineer in a major 802.1X-based roaming consortium > (www.eduroam.org) and a fan/former developer of KDE; and the lack of this > feature has always been a bit of a grief for me. Would be nice if this could be > changed in the future. > > (Somewhat unrelated to this bug: we are working on scripted installers for > eduroam on many platforms - is there a command-line API to inject new configs > into KNetworkManager? Or would I have to try and play directly with > $KDEHOME/share/config/knetworkmanagerrc ? ) Branch nm09 of Plasma NM does not use knetworkmanagerrc to configure connections. All connection's settings are stored by NM, only secrets have the option the be stored by NM or in Plasmas NM (this is the default). You will have to use the NM's DBus interface to add/delete/update connection settings. As as start you can take a look at git://anongit.kde.org/networkmanagement/backends/NetworkManager/nmdbussettingsconnectionprovider.cpp to see how we do it for NM-0.8.x. You can checkout the nm09 branch to see how we do it for NM-0.9.
I've chimed in on the feature request that's pending since 2006(!) in NetworkManager: https://bugzilla.gnome.org/show_bug.cgi?id=341323 I'll sure update the bug when downstream has implemented this.
Hi, after talking to the NetworkManager people, the corresponding functionality is now in NM. In fact, it was considered a security loophole and had a CVE number since 2006! On my openSUSE 12.1, the new NM and corresponding NM-gnome programs were updated today, so the code is actually hitting the streets. I'm reopening this bug to get the new functionality also into the KNM GUI. From today's openSUSE 12.1 patch notification: "NetworkManager did not pin a certificate's subject to an ESSID. A rogue access point could therefore be used to conduct MITM attacks by using any other valid certificate issued by same CA as used in the original network (CVE-2006-7246). Please note that existing WPA2 Enterprise connections need to be deleted and re-created to take advantage of the new security checks."
This was already implemented in Plasma NM three months ago: https://projects.kde.org/projects/extragear/base/networkmanagement/repository/revisions/5f383f9c91e3c9b69f80a2fb2832e97f0540ff5e