> On Sept. 15, 2015, 11:34 a.m., Lamarque Souza wrote: > > Stefan Winter <stefan dot winter at restena dot lu> or <swinter at kde dot > > org>, who also helped in Eduroam specification, once said this about system > > ca certificates: "I meant the "Use System CA Certs". That option makes no > > sense in WiFi Enterprise auth; there's actually a reason why none of the > > big supplicants allows to set that (Windows by default *un-checks* all CAs > > in its system store, and you have to enable the one that matches your > > server cert; and Mac OS always warns you about a new certificate as it > > comes in *unless* you used the Profile installation tool and you have put > > exactly the CAs you trust into the profile." Please add him to this review > > request. > > Jan Grulich wrote: > It seems he doesn't have active developer account so I don't know how to > add him to this review, but I can forward the email with this review to him. > Regarding usage of that option, I implemented it because it's also present in > the latest nm-connection-editor so I suppose it's used by NetworkManager, > they just have it as "No CA certificate is required" so it has a different > meaning there, but I guess they set "system-ca-certs" property anyway. I'll > check that further while waiting for Stefan's response.
Jan, the security model for Enterprise Wi-Fi is the following: the user trusts exactly one server. That server identifies itself with a X.509 certificate. The configuration on the user-side end thus needs to pin one certificate from one CA. That information is provided to the user by the network admin; either via manual instructions or some config file that is consumed on the device (see e.g. https://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ). In that security model, there is *no* place for the system CA store. You can either turn off security altogether (which is probably the semantics of NetworkManager's "No CA certificate is required") - this is of course not recommended from a security perspective, but it is an option. Or you can turn on security and specify CA and server name exactly. The system CA store does neither of this correctly. The system CA store is designed for the web browser use case and it is a useful security model there: since you can visit any website you like, and the web server operator has chosen any CA he wanted to to get his web server certificate, the only trust model that works is that a pool of CAs is considered acceptable. Again, this is absolutely unrelated to the Enterprise Wi-Fi use case and there are good reasons for NOT providing the option. It's option bloat which weakens security. See also our extensive documentation of this subject at https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations Your "guessing" what other implementations mean is probably (hopefully) incorrect - their UI language suggests that they are doing the right thing by allowing to turn security on or off; and not providing a nonsensical option. My review of this patch is: burn and burry it. - Stefan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125233/#review85438 ----------------------------------------------------------- On Sept. 15, 2015, 6:23 a.m., Jan Grulich wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125233/ > ----------------------------------------------------------- > > (Updated Sept. 15, 2015, 6:23 a.m.) > > > Review request for Network Management, Lukáš Tinkl and Lamarque Souza. > > > Repository: plasma-nm > > > Description > ------- > > As summary says, this patch adds option to use system certificates for > WPA/WPA2 Enteprise setting, namely for PEAP, TLS and TTLS. > > > Diffs > ----- > > libs/editor/settings/security802-1x.cpp 0f8f71d > libs/editor/settings/ui/802-1x.ui ac5732a > > Diff: https://git.reviewboard.kde.org/r/125233/diff/ > > > Testing > ------- > > > Thanks, > > Jan Grulich > >
_______________________________________________ kde-networkmanager mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-networkmanager
