[OpenWireless Tech] The police came to the AP owner first, then sniffed the air to find real culprit

[Natanael]

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 (林安廸) <andy at warmcat.com>:

> On 03/01/13 22:30, the mail apparently from californiajack at tormail.orgincluded:
>
>> On 03/01/13 20:03, the mail apparently from californiajack at tormail.org
>>> included:
>>>
>>>> On 03/01/13 15:08, the mail apparently from californiajack at tormail.org
>>>>> 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
> Tech at srv1.openwireless.org
> https://srv1.openwireless.org/**mailman/listinfo/tech<https://srv1.openwireless.org/mailman/listinfo/tech>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20130103/5ee2fd0a/attachment.html>