[OpenWireless Tech] Hello World
Todd Freeman
todd at chiwifi.net
Thu Nov 1 23:00:38 PDT 2012
So I looked through the archives and I see some repeating patterns.
1st people really want to jump on the VPN bandwagon and assume all users
can use it, but noone ever mentions where the other end of the VPN is
supposed to connect to. "the internet" is a copout answer. Its the
subtle way of saying "well people are going to have to pay for something
or figure something out on their own"
This is kinda what separates free from non-free, you can't offer a
service for "free" with "oh by the way you have to pay for this addon or
it doesn't work" That's not free, it's just marketing BS.
It was suggested that the person running the AP would also run the VPN,
there are so many problems with this its not funny.
It is essentially putting all your security hope on a completely random
AP. It's odd that people would suggest that while also pointing out that
the system must be designed to allow for malicious APs.
This of course all ignores the processing overhead of so many layers of
encryption, if people are connecting to some linksys home router, it is
not going to have the CPU to handle many VPN tunnels.
I think an important point we need to ask ourselves here is, what do you
want the fundamental coverage to be like, and how do you expect the
clients to use the network. Please do not take offence to this, but from
what I can tell the roadmap is designed to be very similar to tor,
something you use every once in a while to do a limited number of things
because its ungodly slow, but with the added bonus of very spotty
coverage and no idea where any of the APs are, so you would be biking/
walking around (not driving because you would leave wifi range before
you even detected it). Also the quality is impossible to maintain even
to a minor degree as you will likely have a lot of people with DSL
modems and 128-512k upload caps.
What I like to envision is something similar to clear4g, A network with
ubiquitous coverage that is always on, and the security is managed by
any local org (towns/cities/educational institutions etc..) not by the
people running the APs. By making sign up for the central cert auth
anonymous and easy, the network operator can still comply with DMCA
requests, etc.. by terminating the account (but leave email acct intact
for 30days for them to remove anything they need) Thus the network
operator still gets safe harbour protections without permanently
blocking anyone’s access, and without having any useful information to
give to LE by design.
But one of the things the above system has that is crucial for its
adoption, is capacity. So long as we use industry standards for the auth
mechanism (wpa2-ent) which almost all routers already support, the home
users only have to change the router mode from router to AP with
wpa2-ent,and point it at the local network operators servers. no special
firmware required. Anyone can make a system more complex, layering on
encryption with a shovel is not the answer.
By allowing the network operator things like centralized auth, they can
also be encouraged to run addon services like increased bandwidth caps
as well as location based services or even telco services. This is how
we will be able to break the monopoly comcast,verizon,att, et al .. have
on internet. We need to be able to make a business case to people we
want to run this system.
So as I said, what do you want the client experience to be like ? If you
want it to be like tor, noone will want to use it for their everyday
use. Besides if we already have tor, what is the point of making another
tor ?
Yes the system I am proposing does requires a bit of work in getting the
systems to all talk to eachother, but I think that is still much more
simple then inventing entirely new authentication systems. Also we
should never design a system that allows either the router operator or
the end user to be insecure by doing nothing, and requires "addons" to
be secured. We all know how that goes 70% of the time.
TLDR; network needs to be designed with very low overhead, not rely on
VPNs to be secure, and have throughput that is better then tor. and
finally it has to be easy to incentiveize large orgs to adopt it.
On 11/01/2012 06:15 PM, Natanael wrote:
> This mail will (subtly) reference the roadmap mail that just was sent
> to this list.
>
> So here's my new suggested solution:
>
> Routers announce themselves over WiFi Direct as well as using a
> regular SSID. The "WiFi Direct announcements" also points to that SSID.
>
> The network is protected with WPA2 enterprise, using certs or
> dynamically created temprorary accounts. An OpenWireless compatible
> client will detect the WiFi Direct announcement (also called WiDi,
> that's the name I'll use later here) and see that the router supports
> OpenWireless. It will then send a request using WiDi for specific
> rules for that network.
>
> If the rules match what the client have been configure to
> automatically accept, it sends a request to connect over WiDi. The
> router responds over WiDi with "connect to my SSID ABC using
> credentials XYZ". The user don't have to do anything at all.
>
> If the rules don't match, it simply asks more networks. If none match,
> it presents the networks to the user, maybe even autosorting them
> based on how well they match his rules for autoaccept. So then he
> could see that network ABC says that to connect to that network, he
> only gets to connect to one IP that he first notifies the router of
> (which means "which VPN do you use?", "I use VPN X"), or that some
> services are restricted (port blocking, the user can demand acccess to
> certain ports), or that he needs to autenticate using a certain
> method, or that it is a paid network, etc...
>
> Preferably we would support a reasonably wide set of default rules
> that can be set, and they should be expressable using XML or JSON or
> another computer understandable format that enables autoagreement if
> both parts accept the same rules. A bonus is that this makes it
> multilingual directly, a person with no understanding of english will
> see the network rules presented in his native language when he
> connects to a router in for example an english country. This makes it
> great for tourism (this alone can be a HUGE selling point to router
> manufacturers, more tourism deals for them!).
>
> For authentication, one could imagine that the user could use OpenID
> (as previously mentioned), a SIM (smartcard) connected to a carrier or
> some other connection to a central system, and the router could tell
> the user what it supports (and maybe which of these servers/providers
> trusts). The client could then authenticate directly to his "identity
> provider" tunneled, and the identity provider then notifies the router
> when the user has successfully authenticated. This could enable router
> owners to link their routers to a wide list of local phone carriers,
> and let people on those networks to automatically connect. The
> carriers could possibly even provide VPN:s as a part of this setup.
> The router owners would be off the hook legally and maybe even get
> rewarded by the carriers (paid for on the customers' bills) for
> extending their networks. This don't have to apply to only phone
> carriers, it could apply to ordinary ISP:s and more.
> As a matter of fact, the router owner could even let the router
> connect to a service that deals with these contracts with these
> providers, so the router owner don't have to get a thousand contracts
> with various companies for this. These "authentication middlemen"
> could have international deals with each other, and they still
> wouldn't know who is using the service thanks to the tunneling used
> for auth.
>
> On all networks with authentication, I want the process to look like
> this (for privacy):
> The client first connects anonymously. If the router has a list of
> accepted providers that the user has to have an account at, the client
> tells the router which one of those he use and asks for a secure
> tunnel to that provider (that is verified, using SSL or similiar) for
> auth. The router only gets to know the provider and if the user
> authenticated successfully, and preferably the client then connects to
> a VPN from that provider (not one provided by the router). If it is a
> corporate network or similiar (we can be pretty sure this won't only
> be used for open networks), the client demands that the router
> identifies itself before it provides it's credentials (even if it's
> using SRP for auth, the username can be used for tracking otherwise by
> imitating the SSID).
>
> For routers where the owner don't care about what the users does at
> all, the router owner simply wouldn't set up any VPN or similiar. On
> these networks, the client would passively notify the user that no
> trusted proxy of any kind is used and that the router owner therefore
> could possibly spy on the traffic (classic "insecure network" warning).
>
> Devices that don't support OpenWireless will just see good old WiFi
> traffic, some of it which is a bit wierd (WiFi Direct is an official
> modification/extension of the regular WiFi protocols) and some SSID:s
> for WPA2 protected networks.
>
> ---
>
> So that was my ideas for tonight. The best of all with this approach
> is that we need NO hacking of any wireless protocols, "just" of client
> and router software.
>
> --- If everybody is thinking alike, then somebody isn't thinking //
> Stupidity is a renewable resource
>
>
> On Thu, Nov 1, 2012 at 8:12 PM, Todd Freeman <todd at chiwifi.net
> <mailto:todd at chiwifi.net>> wrote:
>
> I forgot to mention, radius and openID are separate, but linked,
> because almost all wifi devices work with wpa2-enterprise, which
> uses radius to auth and allows you to set things like speed
> limits. I want to link it to the openid so that you have an open
> and public auth system that is also secure enough to use for
> financial transactions. That is also why the CA is important, I
> envision that eventually when businesses want to do something with
> the OpenIDs, they will want to do it over SSL, and personally, I
> trust running my own CA much more then getting certs from verisign
> if activists are going to use it for things like SSL VPN to their
> cellphone. Since the back-end is ldap we should be able to
> arbitrarily add any info field that we want.
>
> ------------------------------------------------------------------------
> *From: *"Todd Freeman" <todd at chiwifi.net <mailto:todd at chiwifi.net>>
> *To: *tech at srv1.openwireless.org <mailto:tech at srv1.openwireless.org>
> *Sent: *Thursday, November 1, 2012 1:48:31 PM
>
> *Subject: *Re: [OpenWireless Tech] Hello World
>
> Sorry I may have glossed over my version a bit, This is a basic
> idea of what I am setting up. It is much more complicated the
> wireless in the developing world.
>
> http://chiwifi.net/Diagram1.png
>
> What that does not show is the ldap and certificate authority that
> I just added, which would work as the backend for radius.
>
> So the basic idea is this, To sign up for service all you need to
> do is be in range of the network (or via the website), login to it
> as if it were an open network which takes you to a captive portal,
> the captive portal allows you to sign up for an account on the
> wifi network, which includes an email account. Thus the sign up
> process allows users to be completely anonymous while still having
> a un-spoofable permanent ID on the wifi network, and because that
> ID is an openID, it can be integrated with 3rd party services
> easily. So you can tie real good and services locally to this ID,
> and use it at local businesses for bartering or bitcoin exchange.
> All while remaining just as anonymous as cash. The possibilities
> are really endless there.
>
> So the purpose is not just free wifi, but to integrate wifi into
> peoples everyday business, this allows it to take hold quickly as
> well as build communities because people will be using it for
> other services if they want to.
>
> Thus far it is setup like the, the Certificate Authority is
> running on Centos 6, using http://pki.fedoraproject.org
> The ldap server is also centos 6, running
> http://directory.fedoraproject.org
> The radius server has not been setup yet, the DNS cloud is running
> powerDNS and I have not been able to get through openWISP enough
> to get the captive portal running. Unfortunately I am not a
> programmer.
> I am planning to use http://www.packetizer.com for the openID server.
>
>
> There is currently 1 tower up. and the datacenter it is currently
> at is donating 1gbit of bandwidth. I also have 2 /64's of IPv6
> addresses, so the plan is to have the clients be dynamically
> assigned ipv6 addresses. With optional static IPs for servers. So
> when I say the issue I have been having is with the auth, I mean
> the whole system. I am not using something very simple like a
> shared secret WPA2. Thoughts ?
>
>
> ------------------------------------------------------------------------
> *From: *"Gj" <fibreguy42 at gmail.com <mailto:fibreguy42 at gmail.com>>
> *To: *"Natanael" <natanael.l at gmail.com <mailto:natanael.l at gmail.com>>
> *Cc: *"Todd Freeman" <todd at chiwifi.net <mailto:todd at chiwifi.net>>,
> tech at srv1.openwireless.org <mailto:tech at srv1.openwireless.org>
> *Sent: *Thursday, November 1, 2012 1:23:33 PM
> *Subject: *Re: [OpenWireless Tech] Hello World
>
> Good to see I'm not alone here either and thanks to SaschaM for
> the heads up :)
>
> Openwrt is a good OSS wifi router firmware starting point with
> wide decice support and one that hasn't gone the closed path of
> others eg meraki (was MIT roofnet istr before the vc's demanded
> their pound of flesh)
>
> I like the android app idea Tom - never having looked at iPhone I
> wonder what's involved with creating and equivalent iOS app?
>
> Guy
>
> Sent from my iPhone
>
> On 1 Nov 2012, at 13:45, Natanael <natanael.l at gmail.com
> <mailto:natanael.l at gmail.com>> wrote:
>
> It was a bit more active for about a month, a year ago. Let's
> hope it wakes up again!
>
> By the way, now that Android has support for automatic WiFi
> Direct service announcement/detection/connection (based on
> UPNP and/or Bonjour), we could build something on top of that.
> AFAIK all it takes is a firmware upgrade for systems with
> ordinary recent WiFi chips to use it, so I imagine routers
> should be able to support it as long as the driver makers
> added support for it.
>
> IMHO that would be the "least messy" solution. A router could
> simply announce it's support for the "OpenWireless hotspot
> protocol" to other WiFi Direct devices.
>
> On Thu, Nov 1, 2012 at 2:39 PM, Todd Freeman <todd at chiwifi.net
> <mailto:todd at chiwifi.net>> wrote:
>
> I am just glad I am not the only person on this list, the
> site is pretty sparse on community info.
>
>
> On 11/01/2012 04:07 AM, Guy Jarvis wrote:
>
> testing please ignore
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20121102/e9bf6cf9/attachment.html>
More information about the Tech
mailing list