[OpenWireless Tech] Open Wireless encryption

"Andy Green (林安廸)" andy at warmcat.com
Thu Jan 3 16:51:17 PST 2013


On 04/01/13 04:36, the mail apparently from Christopher Byrd included:

Hi -

>    - VPNs connections are easily blocked on attacker controlled networks
> (such as injecting TCP resets or dropping packets on evil twin APs).

Yes, although VPN traffic is usually UDP.  If a malicious AP is reduced 
to packetloss as its attack, it's no different than a broken, congested 
or slightly too far away AP, the user will select a different AP.

>    - PPTP VPNs can be cracked with a 100% success rate, disclosing not
> just the contents but the access credentials.

OpenVPN or OpenSwan with clientside cert should be the minimum.

>    - DNS or HTTP cache poisoning prior to VPN establishment can
> compromise traffic or systems even after the VPN is connected.

Yes in the scenario discussed the server bit is on dynamic IP, requiring 
dynamic DNS to resolve.  Client side cert should take care of 
establishing that you are talking to the real server though.

Because it needs free DNS resolution to unauthenticated clients, that'll 
need rate-limiting to stop a DoS.

How the OS acts before VPN setup is also a worry.  Legit APs should drop 
everything before then but a malicious AP may service and attack it.  If 
the VPN Only scheme became established, I guess the OSes will adapt to 
understand that for VPNOnly connection, the client OS should not route 
anything unrelated to establishing the connection itself.

Your point about DNS poisoning before VPN establishment is also real, 
the only true solution is the client OS must act well when it sees the 
connection is only trusted for VPN traffic.

>    - VPN connections are only available to a small subset of possible
> users. I don't think we can assume that someone using Open Wireless
> either has a job that provides VPN connectivity and allows personal use,
> or that they have both a home Internet connection and router capable of
> VPN termination.

Yes that is the case today, but it won't be the case tomorrow even 
without efforts here.  I went shopping for a new AP to meddle with a few 
weeks ago (ended up with a Buffalo 2.4 / 5GHz one with two separate WLAN 
interfaces, now running fine on OpenWRT) and the store was full of 
routers competing on features including VPN support already from the 
factory.  If VPNOnly became available on AP side VPN endpoint at the 
home will come along with it rapidly.

> Third, wireless network access restrictions can often be bypassed
> without security at lower layers. For example:
>    - Captive portals on unencrypted networks can be bypassed with IP/MAC
> spoofing
>    - Traffic can be tunneled over DNS, ICMP, or other allowed protocols.

This is OK for liability side since the client must control the remote 
peer to do those.  If he's proxying there to get stuff done by normal 
protocols that's the same as a VPN setup from AP operator POV.  In any 
event DNS should be ratelimited and ICMP and everything else except VPN 
traffic blocked from being routed.

> Fourth, unencrypted open wireless networks put users at risk, even when
> HTTPS and/or VPNs are used. Examples include:
>    - Systems broadcast a lot of information when connected to open
> unencrypted networks that can be captured and used by an attacker.

This is true.

>    - Systems on an insecure wireless network can be compromised directly
> by attackers. (see for example, evilgrade attacks or network service
> attacks)

These don't apply if it's piped through VPN.  I agree the problem of the 
OS acting well before VPN establishment is a real danger area.

>    - Attackers in some cases can abuse IPv6 support by offering IPv6 on
> unencrypted or evil twin access points. Because IPv6 is preferred over
> IPv4, it can redirect otherwise protected traffic.

Should be covered by VPN link.

> For anyone interested, I covered much of this in more detail in an
> article I wrote for the ISSA Journal "Unsafe at any SSID: Wireless
> Hostspot (In)Security".
> http://www.riosec.com/wireless-hotspot-insecurity
>
> It is for these reasons that I believe security should be addressed at
> the network layer, and that providing encryption without authentication
> for wireless hotspots is necessary. This is why I proposed Open Secure
> Wireless (http://www.riosec.com/open-secure-wireless-2.0). It's also
> important to note that it doesn't preclude the use of other security
> technologies - you can still run captive portals, VPN, HTTPS, etc. on
> top of it, and those technologies would enjoy the additional protection
> of confidentiality and integrity at a lower layer of the network stack.

Yes if it's transparent, and doesn't introduce other problems / burden, 
it doesn't hurt.  At least the APs around today in Starbucks or whatever 
will all benefit from a security upgrade against malicious peers.

However

  - it can help against malicious peers but doesn't do anything against 
malicious AP.  VPN solves that additionally.

  - it doesn't address the AP owner liability issue, so alone it is not 
enough to get mass connection sharing to happen.  Again VPN solves that 
additionally.

-Andy




More information about the Tech mailing list