How safe is public wifi and how to make it safer?
June 16, 2007 4:20 PM
Public Wifi. How safe is it and what should I do to enable more secure browsing?
If you're in a reputable place offering Wifi (e.g. Starbucks, T-Mobile Hotspot etc) how safe is it to browse? I'm assuming nobody could pick up anything off my HDD (I'm assuming windows firewall should do the job), but what about if I wanted to do online shopping, login to my bank etc.
I've heard people setting up VPN's etc but am not sure how to do this. Is there any software I could be using (I just have Firefox on XP) to enable a safer browsing experience?
I've already read this AskMefi question as well as this Microsoft Advisory.
Thanks!
If you're in a reputable place offering Wifi (e.g. Starbucks, T-Mobile Hotspot etc) how safe is it to browse? I'm assuming nobody could pick up anything off my HDD (I'm assuming windows firewall should do the job), but what about if I wanted to do online shopping, login to my bank etc.
I've heard people setting up VPN's etc but am not sure how to do this. Is there any software I could be using (I just have Firefox on XP) to enable a safer browsing experience?
I've already read this AskMefi question as well as this Microsoft Advisory.
Thanks!
Public WiFi hotspots are rarely "safe" at all, since the incorporation of security more or less defeats the "come as you are" nature of the things. They're supposed to be easy access "on ramps" to the Information Superhighway, and so most public hotspots forgo any kind of ecrypted transmissions between the access point and the individual users, which in some schemes would require an encryption key be shared with users and changed frequently.
Even those hotspots that do use WEP or WPA encryption schemes often don't employ virtual LAN technology to create private subnets for each user. It's fairly easy to "sniff" packet traffic even at many "pay for service" hotspots I've used, including some whose network operators you mention.
If a Web site you communicate with properly uses SSL (Secure Socket Layer) over https protocol, at long key lengths, and you keep your sessions to reasonable lengths, you can be fairly confident that traffic between your browser and that Web server will remain private, although the traffic stream between you and it will still reveal that you are talking to a specific IP address, which is pretty easy to reverse resolve. If you're logged into to your bank for more than 2 minutes, anyone who wants to know can work out whether you bank at Wachovia or Bank of America. And suprisingly, many institutions which think their systems are secure, find out the hard way that they aren't, even in this day and age.
It's really a question of what you're willing to risk for the convenience of using public Internet connections. If you're machine is completely patched and up to date, and you avoid sitting in places where you can be shoulder surfed, and keep your sessions fairly short, and are sure your traffic is at least SSL encrypted, you've done a lot to avoid being an easy mark. To go beyond this, you're gonna have to start being a bit paranoid, and give up some convenience in connecting easily, as outlined in this article. Basically, that means avoiding ad hoc connections of any type, as they can easily be other computers in the vicinity, instead of "real" access points, and learning how to avoid things like "phishing" sites and "man in the middle" attacks.
If you have a computer connected to a reliable Internet connection at home, that you can tunnel to through a VPN, you might be able to set up a VPN between your home machine and your laptop, and through the tunnel, use your home machine to surf the Web. But unless you own and manage both ends of the VPN tunnel, or can absolutely trust those who do, there is no point to a VPN system, from a security standpoint.
posted by paulsc at 4:59 PM on June 16, 2007
Even those hotspots that do use WEP or WPA encryption schemes often don't employ virtual LAN technology to create private subnets for each user. It's fairly easy to "sniff" packet traffic even at many "pay for service" hotspots I've used, including some whose network operators you mention.
If a Web site you communicate with properly uses SSL (Secure Socket Layer) over https protocol, at long key lengths, and you keep your sessions to reasonable lengths, you can be fairly confident that traffic between your browser and that Web server will remain private, although the traffic stream between you and it will still reveal that you are talking to a specific IP address, which is pretty easy to reverse resolve. If you're logged into to your bank for more than 2 minutes, anyone who wants to know can work out whether you bank at Wachovia or Bank of America. And suprisingly, many institutions which think their systems are secure, find out the hard way that they aren't, even in this day and age.
It's really a question of what you're willing to risk for the convenience of using public Internet connections. If you're machine is completely patched and up to date, and you avoid sitting in places where you can be shoulder surfed, and keep your sessions fairly short, and are sure your traffic is at least SSL encrypted, you've done a lot to avoid being an easy mark. To go beyond this, you're gonna have to start being a bit paranoid, and give up some convenience in connecting easily, as outlined in this article. Basically, that means avoiding ad hoc connections of any type, as they can easily be other computers in the vicinity, instead of "real" access points, and learning how to avoid things like "phishing" sites and "man in the middle" attacks.
If you have a computer connected to a reliable Internet connection at home, that you can tunnel to through a VPN, you might be able to set up a VPN between your home machine and your laptop, and through the tunnel, use your home machine to surf the Web. But unless you own and manage both ends of the VPN tunnel, or can absolutely trust those who do, there is no point to a VPN system, from a security standpoint.
posted by paulsc at 4:59 PM on June 16, 2007
HotSpotVPN is your friend. Seriously: Simple, straightforward, good. You should use it.
posted by effugas at 5:18 PM on June 16, 2007
posted by effugas at 5:18 PM on June 16, 2007
The difficult part is that you tend not to be able to use HotSpotVPN until you pay, and that requires browsing. At the point you're viewing an attacker's web page, a skilled bad guy has already won.
posted by effugas at 5:19 PM on June 16, 2007
posted by effugas at 5:19 PM on June 16, 2007
If a Web site you communicate with properly uses SSL (Secure Socket Layer) over https protocol, at long key lengths, and you keep your sessions to reasonable lengths, you can be fairly confident that traffic between your browser and that Web server will remain private
This is only true if a hacker hasn't setup a rogue AP to perform man-in-the-middle attacks. In which case, they would have full access to your bank/etc.
posted by Jairus at 5:27 PM on June 16, 2007
This is only true if a hacker hasn't setup a rogue AP to perform man-in-the-middle attacks. In which case, they would have full access to your bank/etc.
posted by Jairus at 5:27 PM on June 16, 2007
At the point you're viewing an attacker's web page, a skilled bad guy has already won.
Gaining paid access in any major chain of wifi providers is done entirely on https:// connections, so you'd be safe if you did the following:
1. Open laptop, join commercial wifi network
2. Sign on through their secure site
3. Connect to HotspotVPN and surf away safely.
posted by mathowie at 5:27 PM on June 16, 2007
Gaining paid access in any major chain of wifi providers is done entirely on https:// connections, so you'd be safe if you did the following:
1. Open laptop, join commercial wifi network
2. Sign on through their secure site
3. Connect to HotspotVPN and surf away safely.
posted by mathowie at 5:27 PM on June 16, 2007
The first answer, by cactus, began with this:
"Everyone on that same wifi network can see all of your traffic"
That should read: "everyone who is trying to look" on that same wifi network. People will not casually come upon your traffic. They have to be looking for it.
But of course it is smart to expect that they are out there.
posted by megatherium at 8:18 PM on June 16, 2007
"Everyone on that same wifi network can see all of your traffic"
That should read: "everyone who is trying to look" on that same wifi network. People will not casually come upon your traffic. They have to be looking for it.
But of course it is smart to expect that they are out there.
posted by megatherium at 8:18 PM on June 16, 2007
So would be using HotspotVPN be preferable to setting up your own VPN? Are there an free solutions that would accomplish the same thing?
posted by Mave_80 at 9:19 PM on June 16, 2007
posted by Mave_80 at 9:19 PM on June 16, 2007
Logmein (www.logmein.com) has a free option that works well as a VPN for hotspots, if all you're doing is using the hotspot to connect to your home PC, and browsing out from there. This effectively isolates your browsing from the wifi network - all anybody on the wifi network would be able to "see" is that you're connecting to Logmein.
posted by gwenzel at 9:48 PM on June 16, 2007
posted by gwenzel at 9:48 PM on June 16, 2007
Jairus, could you explain what you're talking about? Man in the middle attacks aren't possible with SSL unless the user dismisses certificate errors that the browser will show.
Show me a user that doesn't.
posted by Jairus at 12:20 AM on June 17, 2007
Show me a user that doesn't.
posted by Jairus at 12:20 AM on June 17, 2007
...to follow up on that, there are a number of ways to perform transparent SSL MITM attacks: Browser holes, preloading the victim's PC with root authority certs (via faulty file sharing settings, xp holes, etc) using a MITM proxy that makes certs on the fly, etc.
posted by Jairus at 12:29 AM on June 17, 2007
posted by Jairus at 12:29 AM on June 17, 2007
Don't rely on firewalls to keep your files safe automatically, if you've enabled file sharing on your machine for home use. The wizard you use to do that will helpfully open holes in your firewall so that file and printer sharing actually, you know, works.
When you connect wirelessly to a public hotspot, everybody else on the same hotspot is effectively on the same LAN as you. So, if you've got firewalling rules set up to only allow access to stuff from your own subnet, that means everybody in Starbucks has access.
If you want to use a laptop securely at a public WiFi hotspot, you need to understand at least a little bit about networking, and you need to make sure your machine's security features are configured appropriately. Don't rely on Windows (or Zone Alarm or Norton or anything else) to look after you without you needing to jigger it, because it absolutely will not.
At the very least, you should disable file and printer sharing before you take your laptop outside your home.
posted by flabdablet at 1:41 AM on June 17, 2007
When you connect wirelessly to a public hotspot, everybody else on the same hotspot is effectively on the same LAN as you. So, if you've got firewalling rules set up to only allow access to stuff from your own subnet, that means everybody in Starbucks has access.
If you want to use a laptop securely at a public WiFi hotspot, you need to understand at least a little bit about networking, and you need to make sure your machine's security features are configured appropriately. Don't rely on Windows (or Zone Alarm or Norton or anything else) to look after you without you needing to jigger it, because it absolutely will not.
At the very least, you should disable file and printer sharing before you take your laptop outside your home.
posted by flabdablet at 1:41 AM on June 17, 2007
Show me a user that doesn't.
I wouldn't, if I had been visiting the site for years, and suddenly a new and strange (as in unknown, not as in weird) network connection caused me to get a different, questionable certificate.
Browser holes, preloading the victim's PC with root authority certs (via faulty file sharing settings, xp holes, etc) using a MITM proxy that makes certs on the fly, etc.
Of those, only the first two are really possible, and only the first is probable. Unless you're totally lax with security updates on your machine, you should be fine.
posted by oaf at 3:37 AM on June 17, 2007
I wouldn't, if I had been visiting the site for years, and suddenly a new and strange (as in unknown, not as in weird) network connection caused me to get a different, questionable certificate.
Browser holes, preloading the victim's PC with root authority certs (via faulty file sharing settings, xp holes, etc) using a MITM proxy that makes certs on the fly, etc.
Of those, only the first two are really possible, and only the first is probable. Unless you're totally lax with security updates on your machine, you should be fine.
posted by oaf at 3:37 AM on June 17, 2007
Again, there are a number of ways to do this, saying you 'should be fine' is kind of silly, I think. I can purchase a valid SSL certificate for www.the-bank-of-america.com (or BANKOFAMER1CA.COM or whatever), and use DNS spoofing to redirect from bank-of-america.com to the-bank-of-america.com, and provide a perfectly valid SSL certificate to you.
posted by Jairus at 8:34 AM on June 17, 2007
posted by Jairus at 8:34 AM on June 17, 2007
I'd heard that are also some nasty browser attacks combined with DNS spoofing which insert a clear JS window before redirecting to your banking site. I think that most people would agree that tunneling before surfing is a good idea.
posted by a robot made out of meat at 9:40 AM on June 17, 2007
posted by a robot made out of meat at 9:40 AM on June 17, 2007
You can also use SecureIX free personal account with 256 kbits max
posted by pungib at 12:25 AM on June 18, 2007
posted by pungib at 12:25 AM on June 18, 2007
You can use security products out the wazoo, and tunnel like you're digging to China, and none of it will do you any good unless you also have your firewall configured to drop all incoming connections requests even if they originate on your local subnet.
posted by flabdablet at 9:05 AM on June 18, 2007
posted by flabdablet at 9:05 AM on June 18, 2007
Also: if anybody would like to provide proof-of-concept tools, or even a convincing handwaving argument, showing that the following procedure is unsafe at a public hotspot, I'd appreciate it:
1. Turn up to hotspot with a laptop that has its firewall configured to silently drop every incoming TCP connection request, unsolicited UDP packet or ICMP request on all network interfaces.
2. Using PuTTY on Windows, or ssh on *n*x, establish a ssh session to the openssh daemon on my box at home. If the ssh client complains about the server not being in its list of known hosts, go find a better hotspot where no prick is trying to play MITM games. Use a pre-shared key to authenticate the ssh session, because the home box is configured not to allow password logons. Set the local ssh client to forward localhost port 1080 to a dynamic (SOCKS 5) port on the home box.
3. Start Firefox, which has been preset to use a SOCKS proxy at localhost:1080, and has network.proxy.socks_remote_dns turned on in about:config.
4. After checking for surveillance cameras and nearby nosey parkers, do online banking.
posted by flabdablet at 9:42 AM on June 19, 2007
1. Turn up to hotspot with a laptop that has its firewall configured to silently drop every incoming TCP connection request, unsolicited UDP packet or ICMP request on all network interfaces.
2. Using PuTTY on Windows, or ssh on *n*x, establish a ssh session to the openssh daemon on my box at home. If the ssh client complains about the server not being in its list of known hosts, go find a better hotspot where no prick is trying to play MITM games. Use a pre-shared key to authenticate the ssh session, because the home box is configured not to allow password logons. Set the local ssh client to forward localhost port 1080 to a dynamic (SOCKS 5) port on the home box.
3. Start Firefox, which has been preset to use a SOCKS proxy at localhost:1080, and has network.proxy.socks_remote_dns turned on in about:config.
4. After checking for surveillance cameras and nearby nosey parkers, do online banking.
posted by flabdablet at 9:42 AM on June 19, 2007
odinsdream, developing and instructing computer security courses is my job. Or one of them, at least.
Transparent MITM SSL attack via Internet Explorer vulnerabilities
I'm not sure what kind of proof-of-concept you want for a DNS poisoning attack -- it should be obvious how and why it would work.
posted by Jairus at 7:25 PM on June 20, 2007
Transparent MITM SSL attack via Internet Explorer vulnerabilities
I'm not sure what kind of proof-of-concept you want for a DNS poisoning attack -- it should be obvious how and why it would work.
posted by Jairus at 7:25 PM on June 20, 2007
Jairus, that paper was published in 2002. I'd be shocked to learn that the vulnerability it exploits (silent certificate acceptance for images) still exists in IE today. Do you know whether it has, in fact, been fixed?
posted by flabdablet at 5:41 AM on June 21, 2007
posted by flabdablet at 5:41 AM on June 21, 2007
I'm sure it has been fixed; my point is that SSL is never a guarantee of authenticity in a wireless environment. Redirecting a user to a fake login page doesn't require compromising SSL, in any case, only DNS (or ARP).
posted by Jairus at 3:03 PM on June 21, 2007
posted by Jairus at 3:03 PM on June 21, 2007
Without the silent certificate-acceptance hole in the browser, though, getting a successful https: connection to your fake login page would require explicit user acceptance of your MITM server's certificate, would it not?
Also, as far as you are aware, are there DNS/ARP poisoning techniques that will allow a MITM attack against a SOCKS tunnel over ssh, assuming that the ssh user already has the far-end server listed in known_hosts and doesn't allow a new server to be added at connection time?
posted by flabdablet at 4:36 PM on June 21, 2007
Also, as far as you are aware, are there DNS/ARP poisoning techniques that will allow a MITM attack against a SOCKS tunnel over ssh, assuming that the ssh user already has the far-end server listed in known_hosts and doesn't allow a new server to be added at connection time?
posted by flabdablet at 4:36 PM on June 21, 2007
If I have a real cert for my fake login domain (obtained legally or otherwise), then explicit acceptance isn't required. Nothing fishy is going on as far as the CA or the browser is concerned, which is true, as SSL isn't being compromised.
For the socks/ssh, I can't think of any technique that you'll see in the wild to compromise that.
posted by Jairus at 5:33 PM on June 21, 2007
For the socks/ssh, I can't think of any technique that you'll see in the wild to compromise that.
posted by Jairus at 5:33 PM on June 21, 2007
Set the local ssh client to forward localhost port 1080 to a dynamic (SOCKS 5) port on the home box.
I wrote that code :) It has one annoying bug; it leaks DNS when being used in SOCKS4 mode. So a really skilled attacker can get around it, by redirecting your tunneled links to a site of his choosing.
The solution is to use a browser that doesn't leak DNS -- you can make Firefox not, by selecting SOCKS5 as you mention, but IE still doesn't support SOCKS5.
posted by effugas at 3:56 AM on June 22, 2007
I wrote that code :) It has one annoying bug; it leaks DNS when being used in SOCKS4 mode. So a really skilled attacker can get around it, by redirecting your tunneled links to a site of his choosing.
The solution is to use a browser that doesn't leak DNS -- you can make Firefox not, by selecting SOCKS5 as you mention, but IE still doesn't support SOCKS5.
posted by effugas at 3:56 AM on June 22, 2007
Surely that's not a bug in your code, but a limitation inherent in the SOCKS 4 protocol?
As I understand it, SOCKS 4 simply has no way to proxy UDP, which is what DNS generally runs over; it only proxies TCP. To do remote DNS, therefore, you need to use SOCKS 5.
And IE still can't do this, you say? Why am I not surprised?
posted by flabdablet at 8:45 PM on June 22, 2007
As I understand it, SOCKS 4 simply has no way to proxy UDP, which is what DNS generally runs over; it only proxies TCP. To do remote DNS, therefore, you need to use SOCKS 5.
And IE still can't do this, you say? Why am I not surprised?
posted by flabdablet at 8:45 PM on June 22, 2007
This thread is closed to new comments.
They'll also be able to read all the email you download to your pop or imap client, unless you're using TLS/SSL. And your IM conversations? Also public, unless you're using something like Pidgin with OTR.
There are a few things you can use to mitigate these risks, two of which I've already mentioned: Use TLS/SSL for email and OTR for IM. Use https site where available, and never enter financial information into a site that starts with http://
Want to go further? Look into using Tor (the onion router) or an ssh tunnel when you're on a public hotspot. You could set up an ssh tunnel from the wifi hotspot to your home computer, and all of your traffic will be encrypted from the hotspot to home. Then the only people who can get at your data are people on your home network, your ISP, every ISP between there and your destination, and the people who own, or who have hacked, the destination host.
Happy surfing!
posted by cactus at 4:47 PM on June 16, 2007