Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

As far as I understand, WiFi networks that require no password send traffic through the air unencrypted. Those that require a password encrypt each connection uniquely, even if they're all using the same password.

If this is true, I don't understand why. Requiring a password for access and encrypting connections seem like totally separate issues.

Are they really linked this way? If so, is there some reason I'm not seeing? Can some routers be configured to allow public access with no password, yet encrypt the users connections to prevent Firesheep-style attacks?

Update

Some answers have said or implied that the password is a necessary "shared secret" that enables encryption. But it's not necessary. This problem was publicly solved in 1976.

The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

share|improve this question
    
Its a standing issue, and as far as i know, there's no remedy. It could be worth investigating if WPA-Enterprise (which doesn't need a PSK) can be 'tricked' into not needing Authentication while still providing encryption –  NULLZ May 14 '13 at 2:08
5  
Bear in mind that Wifi is a layer 1 protocol. This means it is transparent to layer 2 (Ethernet). So 'having the wifi password' is equivalent to 'plugged into the switch'. –  lynks May 14 '13 at 11:01
4  
Since mine is one of the answers that the OP's updated refers to, I would like to point out that Diffie–Hellman key exchanges are vulnerable to man in the middle attacks (feel free to check the Wikipedia entry provided by OP). This would not be at all suitable in a wireless environment where it could be almost trivial to set this up (all you would need to do is get into the "middle" and create enough noise to prevent reliable communication between target station and AP). –  YLearn Jun 14 '13 at 1:59
    
@YLearn - good to know. Has no safer equivalent been created in the37 years since? –  Nathan Long Jun 14 '13 at 18:57
1  
@NathanLong, I am no expert, but as far as I know, three isn't a way to both encrypt a connection and prevent man in the middle without having some "common starting point" between sender and receiver. My understanding is if the encryption keying material is negotiated with no starting point, then anyone can jump into the middle and negotiate the exchange both ways. –  YLearn Jun 14 '13 at 19:42

7 Answers 7

Why isn't open WiFi encrypted?

It's the same reason why WPA-PSK does not use Diffie-Hellman/RSA key exchange.

Adnan's first point is the most accurate answer.

As for why open WiFi networks don't have encryption. Well, they just don't.

There is no technical reason. it's probably a financial and/or bureaucratic reason. And changing existing infrastructure isn't easy.

How do we know that "JFK Airport AP" is really the access point of JFK airport?

Note that there is a difference between authentication and encryption. The problem described is an authentication problem which exists regardless of whether or not we are encrypting a Wi-Fi connection. In other words: The fact that RSA does not provide authentication is in no way related to the question of why RSA isn't being implemented on open Wi-Fi networks. Also, the authentication problem can be solved using an extremely simple method described in the following example:

Our future, encryption-enabled Wi-Fi router uses Diffie-Hellman / RSA. The router has a small LED display which displays its public key, or perhaps a simple hash of the public key. The access point is called "MyHouse".

I would like to connect my phone to "MyHouse", but there is another AP with the exact same name, all I have to do is look at my router's monitor and compare the string to the string displayed on my phone, that way, easy authentication is achieved. Airports and public places can employ similar techniques by displaying the public key / hash on large screens or on some low cost stickers.

Side note: The LED is just an example, many other methods are available.

Can some routers be configured to allow public access with no password, yet >encrypt the users connections to prevent Firesheep-style attacks?

Yes, that can be configured, but it wouldn't be on the router level. And the one connecting would need to take some extra steps.

Solution 1. HTTPS Web proxy

An extremely simple technique one could use immediately is browsing the web using an HTTPS encrypted web proxy, such as HideMyAss. That way one is using public key cryptography, but it's being done on top of the TCP layer.

Solution 2. a LAN VPN server or SSH tunnel server

A similar approach can be used on the local network without depending on external sites: Use a local VPN server / SSH Tunnel server. The data would flow this way:

Network device(Say, my phone) > AP > Network device (VPN/SSH Tunnel server) > AP > Internet.(# flow1)

The VPN/SSH Tunnel acts as an extension to the AP, if we mentally encapsulate those, we would get:

Network device (My phone) > Encrypted AP > Destination. (# flow2)

Solution 2. Important notes!

  • You MUST use a wired connection between the VPN/SSH tunnel and the AP if using the LAN solution, see the end of my answer.

  • If you would like to practically implement this, you may use a low power tiny always on computer such as a RaspberryPi as an SSH Tunnel server, I tried it and I see no noticeable latency.

Solution 3. Regular VPN/SSH tunnel server

One could use a VPN which isn't on the LAN, then we would get:

Network device (My Phone) > AP > VPN > Destination. (# flow3)

In all 3 cases, the data is fully encrypted using TLS/SSL/Whatever your VPN/SSH is encrypted with.

If using the LAN VPN/SSH solution, the server must be wired, otherwise the traffic which is being forwarded by the VPN/SSH server from the client to the destination will be sent un-encrypted to the AP.

More regarding the LAN solution

If using a wireless connection on an open WiFi with a LAN VPN/SSH tunnel server solution, this is how traffic flows. This is an expansion of "flow1", in which whether the data is encrypted or not is added to the flow:

Network Device > encrypted data > AP > encrypted data > VPN/SSH server > un-encrypted data > AP > Internet

For this reason, we must use a wired cable between the VPN/SSH server and AP, that way, the un-encrypted data is never sent through air.

share|improve this answer

I suspect the answer has to do with the "statelessness" of the WIFI router. Incoming and outgoing packets are treated uniformly. If some sort of encryption were negotiated on a per-connection basis, the router would have to maintain state for each communicating partner. This would break the "layer" model; that packets are treated uniformly and higher layers deal with things like encryption and continuity.

share|improve this answer
    
There must be some state maintained per connection already; otherwise how does it know where to send responses for user requests? –  Nathan Long May 16 '13 at 19:07
    
it sends them to the air - it's called broadcast. Ethernet works that way too; a transmitter just modulates a packet onto the wire. All reveivers receive it, and the one who cares picks it up and does something with it. –  ddyer May 16 '13 at 19:26
    
Ah, right! I forgot that. –  Nathan Long May 16 '13 at 20:33

You're correct that they are not the same problem: Password authentication and symmetric encryption are fully independent concepts that can each be implemented without the other. However, a password is one of several ways to produce the key necessary to operate the encryption.

An encrypted connection such as that between your computer and your AP is implemented using symmetric encryption. For symmetric encryption to work, both parties (the computer and the AP) must both share a key (a small amount of confidential data) for encrypting a stream and decrypting it afterward.

One common way of doing this is using a pre-shared key (PSK), where both parties are made aware of the key previous to attempting to make the connection. This is what you're doing when you set up a Wi-Fi passphrase: When you enter the passphrase on the router, then again on the computer, they now both have this information. The sharing of the key takes place not over the network, where it could be eavesdropped, but manually by keyboard, which is typically a great deal more secure.

(The key is technically not the passphrase itself but some data that is derived from it.)

Encryption requires a key. This is why you're asked for a passphrase, and why without one you don't get encryption. There are other ways than a passphrase to produce keys, but you won't find them on your AP.

Consider this situation: Without a passphrase, the key might be generated (such as with a strong PRNG) by the AP. The key would somehow need to be communicated to the computer. The straightforward way would be over the wireless connection itself (presuming that the AP has no other means of sending data to the computer). Once this is received, the remaining traffic on the connection can be encrypted.

The trouble is that the connection isn't encrypted while the key is sent (if it were, the receiving party wouldn't be able to read the key). An eavesdropper can easily retrieve the unencrypted key and monitor the remainder of the session as if it weren't encrypted.

The theoreticians would say that since this is possible, your connection is already as good as unencrypted and you might as well not waste the CPU cycles scrambling it. I say that while that attack wouldn't be effective unless the attacker is around for the beginning of the connection, you can't safely assume this isn't the case (all of the time).

There are ways around this particular problem using asymmetric (public-key-based) encryption and authentication, wherein via some mathematical magic you're able to encrypt data that nobody except the recipient (not even you!) can decrypt, but it can be complicated to set up, and, as of last time I bought one, isn't likely to be a built-in feature of your AP.

share|improve this answer

The other answers have already explained that Firesheep-style attacks (basically MitM trhough ARP spoofing) have nothing to do with WiFi itself. This is a link-layer issue.

As for why open WiFi networks don't have encryption. Well, they just don't. I don't really know why they decided not to, I can only speculate. One very obvious reason is MitM attacks, as anybody could impersonate the access point (AP) and negotiate the encrypted connection with the victims. Which leads us to a PKI problem, should AP owners acquire trusted certificates for their access points. But that defeats the whole purpose of an Open Wifi Network, because then you'd have to verify the identity of the AP.

How do we know that "JFK Airport AP" is really the access point of JFK airport? Should we issue certificates for access points called "JFK AP"? Would that lead to social engineering attacks? Do I have to create my own certificates then ask my friends to trust them when they connect to my network? Now, of course, one could argue that we can use trust-on-first-use model, but that doesn't work for WiFi networks in parks, airports, or in the street.

There are some proposals to solve the issue, like a proposal by students at The Ohio State University, they call it Dummy Authentication

Our solution utilizes the existing symmetric key encryption algorithms, e.g., TKIP and AES, that are already used in the WPA and 802.11i products to protect wireless frames from spoofing and eavesdropping. In order to use the existing encryption algorithms, encryption keys are obviously needed. In this section, we first propose a new dummy authentication key-establishment algorithm. Then we use the established session key to protect wireless frames.

Which I really like. If you think about it a bit, you'd see that it'd solve the sniffing problem and AP impersonation issues (like with ARP spoofing) with the usage of CA-issued certificates.

We assume that each AP has a public-private key pair, denoted as pk and sk ,e.g.,RSA keys. The public key is contained in a CA-signed certificate or a self-signed certificate.

Of course that would require upgrading all existing WiFi access points and patching operating systems. Not an easy thing to do.

share|improve this answer

When you are talking about "no password" and "same password," I imagine you are referring to the pre-shared key. This is not actually a password, but used as a known value by the station and AP to generate and securely (at least from outside sources without the known value) exchange keying material for the encrypted traffic. WPA/WPA2-Personal do not actually authenticate, only encrypt.

WPA/WPA2-Enterprise uses 802.1X to authenticate and if the authentication is successful, to generate and exchange keying material.

Very basically, to set up any encrypted communication, both sides need some common point on which to build the encryption. On the web (SSL/TLS), this is often done through the use of certificates, but an 802.11 device works at layer 2, which precludes many of these methods.

802.11 uses the two options to provide this common point, either the PSK or information from the 802.1X authentication.

share|improve this answer

Firesheep has nothing to do with the WiFi encryption. If you and I were both on an encrypted WiFi connection, I would still be able to Firesheep your data.

What Firesheep does happens at the router level. It does not intercept the waves on air (well, not exactly)

Basically, it runs an ARP spoofing attack. This sort of attack can be run on a LAN network as well; it involves feeding the router lies about the MAC address corresponding to a given IP. When a router wishes to distribute a packet to a given IP, it needs to find out who owns that IP. If it doesn't have this data in its cache, it broadcasts a message asking for these details. Anyone on the subnetwork can reply to the broadcast and say that the IP is theirs, even if it isn't. Using this, an attacker can seat himself squarely between the router and the victim in the communication channel.

To be clear: This is a problem with TCP/IP (the protocol that drives networking). Not with WiFi.

share|improve this answer
    
So if two computers are connected to the same password-protected WiFi, this is equivalent to them both being on the same open WiFi or them both being plugged into the same LAN: they usually choose to ignore each other's packets, but don't have to. Am I understanding correctly? –  Nathan Long May 24 '13 at 14:16
    
@NathanLong: not exactly, it's more like the router will send packets depending on its ARP table, and I can set up my computer to pretend to be everyone. –  Manishearth May 24 '13 at 14:20
    
Right, but my understanding is that on Ethernet, even if the router knows the MAC address for a given IP and labels the packet accordingly, all other machines on the network still see the packet. Do you know if that's also true for WiFi? At a radio-wave level they certainly must receive the signal, but it could theoretically be encrypted such that only the intended receiver could understand it. –  Nathan Long May 24 '13 at 14:24
    
@NathanLong: I'm not too sure, AFAICT if it knows the MAC address there is no broadcast on ethernet since it doesn't need to ARP. –  Manishearth May 24 '13 at 14:28
    
computer.howstuffworks.com/ethernet6.htm says "a signal on Ethernet reaches every attached node... when a station first receives a frame, it checks the destination address to see if the frame is intended for itself. If it is not, the station discards the frame without even examining its contents." This is why collision detection is needed and why Wireshark can be used (it does not discard others' frames). Switches can filter the packets going down a given cable to only those intended for a host on that cable. But I'm not sure how WiFi behaves. –  Nathan Long May 24 '13 at 15:22

The question (to most people) is an oxymoron. By definition, people will think that "open WiFi" means "un-encrypted WiFi. To me you seem to be asking "Why did the people that wrote the 802.11 standard way back in 1997 make the decisions that they did?"

The short answer - we can only find out by asking them (or seeing if there are any discussion documents floating around on the internet).

However, we can discuss the Firesheep portion of the question. A "Firesheep" attack is a specific type of attack where cookies that authenticate a user to a site are copied by an attacker.

The only requirement is that the cookies can be obtained by the attacker - and therefore WiFi networks using WEP, WPA, or WPA2 with a single pre-shared key are vulnerable, if the attacker has the key. And of course, many small businesses provide WiFi access using a single key.

Having "better" Access Points is an expensive way of fixing this problem, and will still leave users vulnerable to the above attack scenario (where the attacker can use ARP poisoning plus a man-in-the-middle attack against HTTP-only sites).

Therefore as far as solutions go, the best and most useful would be widespread implementation of HTTPS (as recommended by the creator of Firesheep, Eric Butler)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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