Evil twin wireless networks are already an issue today, which is exasperated by a lack of server encryption in open or PSK hotspots. VPN doesn't fully address this due to DNS/HTTP cache poisoning, VPN DoS, IPv6 split tunneling, etc. (see my recent post to this list for details).
There is a proposed solution in the Open Secure Wireless method by validating the domain name presented to the user when connecting to the AP against the CA-signed certificate, just like HTTPS does for secure web sites today. This would have the added benefit of improving security for some enterprise EAP-TLS and EAP-PEAPv0 deployments as well. It doesn't address potential liability; that's a legal, contractual and political issue, not a technical one. However, regardless whether VPN is a potential solution to liability concerns (which is a position I am not taking a stance on either way), VPN connections would be more secure running on top of an open but encrypted connection as it may help prevent active attacks prior to VPN establishment. Thanks, Christopher www.riosec.com twitter.com/@cbyrd01 On Thu, Jan 3, 2013 at 9:56 AM, Natanael <[email protected]> wrote: > I just want to add this thing here: > > Today, Firesheep and liability are the issues. > > Tomorrow, with better AP security but without VPN, tools that will make > your laptop fake a router to create a malicious MITM:ing AP, as well as > liability, will be the issues. > Den 3 jan 2013 15:58 skrev Andy Green (林安廸) <[email protected]>: > > On 03/01/13 22:30, the mail apparently from > [email protected]: >> >>> 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. >>> >> >> There's nothing inherently complex about it, I can install openvpn on my >> OpenWRT router and if someone hasn't already can make a local web interface >> to cut and paste client certs around from inside my home network to set it >> up on client devices as a one-off. >> >> Any certs are selfsigned by the router / "VPN server", there's no central >> coordination needed. >> >> You haven't shown anything more optimal that delivers the same result >>>> >>> >>> EAP-TLS provides the same result. Actually, it provides something better >>> >> >> No, I mean the result that the AP operator can avoid liability for what >> his clients are doing. >> >> http://en.wikipedia.org/wiki/**Extensible_Authentication_**Protocol<http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol> >> >> just provides for clientside certs, that is nice in terms of protecting >> clients from each other, but it's not addressing liability. >> >> 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.) >>> >> >> RSN as in "Robust Security Network" == WPA2? VPN encryption coverage >> from client to his VPN server means the client doesn't need the obfuscation >> from WPA any more. The AP operator may want it to restrict users but >> you're missing something important about the topic at hand --> >> >> ... >> >> 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. >>> >> >> No the proposal is the same AP can at least use WPA at the same time, if >> you have a PSK, meaning a single home router will do what people want >> today, WPA2 for their local network, and offer this on the side. If you >> want to run IPSec or anything else it can work out of its scope too. >> >> The point is that if you associate without IPSEC / WPA / etc credentials, >> it will accept your client unencrypted but won't route any packet that is >> not UDP and part of a VPN connection action. >> >> So there's at once a very open grant of use, that anyone can walk up and >> use it without identity or credentials at all, but at the same time the >> very strong restriction the usage is only to get them as far as their VPN >> server / home router running a VPN server. From that point, they go out on >> the internet "under their own name". >> >> Because an encrypted VPN link is mandatory in that "default" mode, >> clients are protected from each other and from a malicious AP... and the AP >> operator is protected from whatever the clients are doing. >> >> -Andy >> >> ______________________________**_________________ >> Tech mailing list >> [email protected] >> https://srv1.openwireless.org/**mailman/listinfo/tech<https://srv1.openwireless.org/mailman/listinfo/tech> >> > > _______________________________________________ > Tech mailing list > [email protected] > https://srv1.openwireless.org/mailman/listinfo/tech > >
_______________________________________________ Tech mailing list [email protected] https://srv1.openwireless.org/mailman/listinfo/tech
