Created attachment 1283928 [details] Fedora 25 WPA Enterprise configuration screen Description of problem: When setting up a wireless network for WPA or WPA2 Enterprise, the only verification that is exposed for the authentication server is via the CA Server, as opposed to any sort of verification of the authentication server itself. The impact here is that an attacker with an "evil twin" access point can capture authentication attempts, which can be cracked offline. Version-Release number of selected component (if applicable): 1:1.4.4-5.fc25 How reproducible: Always Steps to Reproduce: 1. Run nm-connection-editor 2. Add or Edit WiFi connection 3. Click Wi-Fi Security tab 4. Select "WPA & WPA2 Enterprise" 5. Select "PEAP" for Authentication 6. Try to ensure that you'll not connect to an attacker's access point. Actual results: When configured via the GUI, there is no way to ensure that your WiFi connection will not attempt to authenticate with an attacker's RADIUS server. The best that can be done is to verify the *CA* that issued the certificate, rather than verifying the certificate itself. An attacker could just purchase a certificate from the same CA as is used by the network being impersonated. Expected results: The authentication settings in the NetworkManager GUI should expose some way to prevent authentication attempts with an attacker. Possible techniques include: 1. Expose in the GUI a field for the domain name associated with the WiFi connection. This puts WiFi authentication on the same level as non-pinned HTTPS web communication. That is, you are trusting that the CA has done its due diligence to ensure that the provided certificate is indeed for the domain name listed. Android 7.0 does this. 2. Even if the network's authentication server certificate is issued by an OS-trusted CA, require certificate validation on the first attempt to connect to the WiFi network. After that, only attempt to authenticate with the network if the certificate matches. MacOS and iOS do this. Additional info: It's not clear at this point what Windows does to connect/remember 802.1x-authenticated networks, but in my brief testing Windows does not attempt to authenticate to an attacker's network. Out of popular modern operating systems, I've only seen Linux/NetworkManager do this. I've only been testing PEAP. But it's possible that other Enterprise authentication schemes like TLS and TTLS could also benefit from the improvements described above. hostapd-wpe <https://github.com/OpenSecurityResearch/hostapd-wpe> was used for simulating an attacker's access point.
Created attachment 1283929 [details] Android 7.0 WPA Enterprise configuration screen
Here's a page that describes the current limitation, as well as provides a workaround possible with manual editing of the configuration: https://sebastian.marsching.com/wiki/Linux/NetworkManager
Will: thank you for a superb bug report, the screenshot was really helpful. Decided to do roughly the same thing as Android does and exposed the domain-suffix-match via the "Domain:" field in the editor. The branch is now in review upstream: https://git.gnome.org/browse/network-manager-applet/log/?h=lr/tls-domain-suffix-match-rh1457542
(In reply to Lubomir Rintel from comment #3) > The branch is now in review upstream: > > https://git.gnome.org/browse/network-manager-applet/log/?h=lr/tls-domain- > suffix-match-rh1457542 I know that none of the existing fields has it, but can you add a tooltip to the new text entry explaining what the user is supposed to put there? Do you know if Android uses the value from the Domain field to do a suffix match or a full-domain match? I suspect a suffix match can be bypassed in case the CA is not careful when granting certificates (for example, a domain_suffix_match="serv.company.com" would also match "evil.serv.company.com"). But probably this is not a likely scenario. The rest LGTM.
+ widget = GTK_WIDGET (gtk_builder_get_object (parent->builder, "eap_ttls_grid")); + g_assert (widget); indentation I agree with the tooltip comment. I wouldn't know what "Domain" means in the GUI (if I wasn't aware of what this branch does). Rest lgtm
(In reply to Beniamino Galvani from comment #5) > (In reply to Lubomir Rintel from comment #3) > > > The branch is now in review upstream: > > > > https://git.gnome.org/browse/network-manager-applet/log/?h=lr/tls-domain- > > suffix-match-rh1457542 > > I know that none of the existing fields has it, but can you add a > tooltip to the new text entry explaining what the user is supposed to > put there? Good idea, added the tooltip. It would be nice if other options had tooltips too. Not adding them now though. > Do you know if Android uses the value from the Domain field to do a > suffix match or a full-domain match? I suspect a suffix match can be > bypassed in case the CA is not careful when granting certificates (for > example, a domain_suffix_match="serv.company.com" would also match > "evil.serv.company.com"). But probably this is not a likely scenario. I don't have an Android device to check, but I would be very surprised if this was an exact match. Also, technically "evil.serv.company.com" indeed belongs to the "serv.company.com" domain.
network-manager-applet-1.8.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-2bd2bb14ff
merged upstream as https://git.gnome.org/browse/network-manager-applet/commit/?id=73e296939dc14903120f90f019b674f1c800bc4f
(In reply to Lubomir Rintel from comment #7) > I don't have an Android device to check, but I would be very surprised if > this was an exact match. Conversely, I can't imagine a scenario where it makes sense to do only a suffix match. Just like there should be a single full domain name to identify a website or email server, I think the same applies to an authentication server.
network-manager-applet-1.8.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-2bd2bb14ff
network-manager-applet-1.8.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 1289275 [details] Fedora 26 dialog still missing domain name field Looks good in that a properly-configured network does not seem to attempt to authenticate with an attacker's network. However, there still appears to be another dialog that is missing the newly-added domain name field. Steps to get to such dialog: 1. Click network icon near top right corner of desktop 2. Select Wireless network 3. Click "Wi-Fi Settings" 4. Click the gear for your enterprise network 5. Select the Security tab This dialog appears to need to be updated as well. This will allow people who have configured WiFi before this bug was closed to now associate a domain with the network settings. It will also allow somebody to correct a mis-typed domain name when first setting up the network.
Tested under Fedora 27. To complete what Will explained, a very common modification case happen when a user need to change his password for example. I do confirm that when editing an existing wireless connection, the applet does not print the domain name field. So, if this connection is changed and saved again, the domain name value is suppressed from the interface configuration under /etc/sysconfig/network-scripts/ifcfg-<SSID> (option IEEE_8021X_DOMAIN_SUFFIX_MATCH). This behavior expose again the user to the initial risk that you try to fix (thanks you very much for this).
(In reply to Will Dormann from comment #13) > Created attachment 1289275 [details] > Fedora 26 dialog still missing domain name field I am am not mistaken, this screenshot is from gnome-control-center. That is a different component than nm-connection-editor and AFAIS, is this bug fixed for nm-connection-editor.