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.
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.