Today, most Wi-Fi hotspots at home use the standard WPA/WPA2 authentication and encryption mechanism that uses a shared password between the Wi-Fi hotspot and clients. The downside of this approach is that all users have to share the same password which enables an attacker who is in range of the network and in possession of the password to decode encrypted packets if he has observed the initial EAPOL authentication and ciphering dialog of another client. Another downside is that the password needs to be stored in all access points of a Wi-Fi network. All these things are clearly not acceptable in company environments or during public events that want to offer air interface security. For such environments, the Wi-Fi alliance has specified the WPA-Professional authentication approach that can use various authentication methods with certificates and individual passwords for each user. Let's have a closer look at one option of which I was recently able to take a Wireshark trace:
To address the need of companies for a centralized user management, WPA/WPA2-Professional manages certificates and passwords from a central authentication server, often referred to as a RADIUS server. In practice it's not straight forward to discuss such setups because they are mostly used by companies and hence can't be discussed in public. Fortunately I've now found one network that uses WPA2-Professional with a certificate and passwords that can be discussed in public: The Wi-Fi network that was used during 32C3.
As they've described on their Wiki, a server side certificate was used to authenticate the network towards the user via TTLS. To authenticate clients, a username/password of choice could be used in the network. As the conference network administrators were not interested to authenticate users, any username and password combination was accepted. In practice users could remain anonymous this way while at the same time an individual secret was used to generate cipher keys, i.e. packets can't be deciphered by an attacker even if the authentication packets were captured.
The screenshot of the Wireshark trace on the left (here's the pcap in case you want to have a more detailed look) shows how the TTLS/Certificate authentication works in practice. After associating with the network, the Wi-Fi access point asks for a username, which can be anonymous and then tells the user that it wants to proceed with a TTLS-EAP authentication procedure. The client device then answers with a 'Client Hello' packet that contains all cipher suites it supports. The network then selects a cipher suite and sends it's signed certificate to authenticate itself which contains it's public key.
In company environments, the certificate used in Wi-Fi networks is usually signed by a private certificate authority. To enable the device to validate the signed certificate that was sent, the public key of the certificate authority that has signed the delivered certificate has to be stored in the device before it connects to the network for the first time.
In case of the 32C3 network a public certification authority was used to sign the certificate delivered to the device. As anyone can get a signature for a certificate from a public certification authority if he is the owner of the domain specified in the certificate an additional client side configuration is required to ensure that only signed certificates with the correct domain name of the Wi-Fi network are accepted. Unfortunately, Ubuntu's graphical network configuration tool doesn't have a field to configure this extra information as shown in the second screenshot.
Fortunately it's possible to modify Ubuntu's configuration file for the network after it has been created in '/etc/NetworkManager/system-connections' by adding the 'altsubject' line in the 802.1x section with the domain name used by the Wi-Fi network's certificate.
[802-1x]
eap=ttls;
identity=x
ca-cert=/etc/ssl/certs/StartCom_Certification_Authority.pem
altsubject-matches=DNS:radius.c3noc.net;
phase2-auth=pap
password-flags=1
Putting in a wrong value in this line makes the connection establishment fail so I could verify that the overall authentication process is secure.
Once the client device has accepted the server certificate (packet 14 in the trace) an encrypted handshake message is exchanged that is client specific. For this dialog, the client uses the public key that was part of the certificate to encrypt the message. Decoding the packets on the network side is only possible with the private key. As the private key is never sent over the air an attacker can't use a copy of the certificate for a rogue access point.
Afterward the standard 4 step EAPOL Wi-Fi messaging is used to activate link level wireless encryption, based on an individual secret exchanged during the TTLS process. Packet 22 shows the first encrypted packet exchanged between the access point and the client device, a DHCP message to get an IP address. As the trace was done on the client device the decoded version of the packet is shown. Once the IP address has been received the connection is fully established and user data packets can be exchanged.