Under Windows/Linux, client side. How can I ensure that I'm not connecting to a rogue AP?
MAC's are easily spoofed.
WEP is cracked in minutes.
WPA/WPA2 implementations are not secure in all routers.
IMO man-in-the-middle attacks are almost unavoidable
The main problem is that the control data in 802.11x is never encrypted.
Because every wireless authentication must start using the unencrypted control sequence, it will be vulnerable to a man-in-the-middle attack.
To make matters worse, 802.11x sessions can easily be forced to disconnect and re-authenticate, so the man-in-the-middle can appear at any time in the session.
By using a radio-beam directed only at the client, it is very hard for intrusion detection systems to intercept this traffic.
The solution to this is to stop worrying about the man-in-the-middle at this or that access point.
Just make a connection with any access point, secured or not.
None of them can be trusted, so don't bother.
Instead use a VPN solution that is safe from man-in-the-middle attacks*). e.g. SSHv2 in a MITM-safe configuration and connect to your endpoint using that.
What can the attacker do?
Than your attacker can listen in on the stream of data to his hearts content, all he can infer is how much data you are sending and receiving at your laptop (traffic analysis), this is still useful, but he could do that anyway by silently sniffing the wireless traffic.
But keep your laptop safe
You will still have to keep an attacker out of your laptop, employ a firewall that only accepts traffic from your VPN connection and nothing else. Use a secure operating system.
Benefits of this approach
Your laptop will be usable outside the corporate infrastructure. Realistically it will almost never stay inside that safe shell and securing all the access points you want to connect with is a pipe dream.
If you set up a proxy server for web and mail server reachable through the VPN connection you'll have full secure use of your laptop from any and all locations.
With WEP and WPA outside attackers can spoof your wireless access point.
With WPA2, regardless of encryption used authenticated attackers can initiate a mitm attack regardless of encryption scheme used. This can be done by unreliable insiders or malware on a trusted laptop.
Whilst there is no need to get all paraniod about this as D.W. correctly pointed out.
The bottom line is, there is no way to be 100% sure that you are not connecting to a rogue AP.
Now you only need to worry about that iphone.....
WPA2 has a mitm attack vector called Hole 196, see: http://www.airtightnetworks.com/WPA2-Hole196
*) not all VPN solutions are and lots of them have configurations where an otherwise safe solution is still at risk, but there are safe options and if you have a good sysadmin it is not a difficult thing to setup correctly.
The only way to be 'sure' you are connecting where you want to connect, is by having a root of trust beforehand, something shared with AP like symmetric keys or a the public key of the AP (and be trust the public key belongs to it) or trust some certificate. If you have this root of trust, you can form a basis of trusting the AP if it can provide assurances that it knows the private key or can use the shared key.
Also, if the AP uses WPA/WPA2 then mutual authentication is used, so you can infer it is the correct AP by the fact that authentication succeeds or fails.
The solution is alluded to in another answer but not explicitly stated. This is currently only possible using WPA/WPA2 Enterprise. Using EAP-TLS both the client and the authentication server (ie RADIUS) are authenticated via certificates. If you want to be sure you are connecting to the right AP secure mutual authentication is required. That being said this type of deployment is rare outside of the enterprise.
Here's what I suggest:
Configure the access point to use WPA2-PSK, with a long and strong passphrase, one that would be very hard for anyone to guess or to break by brute force. (Don't use WEP or WPA, they are not secure enough.) Don't tell anyone else the passphrase.
Configure your computer to connect to that wireless network with that passphrase, and only that wireless network. Disable auto-connect, or delete all other remembered wireless networks. (On Windows, you can do that by going to the Network and Sharing control.) If the connection succeeds, I think you have pretty good assurance that you are talking to the real access point.
This seems good enough for most purposes. If you need high security, set up a VPN and ensure that all of the network traffic out of your machine is tunneled through the VPN: then you don't care what access point it is traversing.
My general advice would be to only connect to "secured" WiFi Access Points. This requires that you and the AP have knowledge of a PSK or other authentication process, by which your system otherwise will not connect to the AP.
Additionally (and obviously) this does have the major added benefit of making sure that your wireless traffic isn't easily sniff-able by Eve.
You cant and you should not worry to much about it.
If the AP gives you internet connectivity it should be regarded with the same suspicion as any internet connection. So any sensitive information sent over the internet and the access point should be separately authenticated and encrypted.
- Use your own DNS server not the one provided by the AP
- Only use https when connecting to websites
- Or use a vpn tunnel to a reliable server
Here are a few mitigations
Don't Connect based on the SSID
You can configure many clients' remembered WiFi networks to include the BSSID of the AP. The upside of doing so is that if your device detects the SSID of a remembered network, it won't even initiate a connection unless it has the BSSID that is stored in your device's remembered network config. The downside is that this will kill more forms of WiFi roaming, and the BSSID can be spoofed. This is really only good for protecting against very simple attacks or preventing your device from attempting to connect when a name collision occurs (like when "linksys", "holiday-inn", "starbucks-wifi" or whatever else is in your remembered networks).
Use Server Authentication
In WPA2 Enterprise, you can configure 802.1X to use a RADIUS server for authentication, and the first thing you should do in this case is ensure that your client device is authenticating the server by checking to see if it has a cert signed by a CA you trust. The upside of this is that it's a robust validation technique that is extremely difficult to undermine. The downsides are that you do have to attempt a connection first (meaning the AP is at least aware of your device), this requires a lot of set-up, and this may not be in your power if you're trying to validate someone else's AP and they don't want to set-up WPA2 Enterprise.
Don't Trust the Infrastructure
Though you didn't ask, I'll give you this for free. Even if you connect to a rogue AP, tailor your behavior to help protect against MitM attacks. Use a VPN provider like PIA, use tor, use https-everywhere, hard-code your client DNS to a well-known provider like 188.8.131.52, have all authentication cookies deleted upon browser closure. However, this is still a dicey prospect. Many applications fail to perform robust CA validation on endpoints, there are attacks on Windows clients that can expose your authentication cookies through a rogue AP, sslstrip can redirect you to non-ssl sites unless your using https-everywhere in aggressive mode or the site your connecting to uses HSTS (most don't), or tor or VPN proxy can often be circumvented (usually innocently) by applications.
One of the best options for protecting yourself against LAN-level MitM, when you're using a laptop, is to virtualize Whonix (or something to serve as a VPN gateway/router) and use IOMMU to pass your WiFi card to that VM. Then route your traffic to the Whonix router and everything will be sent over TOR. This greatly eliminates proxy evasion on your client, and reduces network card/hardware attack surface. The downside of course, is that on the other side of the tor proxy/VPN endpoint your traffic is just as vulnerable to MitM attacks (however, such attacks require much more sophistication to take place between an ISP and a service provider). This sort of set-up is what Qubes-OS does, but can be managed with a little tinkering on most linux distros. This almost certainly will not be feasible on Android or iOS. #NotForTheFaintOfHeart.
This is a common issue at the security conferences I have attended in the past. One in particular provided all the delegates with the MAC address of AP. Users were instructed to enter static entries in the ARP table of your device to ensure that rouge APs would not work.
As for determining prior to connection you could use something like Kismet/Kismac to ID the AP.
You can't? You can be sure within some confidence level. The "secure" confidence level depends on your situation.
But to be more helpful, Johan has answered it pretty comprehensively. I think the more important question might be "What are the relative strengths of the various ways to secure your APs?"
And how much effort does it take to subvert the various levels of securing your AP?