802.1x: improve security against MitM and usability
Networks using 802.1x authentication (WPA/WPA2 Enterprise) such as eduroam or corporate networks typically authenticate against a TLS server (Protected EAP (PEAP), Tunneled TLS (TTLS), or TLS with mutual authentication (TLS)). These networks appear to use certificates that are signed by a CA that is already in the system trust store.
Example when using eduroam in Berkeley while using my TU/e credentials (domain tue.nl
):
CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA' hash=3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c
CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA' hash=3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c
CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3' hash=beb8efe9b1a73c841b375a90e5fff8048848e3a2af66f6c4dd7b938d6fe8c5d8
CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=NL/L=Eindhoven/O=Technische Universiteit Eindhoven/OU=ICT Services/CN=network.tue.nl' hash=489f27e92b805ecce4442fd5afcf25c79ea9becdbb433b1352b985bd8bed3e91
CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:network.tue.nl
Right now, the user interface in KDE Plasma (Arch Linux with plasma-nm 5.16.3-1, networkmanager 1.18.0-1) and system settings in GNOME (tested with Ubuntu 18.04) allows a custom CA to be selected. If not done, then no certificate validation is performed. Via nmcli or by editing the config directly, one can enable use of the system root CA store (configurable compile-time default: /etc/ssl/certs) using 802-1x.system-ca-certs=true
. This option is only safe if a domain is explicitly set.
How do other systems do it
On macOS, a user connecting to an untrusted network is prompted to accept the certificate chain when no profile is installed. Once done, the full chain and domain name is added.
One can also provision a profile with either the full chain, or just the domain name to avoid the certificate prompt. In the second case when no trusted CA chain is specified, it uses the system CA trust store.
I believe that Windows does something similar.
Proposal
- Change the current insecure default: require a domain name to be specified and enable
802-1x.system-ca-certs
by default when no custom CA certificate is supplied.- Current behavior: (1) if no CA cert is specified (default), certificate chain validation is disabled. (2) If no domain is provided (default), no domain name is validated. (3) The system CA store is not used unless manually configured outside the GUI.
- Warn users when a CA is already configured, but without an explicit domain name.
- If necessary, add a checkbox where a user can explicitly opt-out to such a check. Even better, just don't. Or make it a trust-on-first-time-use (TOFU) where the full chain is stored. Users that want to be insecure can use nmcli directly.
In theory this can be implemented without daemon changes, the GUI could tune the additional settings directly based on the user input.
However, to raise awareness, the daemon could also warn when such an insecure configuration with no proper validation is performed. A configuration where a public CA is selected, but no domain is provided is asking for trouble. There have been cases where organizations shipped private keys and certificates (cough Amazon Music cough) and obtaining certs from trusted CAs is actually cheap or free (Let's Encrypt).
Benefits
- Usability: NetworkManager works out-of-the-box with no need for additional CA configuration since it relies on the system CA store.
- Security: NetworkManager improves the default security settings, protecting better against man-in-the-middle (MitM) attacks.