Comments on: The Security Challenge of Open Wireless Networks http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/ Empowering people with appropriate tech and sustainable process Mon, 12 Dec 2011 10:19:08 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: emurhfkq http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-414 emurhfkq Thu, 21 Jun 2007 23:54:00 +0000 http://www.multiplicity.dk/?p=492#comment-414 <p>people are stranger</p> people are stranger

]]> By: tkrag http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-339 tkrag Thu, 23 Mar 2006 22:15:49 +0000 http://www.multiplicity.dk/?p=492#comment-339 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). cheers /tomas 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).

cheers

/tomas

]]> By: Max Horvath http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-338 Max Horvath Thu, 23 Mar 2006 19:57:15 +0000 http://www.multiplicity.dk/?p=492#comment-338 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 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

]]> By: Michael Lenczner http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-337 Michael Lenczner Thu, 23 Mar 2006 15:41:01 +0000 http://www.multiplicity.dk/?p=492#comment-337 "I think the Man-in-the-middle challenge is more complicated than simple authentication" ya. definitely. “I think the Man-in-the-middle challenge is more complicated than simple authentication”

ya. definitely.

]]> By: tkrag http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-336 tkrag Thu, 23 Mar 2006 15:35:47 +0000 http://www.multiplicity.dk/?p=492#comment-336 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. cheers /tomas 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.

cheers

/tomas

]]> By: Michael Lenczner http://www.multiplicity.dk/2006/03/the-security-challenge-of-open-wireless-networks/comment-page-1/#comment-335 Michael Lenczner Thu, 23 Mar 2006 15:17:27 +0000 http://www.multiplicity.dk/?p=492#comment-335 "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. “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.

]]>