5

I have configured a Cisco WLC to authenticate users using External Web Authentication at Layer 3. Are client wifi connections more resilient against eavesdroppers with a pre-shared key at Layer 2 versus simply having an open network and just using Layer 3 web auth?

For example, say there is a client that connects to wifi, but does not have a username/password for Layer 3 web auth. If the wifi was open access would the client be able to sniff the airwaves and read unencrypted data (for example HTTP connections, or maybe that PDF being printed to the networked printer). What if the wifi has a PSK? Does the non-layer-3-authenticated client have less or the same amount of visibility to unencrypted traffic?

Based on @BatchyX's comment, how difficult is it to intercept a WPA2 handshake and get the PSK without knowing it? This network is in a coffee shop scenario where there are many clients and constant traffic.

Is there a better way to secure the network? Is there a 802.1X variant that would allow per-user keys without the per-user certificate requirement?

Thanks!

  • Could you elaborate more about the eavesdropping that you're concerned about? Is it merely the web authentication exchange? – Mike Pennington Nov 4 '13 at 19:42
  • 1
    RSN-PSK does not do anything to counter attacks from those who knows the PSK: they can eavedrop everything if they get the 4 way handshake. – BatchyX Nov 4 '13 at 20:00
  • Thanks for the comments thus far; the post has been updated per the feedback here. – berto Nov 5 '13 at 21:05
6

Web authentication is really more of a means to limit/allow guest access on a clear network that requires no additional client configuration to connect. It is not meant as a way of providing secure access.

So, unless the client only uses encrypted sessions (HTTPS, SSH, SFTP, VPN, etc.), then they are far more secure using a PSK than web authentication.

Edit for the expanded question: Generally speaking a client connecting to the network in any means is not "capturing" any traffic in the air. Attackers capturing traffic will not be connected to the network.

If a client device is connected to a SSID that has no encryption, anyone in the area could "listen in" while there is data going to/from the client. Any of that data that is not encrypted by other means would be easily decoded by someone who wanted to do so. To be entirely clear, "L3 web authentication" provides no encryption. Specifically to answer your question, yes, anyone can capture traffic on an open/clear SSID using web authentication, whether they have a username/password or not making traffic like your example HTTP or print traffic vulnerable.

A PSK is not actually used to encrypt the data, rather it is used as a common frame of reference (or starting point) to allow to devices to negotiate the keying material used for encryption. Having the PSK will not allow you to decrypt the data. However, as BatchyX pointed out, if you have the PSK and capture the handshake, since you have the same "starting point" as the other device (i.e. the PSK), you will be able to get the keying material and decrypt any data using that keying material. This provides much less visibility for an outsider to capture data, as they would need both the PSK and the handshake to do so. One without the other will not suffice.

As for getting the PSK by capturing the handshake, this is a bit more involved, but can be done. Basically, this is a "brute force" type of attack where the attacker uses different PSK values against the handshake until they find one that allows them to understand the full handshake. Once they have this value, then they will be able to easily decrypt any other connection that they capture the handshake for as well. While this is a simplistic description, if you are using WPA2/AES without a "common", short, or dictionary PSK, know that this is very unlikely to occur.

If you wanted a better way of doing this without client certificates, then the most common one is 802.1X based WPA2-Enterprise using EAP-PEAP-MSCHAPv2. This only requires the server side certificate, but is a more involved process to configure the client (although this has gotten much better for many devices in the past couple of years) to authenticate against a RADIUS server. Not only does this make the keying material different for each user, but different for each session as well.

In your coffee shop scenario, I would recommend using WPA2-Enterprise SSID for "company" devices. As for customer access, a second SSID with either web authentication or PSK provides a mechanism for limiting access. Normally most public places go with the web authentication because they can have a mechanism for providing a "Terms of Use" agreement to cover themselves in a legal sense. They leave it to the customer to provide for their own protection of data.

  • YLearn, you're mentioning PEAP; however, PEAP is vulnerable to many problems itself. I think EAP-TLS is the best option if you have control of the laptop and the wifi infrastructure. – Mike Pennington Nov 5 '13 at 23:19
  • @MikePennington, that isn't really about vulnerabilities in PEAP itself, rather in the ability to misconfigure clients and not educate users properly. Those are common issues when it comes to the issue of if something is secure or not. EAP-TLS can be problematic if you don't manage your client certificates properly. I threw EAP-PEAP-MSCHAPv2 out since the OP asked about a non-client certificate form of 802.1X. – YLearn Nov 5 '13 at 23:56
  • You are correct, in the ideal world you can ignore problems with client implementations. We live in the real world. EAP-TLS takes user mistakes out of the equation. – Mike Pennington Nov 6 '13 at 0:10
  • @MikePennington, again I threw that out there as an option since the OP asked for a non-client certificate form of 802.1X. EAP-PEAP is still better than PSK, even with it's potential problems and enterprise Windows deployments (i.e. AD) can mitigate most of those problems with group policies. The details of proper implementation seem to be a bit out of scope of this question. Sometimes in the real world, things just aren't as secure as we would like all the time. How many times have you gotten to implement the minimum 12 character, four class, non-dictionary passwords across the enterprise? – YLearn Nov 6 '13 at 6:49
  • Again, I threw that out to highlight the non trivial risks associated with deploying PEAP. PEAP client misconfigurations are common, and misconfigured PEAP + the easily cracked AD credentials you mentioned means the attacker gets both wifi access and an AD login. Keep using whatever you want, but we should explain risks of this magnitude to visitors. – Mike Pennington Nov 6 '13 at 7:09

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.