Why isn't open WiFi encrypted?

Question

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)

Answer 1

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)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Update: Diffie-Hellman

Even if Diffie-Hellman key exchange is used, there's still an issue of trust.

Here's a brief run-down of why:

• Without prior establishment of trust between the parties, authentication is not meaningful.
• Without meaningful authentication, DH is not meaningful. (It is vulnerable to a man-in-the-middle attack.)
• Without meaningful DH, encryption based on a DH exchange is not meaningful.
• Communication without meaningful encryption is (roughly) equivalent to communication without any encryption.
• Thus, a DH-based default encryption scheme is not substantially more secure than no encryption unless trust has been established first.
• Without a mechanism of trust by third parties (such as PKI or web of trust), the establishment of trust requires a direct exchange (in person, by phone, etc. depending on paranoia level) of information.
• Any useful mechanism for direct exchange could, at least as easily, be used to share a PSK.

Establishing trust is a problem that is difficult to solve between strangers without a direct exchange, and such a direct exchange is already sufficient to share a PSK.

One way to avoid the direct exchange, theoretically, would be to buy an SSL cert for your AP from a public CA. This could get a little pricey, and I think AP owners are not that likely to pay extra to provide secure Wi-Fi to strangers. A self-signed cert could be used instead, but this would require the guest to either blindly trust a self-signature, which leaves it open to MITM, or get and install the cert after checking its signature against the original—and this would once again require a direct exchange.

Answer 5

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.

Answer 6

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.

Answer 7

Nowadays there is actually an approach to encrypt connections to open wifi hotspots, using "Opportunistic Wireless Encryption". OWE is specified in RFC 8110.

I don't know which clients or hotspots actually support this standard, though.

Answer 8

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.

Answer 9

I'm not a security expert and have only basic understanding of cryptography but I think that you are absolutely right and the connection to wifi should be encrypted with DH to protect at least from eavesdropping. This can't protect from MitM but that attack is harder to do. Especially this can be significantly prevented by trust of first usage.

And actually we can go further and implement PKI as for HTTPS. For example my router also serves my homepage and it has it's own domain and HTTPS certificate signed by CA. So it would be great if in list of wireless networks it will be shown a green padlock the same as in browser. For the big public access points like in airports this also could be an affordable solution.

Also I have no idea why not to use an usual TLS/SSH instead of using some CRACKed algorithms.

That's a big irresponsibility that this wasn't implemented for so long and billions of users are now vulnerable even without knowing this.

But recently was released a WPA3 and it has Perfect Forward Secrecy and OpenWrt supports it in recent snapshot builds. Here is interesting article with first impressions about it https://gist.github.com/est31/d92d17acbb4ea152296f9b38764cd791

Hope this solves the problem but who knows - maybe it also have some vulnerabilities.