You have just bought tickets to an exotic vacation spot. You board the flight, you land safely, you pull your netbook from your backpack, fire it up, and then check if there are any available Wireless networks. Indeed there are, unencrypted, passwordless, waiting for you. So you connect to the most convenient hotspot and start surfing. Being addicted as you are, you want to login into your email or social network just to check if something cardinal happened in the world during your four-hour flight. You're about to hit the sign in button. Stop. What you're about to do might not be safe.

Do you actually look at the certs given to your HTTPS connections? In a "hostile" environment trusting HTTPS to be secure isn't much better and often gives a false sense of security. It's pretty trivial to just proxy any HTTPS traffic for a user and unless you actually look at the cert you'll never know. I will admit that if your data stream between you and siteA is legit that people in between can't sniff it, but if you're starting out in a hostile area it can't be trusted.

How do you plan to proxy SSL traffic without having the browser complain about incorrect certificate? Besides, you'd need to actually be able to intercept the data stream first to even set up a proxy, meaning that you'd need to be in control of the wifi hotspot, the machine issuing dhcp replies, or one of the machines between the user and the target website. A random machine in the same network can't just start routing your traffic.

Well, yeah. In some random "hotspot" that you pick up while on the road the scenario that a DHCP server and/or router is compromised or maliciously setup is rather high. That's the point.

So, getting a proxy setup where the user gets certificate warnings is trivial and most people "need" to check their facebook or whatever and would just click continue. Also, plenty of CAs around the world aren't all that great and you could probably finagle a trusted cert out of many of them and use something like Squid and its SSLbump feature to just invisible proxy the SSL traffic for you.

"...you'd need to actually be able to intercept the data stream first to even set up a proxy, meaning that you'd need to be in control of the wifi hotspot, the machine issuing dhcp replies, or one of the machines between the user and the target website. A random machine in the same network can't just start routing your traffic."

Actually there are some attack vectors where a random machine in the same network can just start intercepting traffic. These aren't theoretical either, they work on many LANs.

Many wifi routers don't firewall users from each other (though commercial hotspots should). Consequently this opens up a few attacks. DHCP is extremely vulnerable to race conditions where a client joins the wrong subnet or uses the wrong gateway. I've studied this method and it is pretty reliable.

With no inter-peer firewall, arp spoofing is just as feasible with WIFI as it is on a LAN. The wrong client claims ownership of another's IP address and then forwards the packets to the real owner.

Another possibility, though this one requires some sophistication, is to spoof the hotspot's own DNS server from the wan interface. I've never tried it as it requires non-egress-filtered internet access, but if you can flood the hotspot's public ip with DNS responses before the real DNS server responds, there's a chance it will accept the fraudulent answer, and will begin feeding the wrong IP address to hotspot clients. If I remember correctly, the odds of success were maybe only 1 in 10000 due to sequence number probabilities.

Another obvious problem with public wifi hotspots in particular is that it's hard to verify that you are connected to the service you think you connected to. It's easy to impersonate an SSID and even BSSID whether encrypted or not.

This says nothing of passive wireless snooping, or heck even physical wire snooping of the hotspot's cable connection.

I usually don't care though, it's nice just to have internet access on the road regardless of who's watching. I don't particularly trust my own ISP anyways.

Several certificate authorities were just revealed to have been selling subordinate roots to IT organizations which would allow them to do just that. Here's the letter that Mozilla sent out to all their registered CAs about this issue:

So I'm afraid that trusting SSL to prevent MITM attacks is no longer possible. You should inspect certificates or use an addon like Certificate Patrol to help automate the process, and if you are connecting to an untrusted network, consider using your own VPN as well.