[OpenWireless Tech] Tech Digest, Vol 5, Issue 5

Sun Jan 6 07:19:29 PST 2013



> From: tech-request at srv1.openwireless.org
> Subject: Tech Digest, Vol 5, Issue 5
> To: tech at srv1.openwireless.org
> Date: Thu, 3 Jan 2013 13:08:20 -0800
> 
> Send Tech mailing list submissions to
> 	tech at srv1.openwireless.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://srv1.openwireless.org/mailman/listinfo/tech
> or, via email, send a message with subject or body 'help' to
> 	tech-request at srv1.openwireless.org
> 
> You can reach the person managing the list at
> 	tech-owner at srv1.openwireless.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tech digest..."
> 
> 
> Today's Topics:
> 
>    1. Open Wireless encryption (Christopher Byrd)
>    2. Re: The police came to the AP owner first, then sniffed the
>       air to find real culprit (Christopher Byrd)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 3 Jan 2013 14:36:47 -0600
> From: Christopher Byrd <chris at riosec.com>
> To: tech at srv1.openwireless.org
> Subject: [OpenWireless Tech] Open Wireless encryption
> Message-ID:
> 	<CAOTZX8Lodu8p5KxY5rt2f5y2sQARXiF1SHPbMhKRggUzP_FO6A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I've seen SSL or VPN advocated as a solution to wireless security on this
> list. I personally don't think that HTTPS or VPN is a good answer to open
> wireless concerns. Below I've outlined some of my reasons that I believe
> network layer security is important.
> 
> First, security protocols that operate higher in the network stack, such as
> HTTPS and SSL/IPSec/PPTP VPN, often have vulnerabilities when the
> underlying network is not secure due to implementation flaws or over
> reliance on end user awareness. To provide a few specific examples:
> For HTTPS...
>   - On an insecure network HTTPS can be bypassed with tools such as
> sslstrip. Without HSTS (which hasn't been deployed widely at this point)
> browsers rely on users to notice that the site is not secure.
>   - SSL/TLS protocols use OCSP or CRL checks to identify revoked
> certificates, but these checks can be blocked on an insecure network and
> failures are treated as "soft" (non failure) errors by browsers.
>   - BEAST and CRIME attacks on SSL and TLS can disclose information inside
> encrypted protocols in specific situations that are most likely on open
> wireless connections.
> For VPNs...
>   - VPNs connections are easily blocked on attacker controlled networks
> (such as injecting TCP resets or dropping packets on evil twin APs).
>   - PPTP VPNs can be cracked with a 100% success rate, disclosing not just
> the contents but the access credentials.
>   - DNS or HTTP cache poisoning prior to VPN establishment can compromise
> traffic or systems even after the VPN is connected.
> 
> Second, HTTPS and VPN do not have adequate coverage. For example:
>   - Relying on HTTPS assumes that the Internet is only HTTP, ignoring all
> of the other interesting protocols (mail, news, chat, video, p2p, etc..).
>   - 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.
> 
> 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.
> 
> 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.
>   - Systems on an insecure wireless network can be compromised directly by
> attackers. (see for example, evilgrade attacks or network service attacks)
>   - 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.
> 
> 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.
> 
> Thanks,
> 
> Christopher
> www.riosec.com
> twitter.com/@cbyrd01
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://srv1.openwireless.org/pipermail/tech/attachments/20130103/24199128/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 3 Jan 2013 14:58:53 -0600
> From: Christopher Byrd <chris at riosec.com>
> To: Natanael <natanael.l at gmail.com>
> Cc: tech at srv1.openwireless.org, Dan Auerbach <dan at eff.org>
> Subject: Re: [OpenWireless Tech] The police came to the AP owner
> 	first, then sniffed the air to find real culprit
> Message-ID:
> 	<CAOTZX8J1MOXURArsm6z_ZP-UiK5umqYpCJXJ++PkSyDmd0T59w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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 <natanael.l at gmail.com> 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 (???) <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>
> >>
> >
> > _______________________________________________
> > Tech mailing list
> > Tech at srv1.openwireless.org
> > https://srv1.openwireless.org/mailman/listinfo/tech
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://srv1.openwireless.org/pipermail/tech/attachments/20130103/c5182fe4/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org
> https://srv1.openwireless.org/mailman/listinfo/tech
> 
> 
> End of Tech Digest, Vol 5, Issue 5
> **********************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20130106/29fbac71/attachment.html>