**Disclosure**: I am currently in the proccess of interviewing for a job with [Fon](http://fon.com/) and this piece is largely a result of me spending time (for the first time in years) on the challenges of shared wireless in the rich countries of the west (rather than thinking mostly about the challenges in the less developed countries). *

The following are my pretty unstructured notes on how a hotspot sharing service such as [Fon](http://fon.com/) could help deal with some of the, real and imagined, security issues of hotspot-based networks. In many ways it doesn’t seem to matter to _the average user_ whether a security threat is real or imagined, as most people will never actually lose data or get atacked in a way that has actual consequences, it mostly the awareness of the threat that needs to be dealt with, rather than perhaps th threat itself. In many cases the way to deal with the awareness of the threat, is of course to remove the threat itself, however unlikely it is to ever be a problem.

Here we go….

There are 2 main security challenges that emerge from a system of shared wireless. Both are essentially the result of not having a stable trust network between the owner of the wireless network node, and the user of the network.
1. The risk of someone abusing your network for unethical (or perhaps even illegal) activities, including access to unethical materials on-line or attempts to access personal data over the local network.
2. The risk induced by the need to trust the owner of whatever Access Point you happen to connect to when away from home, and the ability of that trust to be abused top access your personal data and attempt to steal passwords to services such as e-mail or on-line banking services.

## The risk of abuse of connectivity. ##

There is a risk, when sharing ones network, that users will not use this network responsibly. This risk includes
* the risk of abuse of bandwidth,
* the risk of uethical (and sometimes illegal) use of network resources (child pornography and terrorism seem to be favoured by the news media when discussing this risk),
* the risk abuse of local network privileges.

### Abuse of bandwidth ###
When you agree to share your network with others, it is most often done, with the implicit understanding that you are sharing excess bandwidth, i.e. that you probably won’t notice the difference. However, especially in densely popuilated areas, a completely open network, may receive much more usage than the person sharing the network expects, thus adversely impacting his/her user experience.

Simple traffic shaping/bandwidth management can easily be implemented at the router level, and the biggest barrier in doing this for most people, is probably a lack of understanding of the issue, and a lack of knowledge about how to configure this. Controlled models of sharing, such as those offered by Fon and others, have the potential to easily deal with this issue. Primarily, the fact that Aliens (i.e. non-members of the Fon network) are charged a small fee for access, means there is little business seense in using someone elses network as your main connection. Also, the fact that Fon distributes routers with a simple web interface that allows for user authentiaction greatly simplifies the challenge of bandwidth control. In fact, user authentication, at some level, is a prerequisite for decent bandwidth management, and without some sort of user-level auth more advanced equipment would be required to deal with this issue (i.e. either dual access points or a system that supports VLAN’s with multiple essid’s in the same access point). Once user authentication is built into the system, it is fairly trivial to set-up a system that reserves a minimum of bandwidth for the network owner and his or her household.

**Recommendation**: Build simple bandwidth control into the default Fon-Basic firmware. Ideally using 2 separate essid’s, one running WPA and one with the exisiting captive portal solution for roaming visitors (Remark: This isn’t possible with current firmware for the Linksys WRT54G). Ensure that bandwidth control is enabled by default, and that all it takes to modify it is to enter the full bandwidth of your connection, and (if the VLAN solution is not viable) a list of usernames to be prioritised. Make it possible to disable this for advanced users like myself who have separate access points for personal use and for Fon.
I think everyone is potentially going to run into this problem, and dealing with it up-front increases the likelihood of happy users.

### Unethical (perhaps illegal) use of the network ###
This is a risk that receives a lot of attention from the media, (at least in Europe) with the story being that anyonme who has an open wireless network, essentially is abetting Terrorists and Child Pornographers in plying their trade, because they are offering a place for these criminals to connect anonymously to the Internet. From a perspective of common sense, this is a blatantly absurd assumption. The internet is pretty much built on a concept of anonymity, and there are litterally thousands of tools available for easy download that will let anyone completely hide their tracks on the internet. It is trivialk for anyone wanting to perpetrate a crime on-line to do so anonymously without resorting to parking their car outside your home and sitting in a cold, dark car while downloading information off your network. There are cybercafé’s or libraries with internet access, but more importantly, with a bit of research and the right tools they can do all this from the comfort of their DSL connection.

Legally, the position seems even more absurd. Since anyone running an Open Network is subject to other people using their network, it is impossible for law enforcement to prove that a specific bit of traffic originating on a wireless network, was initiated by any one person or computer. In other words, if your network is not open, and someone hacks into your network or computer, you may be facing a much harder job proving it wasn’t your traffic, than if the network was indeed left open. Add to this that most cases of compter crime perpetrated over private networks is actually done by hacking into windows-based computers over the Internet (remotely) and using them for sending spam or perpetrating Distributed Denial of Service attacks, and the absurdity of the legal argument rises further.

On the other hand, we have to accept that there is a will amongst both the Governments and the ISP’s to propagfate this myth, and to spread this fear of abuse. In other words, the more people believe in these absurdities, the more important it is for Fon and others to address these fears in public.

**Recommendation**: There seem to be 2 ways for a network such as Fon to deal with this issue. Technically speaking, the fact that users must be authenticated and logged in in order to use the network, would go some way towards mitigating the fear of anonymous usage (although there is not true authentication in this scenario because Fon users credentials are not checked on registration). The other, and in my mind, more important role for Fon, is to work actively through the media, to mitigate these absurdities, by repeatedly explaining the truth, perhaps starting with a FAQ on security issues. Beyond that, since the threat is fabricated anyway, there is probably very little Fon (or others) can do to deal with this issue.

### Abuse of local network privileges ###

This is, perhaps, the biggest of the security challenges faced by average users sharing their bandwidth. Given the way many people share local resources amongst multiple computers in the home, i.e. using windows file sharing or Apple Bonjour, and given the inherently incesure default configurations of most home computers, the trusted local network becomes an (unfortunately) critical part of home user security. In other words, in home swith multiple computers, a lot of trust is often placed in the fact that the ISP’s router and/or firewall provides some degree of segregation between the Internet and the local network. In the default configurations of most people who share a local network (with or without a system like Fon), this quickly becomes an issue. The way Fon and other recommend setting up the access point used for sharing, places it behind the firewall on the local area network, leaving any visitors capable of browsing for windows file shares, intercepting local Bonjour data etc.
As with the issue of bandwidth abuse, the main reason for this is probably a lack of knowledge and understadning of the issues with most regular Internet users. Also there seems to be very little information about this from ISP’s and equipment manufacturers, who prefer to tell people to close off their wireless networks, rather than helping them open them in a secure manner.

**Recommendation**: Using VLAN’s, either wireless or wired, to segregate Fon user traffic from local user traffic could be used to improve local security. However, using just the equipment available from the ISP (a low-cost router) and Fon’s access point, there doesn’t seem to be a fool-proof way to segregate traffic logically or physically, without using some sort of tunneling or vpn. (I might be wrong here, so please do correct me if I am). At least as long as both the visiting Fon users and local users wish to use the wireless network, and there is only one wireless access point available, unless the access point supports wireless VLAN’s with encryption only on one of the essids.
The simplest setup might involve 2 access points, both conencted to separate ports on the ISP’s router, and segregated intop VLAN’s on that router, but this markedly increases equipment costs.
Another, and perhaps better approach, would be for Fon, in cooperation with participating ISP’s, to produce simple security guides, explaining the local security issues, specifically as they apply to the setup of the ISP’s router with Fon’s system. This could include useful guides to setting up local VPN’s or tunnels that can be used for local file-sharing and Bonjour traffic etc. Some of the options for that include running an OpenVPN server on the access point, and explaining the advantages of local users joining a VPN when using local network resources. Alternatively, there are peer-to-peer VPN solutions, such as [hamachi](http://hamachi.cc/), which might offer a useful alternative for local filesharing, without requiring pushing the limits of the Linksys WRT54G for encryption and decryption of data. (More about the impressive hamachi later).

## Security for Roaming Users. ##

Now this is where the security dicsussion gets really interesting. Essentially, when using a 3rd party hotspot, I am placing a lot of trust in the owner of that particular hotspot (as well as his or her provider). There are basically 2 ways this trust can be abused. By the actual provider of the hotspot, or by a [rogue hotspot](http://en.wikipedia.org/wiki/Wireless_security#Malicious_Association) or [man-in-the-middle attack](http://en.wikipedia.org/wiki/Wireless_security#Man-In-The-Middle_Attacks).

Both of these threats can, in many ways, be treated as one, i.e. the scenario where Internet Access is gained through an untrusted 3rd party, be it a Rogue Access Point, or a malicious Open AP provider or Fon member.

### Trust in the Hotspot ###

In commercial hotspot networks, such a T-mobile or similar, the trust i place in the actual hotspot provider is similar to the trust I place in my ISP at home, and is founded on the reputation of that particular company, which is pretty simple to research on-line. However the Rogue AP scenario must be considered a potential threat in these cases ass well. In the case of an entirely open hotspot, or one provided by an informal network such as Fon, this trust is much harder to verify. The person who’s network i connect to has only an informal association with Fon, and the risk of acting maliciously is assumed to be much smaller than for a company making a living out of providing decent service.

In these cases (open AP’s or Rogue AP’s), the risk of abuse must be assumed to be real, even if it is probably rare. And unfortunately, in the rare cases where such a network is abused with malicious intent, this gives the hotspot owner complete access to traffic from the user’s computer to the Internet. With a skilled attacker and a less than extremely sharp user, this unfortunately can include SSL traffic such as credit card information or bank login details (see this [article on Tom’s Networking](http://www.tomsnetworking.com/2006/03/21/out_to_get_you/) for more details).

There are basically 3 ways to protect against these types of issues, on untrusted networks.
1. Assume that the risk of this happening is small enough that you can ignore it. If your biggest secrets are you’re credit card data, and you have a habit of watching your statements for strange transactions, perhaps the issue really isn’t too big. This is generally my approach, and I’m a big fan of less paranoia, but then i don’t often transmit sensitive corporate data or have other peoples trust to consider, almost everything i transmit can only hurt myself, and so the threat seems containable.

1. Ensure that nothing private is transmitted over the untrusted network. Use the Open AP only for surfing the web, and doing other innoculous things (generally things that don’t require a password. Perhaps use an anonymizer, such as [tor](http://tor.eff.org/) and [privoxy](http://www.privoxy.org/), if you don’t want the hotspot owner to know which sites you have been using). Think carefully about which data you want to risk exposing, before transmitting that data over the uintrusted network.

1. Secure your connection with a VPN or advanced tunneling. This seems to be the optimal solution, but for regular computer users, this can be pretty difficult to understand, let alone implement properly. If SSL is insecure, why trust other encryption mechanisms? And do I really need to understand what is going on in the background to be able to trust the network? There has been a lack of simple solutions for this type of encryption, solutions that just work, from companies the users trust. And specifically solutions that don’t require advanced knowledge of security.

### VPN’s and Tunneling ###
For end-users without the skills or server access to setup SSH tunnels or their own VPN tunnel, using a VPN solution is not simple. Unless your company runns a service supported by an IT department, this has, so far, not been a simple matter. There are alternatives for users without a corporate VPN. Hosted VPN services such as [HotspotVPN](http://www.hotspotvpn.com/), will let you use their servers as a VPN end-point for a monthly fee. There are 2 issues with this type of service, mainly that it introduces yet another trust point, that the end-user needs to place faith in, and that the services aren’t cheap for casual users who may not need the, on a regular basis. The main reason for monthly costs in the 10 USD region is probably bandwidth, i.e. everyone who uses a service such as HotspotVPN, passes all traffic through their servers, requiring them to have quite a bit of bandwidth available.

An interesting alternative to this, would be to use one’s own bandwidth, by hosting ones own VPN endpoint. Unfortunately there are some barriers to this, the most significant being the need to have your own server running 24/7, with a routable (preferably fixed) IP address. Both of these requirements, are currently quite demanding, and not something that normal Internet users should need to do/have.

**Recommendation**: In this respect, controlled wireless networks such as Fon have a potential advantage. Fon controls the software on the access point, and using the Linksys WRT45G series running linux, such an access point can easily act as a VPN end-point. With the right software on the access point, each users home AP could act as a VPN end-point for that user, when he/she is travelling, and using a different Fon node (or other Open AP). This might have the additional advantage of being a reason for people not turning off their Access Point when they are away on vacation or otherwise not needing the local access for a period (in other words, it might also improve the availability of Fon hotspots).

The obvious way to provide such a service in the Fon software, would seem to be using the Open Source [OpenVPN](http://openvpn.net/) implementation. Not only is it already implemented in the software that forms the basis of the Fon software, but it also has clients for all 3 major Operating Systems (Linux, Mac OSX and Windows). Unfortunately, I foresee an issue here, namely that many Fon users will not be installing their AP’s in such a way that they have a routable IP on their Internet (WAN) interface. In many cases, the ISP already provides a router, that other equipment plugs into, and some quite technical configuration may be needed to forward requests through the router to the AP. In other cases, the ISP doesn’t provide routable addresses to end-users at all, making it very difficult to provide traditional VPN endpoints on the Access Points. Note: While it may be possible to configure OpenVPN to traverse NAT systems, this is by no means easy, especially given the many different forms of NAT employed by ISP routers.

One alternative suggestion for using AP’s as VPN end-points is implementing a sort of NAT-traversing peer-to-peer tunneling system. In the past 6 months systems like these have begun to appear, and other companies are working on similar software. One implementation that can give an indication of this type of functionality is [Hamachi](http://hamachi.cc/). Hamachi is a peer-to-peer secure tunneling system, that allows you to organize two or more computers into a virtual network. The strength of the systems lies in it’s ease-of-use and the fact that hamachi manages to traverse about 95% of all NAT routers (according to hamachi’s own estimates). Unfortunately Hamachi software is not Open Source, but free clients exist for both Windows and Linux (Mac OSX coming soon) . While it may be difficult for Fon (or others) to implement this software, due to it’s closed-source nature, hamachi seems to provide a good indication of what is possible in this space. Having this type of system on their AP, would allow a user to remotely connect their laptop directly to their home AP in a secure tunneled network, and perform all their network transactions over this link, rendering rogue AP’s and MITM attacks extremely difficult. And more importantly it would allow Fon to offer a security service without having to cover the cost of bandwidth.

6 thoughts on “The Security Challenge of Open Wireless Networks

  1. “Using VLAN’s, either wireless or wired, to segregate Fon user traffic from local user traffic could be used to improve local security. However, using just the equipment available from the ISP (a low-cost router) and Fon’s access point, there doesn’t seem to be a fool-proof way to segregate traffic logically or physically, without using some sort of tunneling or vpn. (I might be wrong here, so please do correct me if I am).”

    Hey Thomas. At ISF we seperate wireless traffic from the LAN so that our members can’t access the owner’s network. The linksys will let you set up different networks on each interface. I imagine you already know that. But we can’t seperate members’ wireless traffic from the owner’s wireless traffic.

    Also – re: man in the middle – What about authetification. I know that it was a big deal when we designed wifidog that our hotspots *would not* be able to catch the authentification information of our users. User authenticates with the central server in a way that the hotspot owner can’t eavesdrop.

  2. First of all, i am by no means a security expert, but I think the Man-in-the-middle challenge is more complicated than simple authentication. First of all, a Rogue AP could offer up a fake captive portal page (copied from the real network) in what is very similar to a phishing attack, except that (because the rogue AP controls DNS) it isn’t even visible in the URL. Using https with a “real” certificate, would mean that the user would get a certificate warning in their browser when accessing the fake captive portal page, but having set-up lots of chillispot auth systems with self-signed certificates, I can pretty safely say that most users would just accept the self-signed certficate, because they assume they are on a good network.

    The other way this can be done, is for someone to setup a machine with 2 radios as a transparent bridge between the user and the real access point (using the same essid, but with a stronger radio), and let all the auth happen through the transparent bridge, and just passively sniffing traffic until the user goes to an interesting web-page, i.e. their bank, at which point the transparent bridge becomes a web proxy that accepts the password on behalf of the user and passes it on to the actual bank.

    I am sure there are ways to deal with these issues, that do not require tunneling through the AP, but i have a hard time seeing what would be more trust-worthy than tunneling back to a piece equipment you trust, i.e. your own access point.

    I realize that your access point may be compromised as well, and that truly each tunnel should go to the end-point server where that servic is being accessed, but that seems fairly unrealistic to me, compared to the simpler solution of just creating a tunnel.



  3. Well, seperating the LAN from the WLAN via VLANs doesn’t really protect the access to a local network when the router’s WAN is connected to a local network itself.

    To protect this local network I blocked access via WLAN to every private IP possible in the router’s firewall (using iptables).

    This way a local network cannot be accessed via WLAN at all.

    Cheers, Max

  4. Max, that’s a good point, and to a certain degree just strengthens my point that there are potential security issues that need to be dealt with in these scenario’s, and since most Fon users cannot be expected to be able to properly setup iptables, this is a non-trivial issue. I think my point with the multiple VLAN’s was meant to be that, with that feature, and some good default firewall rules it is possible to make a reasonably secure segregation of traffic, something that simply isn’t possible with a standard (cheap) DSL router or modem and a single Linksys box for wireless (at least not without some tunneling or VPN).



Comments are closed.