2

As I understand how most WiFi hotspots work, they require the user to authenticate on a Web page that is served by a proxy on the WiFi default gateway. After whatever authentication process (if any) the user went through on the Web page, he is then allowed to connect to the Internet through MAC address filtering. But the WiFi connection is still in the clear and subject to casual eavesdropping isn't it?

Or are there some WiFi protocols I am not aware of that would allow the user terminal to establish a new encrypted channel (à la WPA2) with the AP based on the interaction that the user had with the Web authentication process?

Edit: To clarify the reason for my inquiry is that I noticed that most WiFi clients nowadays notify the user joining such network that "An authentication is required". On a mobile phone by selecting this notification the browser will directly open the authentication Web page. So I am supposing that there's some WiFi protocol level exchange going on between the WiFi client and the AP related to this authentication step, so why not also getting a randomly generated PSK through a public key from the AP?

3

Security is worse and goes beyond a simple confidentiality issue.

As you stated it is indeed "subject to casual eavesdropping", but as you also noticed the legitimate user is "allowed to connect to the Internet through MAC address filtering".

An attacker can change his own MAC address to share the same one as the legitimate user. This creates a MAC address conflict, but in practice this just results in some warning messages appended to some system log file that end-users never check anyway. Connection is maintained and works for both parties simultaneously (as they share the same collision domain).

From now on, not only the attacker can eavesdrop legitimate user's data but the attacker can now impersonate him in the eyes of the hotspot (and the infrastructure and provider behind it). The attacker is usually also able to keep the access open any arbitrary time after that the legitimate user went away (this requires the attacker to simulate regular activity all along, either any random activity or simulate a certain "authentication" web page refresh, but this is easily automatable).

Most, if not all unencrypted open WiFi accesses relying on a portal suffer from such issues: hostel, paid WiFi access, public hotspot services that some ISPs push to their end-user to share their WiFi with other subscribers, etc.

From there, you have two main ways to secure this:

  • Either stay in the upper network layers: provide a VPN client application to the user (don't necessarily call this a VPN, from a commercial point-of-view anything will do: "WiFi-Access", etc.). Instead of using a web page the user will use its client software to authenticate itself and "open" the WiFi access (in practice the unencrypted WiFi provides access to a VPN server, itself providing access to the Internet to authenticated clients).

  • Or you fix the problem in the lower layers: provide end-user either a PSK "WiFi password" (hostels case for instance), or instead of providing them an VPN client application provide them certificates that will be used to connect to your hotspots (ISPs case for instance). From there a more secure channel will be established between the end-user and the acces-point, allowing the user to securely authenticate to the hotspot's captive page.

There is no way here to, as you suggested, create a security token at an higher layer (the application layer, here the browser) to use it to secure a lower layer (the data link layer, here the WiFi connection). You implement security either at one or the other layer.

0

For my description I will assume this is a captive portal implementation that you are likely to see in a hotel for example.

The Wifi is still in the clear if there is no authentication (such as WPA2) done prior to the connection. It appears most implementations go for the unsecure option allowing easier access to guests. I have seen some hotels require a PSK to access the Wifi and then a forced captive portal. (This would provide the encrypted and authenticated traffic as expected).

  • Yes your assumption is correct in the case I want to describe: No PSK, just the plain "authentication" portal/gateway. – Samuel Oct 27 '17 at 15:50
  • In that case the wifi traffic would not be encrypted or authenticated. Obviously any traffic which has encryption/authentication provided at a higher level (such as TLS) would still remain encrypted using that (not related to the wifi encryption at all) – ISMSDEV Oct 27 '17 at 15:52
  • That is also my understanding but if the WiFi client is negotiating something with the AP, it could also retrieve a PSK silently without the user having to know it or set it up. I updated my original question above to reflect this. – Samuel Oct 27 '17 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.