> On 03/01/13 20:03, the mail apparently from [email protected] > included: >>> On 03/01/13 15:08, the mail apparently from [email protected] >>> included: >>> >>>>> solutions in parallel without spending so much energy knocking down >>>>> other people's ideas, more progress will be made. That's not to say >>>> >>>> These are old ideas, and knocking them down is as easy as knocking WEP >>>> down. They are suboptimal, and people should be made aware of the HUGE >>> >>> What do you mean by comparing VPN to WEP, that it is insecure like WEP? >>> It is not. >> >> VPN is a suboptimal solution like WEP. A (rather beautiful) hack, like >> WEP. > > Words like "suboptimal" and "hack" are not adding anything to > understanding the issues: they're, well, just, like your opinion, man.
When your VPN concatenator no longer accepts your password you will understand why the VPN is suboptimal: not everyone can use one. It is a very complex setup. > You haven't shown anything more optimal that delivers the same result EAP-TLS provides the same result. Actually, it provides something better than IPsec: it provides link-level security. If you don't know what that means, then I really can't show anything more. > and I don't agree it is a hack layering the encryption like that. I think its a hack if you expect everyone to do what you have been provided by someone else: your corporate VPN. You can always disable RSN in my solution. You can always have your corporate VPN in my solution. In your solution, you can't. Because its a hack (an old hack.) > >> The flaw in WEP was technical; practically is was painless. The flaw in >> VPN is practical and logistical vis-a-vis OpenWireless; technically it >> is >> rock solid. >> >>> >>>> weaknesses, in this case the weakness is primarily that VPN is a >>>> client-server solution, and asking all clients and all servers to >>>> implement it will end up in the same situation we are in now. The >>>> weakness >>> >>> SSL is a "client server solution" that has done great and has spread to >>> even computationally weak and inexpensive clients, hell even HTTP is a >>> "client server solution". So is WPA / AP model itself. Not sure what >>> insight you think it is bringing to the table to say that VPN is bad >>> because there are clients and servers. It's already proposed that home >>> routers become the "VPN server" for the remote owner solving >>> provisioning and secure setup for VPN clients by doing it at his home >>> network as a one-off. >>> >> >> I'm saying VPN plain isn't need for a baseline security. As I say, its >> the > > What exactly is "a baseline security"? A minimum level. > > The major problem with offering open access points is the liability > assumed by the AP operator for what the clients do with his IP address. True in some jurisdictions I imagine, like China and Germany. Off hand, I don't think so in any U.S. state, like here in California. I have never heard of Comcast getting in trouble because someone used their IP address for child pr0n. That question is very jurisdictional, like the question: what is the penalty for smoking marijuana? That depends on whether your in Amsterdam (none in reality), Colorado (none in reality), California (I hear its a $100 traffic fine, but no cops bother), the UK, or China. Same goes for liability for Internet service. > > Only a clientside VPN solution addresses this critical point. Since I No, it does not. A locally provided IP address (provided by the "AP") is still used to communicate with your remote (remote as in its elsewhere on the Internet) VPN, wherever it is on the Internet. Don't confuse your local IP address used for Internet access from the AP operator with your IP address provided by your VPN operator for use on their network and accessable through your TUN network interface. That's why its called "virtual", because that's not your real IP. Your real IP is the one the "AP" gave you. You can't use an IP address from China in Texas. When you're in Texas, you use a Texas IP to communicate with any computer not on your LAN, period. Whether or not that Texas IP packet has a VPN-encrypted Chinese IP address inside it is irrelevant; it is a Texas IP address you are using in Texas to access the Internet. To sum up my argument, just in case you don't understand: the "AP" IP is real, while the VPN IP is "virtual". The "virtual" IP is only used within your corporate VPN network, but it can only get to your VPN network using the AP IP over the Internet. Does that make sense? >From the point of the AP operator, his IP address is being used to connect somewhere on the Internet. How does he know it is a VPN you are accessing and not childpr0n.com? Let me answer you: he does not know. (Especially if the childpr0n.com connection looks like VPN.) They are all just IP address somewhere on the Internet to him. Any attempt to try and filter out anything but VPN traffic would not be OpenWireless, it would be ChineseOpenWireless. > do not see a resurgence of open, Internet-connected APs occurring unless > something changes the liability issue, I think this IS part of any > "baseline", whatever that means. I agree. If its a problem it needs to be identified. > >>>> really isn't a protocol one, but one of application. The proof is in >>>> the >>>> pudding: because VPN as a solution to wifi has already been >>>> recommended >>>> a >>>> long time ago, and no one uses it a decade later because it is >>>> impractical >>>> and hack-ish. >>> >>> Plenty of people use corporate VPN over unsecured Wifi, because it's a >>> very nice solution allowing the use of even hostile APs without >>> compromising ability to use content from the secure network safely. >>> Those are characteristics we can all benefit from. >> >> Plenty of people use [IPsec, Skype...] over unsecured Wifi, because it's >> a > > That's a different subject: you claimed "no one uses [VPN] a decade > later because it is impractical and hack-ish", and that's completely > false. I think you lack context for my sentence. Obviously, people with really shitty networks use VPN and an unsecured Wifi. No real university in California does AFAIK, except maybe some shitty community colleges. Now, many universities did at one point. But they stopped, because using VPN over an unsecured wifi is just plain suboptimal. Almost every university in the largest state in the US apparently agrees with me (actually I agree with them), because you don't need a VPN for secure wifi at these universities--you use RSN and EAP-TTLS etc. Which is cool, because using standard-based appropaches like 802.1X instead of custom VPN solutions enables things like eduroam, which is awesome. VPNs and RSN-disabled wifi networks just plain suck from a practical standpoint. How many VPN softwares have you gone through? We went through like 2 or 3 before switching to a standards-based option based on RSN, and it hasnt changed since. Any laptop will now work without any VPN software, and has a "VPN in the AP" so to speak. Because thats what RSN is: a VPN in the AP, and then some. Obviously not everyone stopped this horrible practice. I can't believe your work still makes you use VPN to login to their unsecured wifi. That sucks. I just don't think OpenWireless should be founded on such badly designed networks. > >>> The additional benefit above that is that VPN-only APs can decouple >>> themselves from responsibility for what that secure client traffic is, >>> since the AP IP is not used to get it from the Internet. >>> >>> Do you have a way to get those characteristics from a better scheme? >>> Let's talk about that if so. >> >> Uhh...? Which IP is used to forward your data to your remote, off-site >> VPN >> concatenator then? You can't just pick random IPs as your source address >> and expect them to route back; of course the AP IP (as you call it, I >> assume you mean a local network or router provided or recognized IP) is >> goin to be used. At that point, the local hotspot still has the same >> "responsibility for what that secure client traffic is" as it did >> without >> your VPN or whatever other IP data you sent, VPN or HTTPS or whatever. >> They can never decouple themselves, the IP addresses are theirs, and you >> need their IP addresses to communicate with the Internet, including your >> VPN. >> >> I think you misunderstand Internet networking, or you have not adequetly >> explained the scenario. > > If I associate with an unencrypted AP using a VPN on my client, my VPN OK, so you connected to a horribly configured AP. Got it. > "server" is my home router box, and I bring up reddit in my browser: > reddit just sees my home IP address in its logs. If I post something > bad like "xyz is a dumbass", an enraged xyz can get a court order for > Reddit's logs and find my home IP and I get my no doubt well-deserved > punishment for impugning the reputation of the dumbass. There's nothing Yes. > floating about to implicate the innocent AP owner who happened to be the > first hop: nobody will pound on his door at 3am. Unless you decide not to use a VPN, and just directly post on reddit. In your scenario, its still your choice to fuck over you or him. How exactly is the VPN required? Whats to prevent an asshole from just posting to reddit from an unencrypted AP? Nothing. Nothing prevents you. I can give a similar example using SSH, about how I SSHd to my home box and posted "xyz is a dumbass" on reddit. So? Are you arguing that running a VPN server is required for security? That running an SSH server is required for security? Are you arguing that my grandma must set up an SSH or VPN server to get security? Instead of just fixing EAP-TLS? That's suboptimal, at a minimum, but a more precise description may be "not gonna happen". > > Do you see now that might help encourage AP owners to allow VPN-only > connections from random clients? Or, do you have a better scheme that > delivers the same kind of result? I still don't know what you mean by "VPN-only". So no one should be able to use SSH? They shouldn't be able to use IPsec ESP? That isnt OpenWireless. If my grandma can't use SSH, or some other protocol, on her network because you decided that only VPN is allowed, that is a good indication your solution is a hack. If this solution is just for your network, hey by all means go ahead. But I don't think hacks should be encouraged by OpenWireless.org. > > -Andy > _______________________________________________ Tech mailing list [email protected] https://srv1.openwireless.org/mailman/listinfo/tech
