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

[californiajack at tormail.org]

> 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.

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
"asking all clients and all servers to implement it", to implement VPN on
every OpenWireless AP, is so amazing logically difficult it is doomed to
fail. It is a logistical nightmare because of the server-client
infrastructure needed for every VPN / AP combo. The 802.11 client-server
is required no matter what, so EAP-TLS doesn't add any logistics. The
client-server infrastructure for HTTP/SSL is distributed with Windows (IE)
and Mozilla, so doesn't add any logistics. The difference between VPN and
the other "client server solutions" mentioned is that theses solutions are
already available on most laptops out of the box and don't add any
logistics.

Hopefully, only a policy change will be needed in AP wifi EAP-TLS
implementations and BAM! OpenWireless with encryption and perfect forward
secrecy and protected MAC frames!

Any proposal to embed even more programs, like OpenVPN, in an SOHO AP
router is doomed at the start. Its hard enough getting hostapd in there.
While it is possibly a solution, why? Why would someone implement a VPN on
an AP when the AP already has RSN? That doesn't make sense. It will fail
for the exact same reasons the same proposal from a decade ago failed.
People don't want Humvees, they want Hondas. Easy to drive, easy to fix,
and economical. Especially if theres already a Honda out front to use for
free. They don't want corporate VPNs to connect to Gmail, but they don't
want rogue deauth management packets every 20ms either.

In short, VPN is not needed for baseline security. EAP-TLS and SSL should
suffice, and infrastructure for them has already been setup, unlike your
custom VPN. (Assuming everyone doesn't just refuse to change a couple
lines of code in an AP, rather than setup additional client-server
infrastructre for the VPN flavor of the year on every AP and laptop.) The
VPN is superfluous to basic the needs of the OpenWireless.org project. RSN
should suffice for most, and it does not preclude VPNs in addition.

Security in depth. I see your main argument as 802.11i RSN is not needed
because you have a custom VPN. OK. I don't have a custom VPN, and I can
gether setting one up on a home network for unauthenticated wifi access
would be a bitch. You should be able to have both, but I think most will
find out if they have RSN and HTTPS then the VPN doesnt offer anything
extra of impotrance. We have the chance to make TLS for IEEE 802.11 as
easy as HTTP for the cost of only minimal *policy* changes in hostapd
(that are explicitly allowed in the RFC). We alread have a standard, we
alread have implementations on large numbers of APs. This is just a policy
change for provisioned but never implemented use cases in the EAP-TLS RFC.

>> 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
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.

Still, they dont belong on every OpenWireless.org AP and client as
required components because they have benefitial characteristics. I think
you may be confusing your setup from my setup from someone else's setup
from a basline setup.

>
> 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.

>
> -Andy
>