This is a personal blog. My other stuff: book | home page | Twitter | CNC robotics | electronics

December 13, 2010

Unencrypted public wifi should die

Unencrypted public access wireless networks are an unbelievably harmful technology devised with no regard for the operation of the modern web - and they introduce far more problems than immediately apparent. The continued use unencrypted wifi on municipal level and in consumer-oriented settings is simply inexcusable, even if all the major websites on the Internet can be pressured into employing HTTPS-only access and Strict Transport Security by default.

Straightforward snooping and cute tricks such as sslstrip aside - all of them still deadly effective, by the way - there are many less obvious problems we simply can't solve any time soon:

  • Cookie poisoning: JavaScript same-origin policy draws a clear boundary between encrypted and non-encrypted content - but HTTP cookies are critically broken in this regard. It is possible to selectively overwrite secure cookies with malicious values over HTTP - with disastrous consequences for most of the contemporary web apps.

  • Plugin SOP problems: similarly to cookies, the variants of same-origin access rules implemented by plugins such as Java, Flash, or Silverlight, are often peculiar - and do not necessarily respect the isolation between encrypted and non-encrypted content (but share the cookie jar and document cache with the rest of the browser).

  • Cache poisoning: browser cache persists across network visits. On insecure wireless networks, malicious active content can be persistently cached in any non-encrypted origin - even if that origin is not intentionally visited - and will be carried onto trusted networks accessed later on (e.g., home or corporate environments); in other words, your browser may be essentially permanently backdoored after a single visit to a public hotspot. Curiously, there is some renewed interest in this area of recent. HTML5 features such as cache manifests and local storage promise to make the problem even more pronounced.

  • Cache retrieval: for the same reason, content injected over insecure wireless networks can comprehensively enumerate and read back all previously stored objects in browser cache, in arbitrarily selected non-encrypted origins - a huge privacy problem for as long as any remotely sensitive data is still exchanged over HTTP - even when this exchange itself happens only over private, secure networks.

  • Address bar autocompletion poisoning: even with mechanisms such as Strict Transport Security in place, content injected over insecure networks may attempt to silently poison address bar autocompletion mechanisms - ensuring that future attempts to navigate to a particular website will be completed in a subtly incorrect way, and will take the victim to a malicious domain name instead.
The only good way to eliminate all these risks is phasing out browser-level HTTP support altogether; but that's impractical, and simply wrong - and as much as I admire EFF, I think that universal SSL is not the right battle to fight. The burden of not decreasing user safety should rest with those introducing new standards or promoting new use cases; and something clearly went pretty awry here. We should be working hard to fix it soon - and never let it happen again.

PS. As of today, encrypted 802.11 is not much better for this use: the fiasco of WEP aside, on WPA2-PSK networks with publicly advertised key, insiders may simply decode and modify traffic to other clients by watching the handshake; while other authentication systems may be vulnerable to "Hole 196". On top of that, attackers may opt to impersonate "trusted" access points as seen fit. These shortcomings are incredibly frustrating - but can be addressed; in fact, some proprietary workarounds seem to be available already.


  1. Solution: encourage open hotspots to put the wifi password in the ssid name. Append PW=open to the ssid which can be recognized by humans and future updates to wifi software.

  2. Can't browsers be a little smart about this. When loading it could detect if the network of the user has changed and then ask if they trust the network they are connected to right now. If they answer that they don't then it could go in to a 'secure' mode where it does not persistently store any details from the session (cache, localstorage, websql DB) but deletes them on closing the browser, does not give access to the existing information stored in client-side stores (cache, localstorage, websql DB) and warns the user everytime they visit a HTTP website (if possible enforce 'HTTPS only' to sites where it would apply like GMail). On detecting an open WiFi it could do this automatically without asking the user.

    This might not stop all attacks out there and might not work for all users but it might give the majority a fighting chance at the very least. Like Http-Only and X-Frame-Options it could get implemented in other browsers if it turns out to be useful. Browsers have become far too important a software to still act ignorant about the environment they are in.

  3. Well, giving the user a choice between "be unable to access any HTTP sites" and "get traditional Internet as mom used to make" is probably a bit unproductive.

    There are less radical variants that could be attempted, though - e.g., displaying a warning in browser chrome + automatically entering incognito mode with no caching, etc.

    That said, it would be even better not to roll out stuff that suddenly makes existing technologies unusually unsafe ;-) We will never get to a point where most of our remotely sensitive interactions with the web would be occurring over STS-locked HTTPS, and I am not sure it's wise to push for this. You can maybe get top 100 most popular websites to comply - but that's still meaningless. Stamping out bad wifi is probably an easier and more sensible pursuit.

  4. Bruce: my understanding is that a public shared key is not a robust defense against other users?

    Then, there is also the possibility of just pretending to be a legitimate AP to capture clients yourself. Seems like setting up public wifi is... hard.

  5. I wasn't suggesting fully blocking HTTP sites but only 'warn', infact you said it perfectly - going in to incognito(websql?) automatically plus warning (similar to the SSL cert error warning maybe) for HTTP sites.

    Open WiFis are a convenient evil and I find myself connecting to them sometimes(no 3G in India yet), I do that in incognito mode, doing it automatically for folks who don't understand what even open WiFi is can be helpful.

    This sounds more like me trying to bug you with a feature request for Chrome than a discussion on open WiFi. Sorry about that but it would be cool if Chrome did have something on those lines :)

  6. Actually, it isn't - and the solution has been used for years:
    Provide open, unencrypted 802.11, but don't forward any traffic (it is a walled garden). The clients on the wireless can only connect to a single local server, which provides a VPN service. To get out of the walled garden, you must use a VPN client, connect to the local vpn server, and then send all your traffic over the VPN service. I have some old hardware from 2000 that did exactly this - now, most any AP that runs linux should be able to act as the AP and VPN server.
    It shouldn't be hard to create a firmware image based on OpenWRT that implements this, and you can even have a capture portal page that explains the VPN connection process, and perhaps generates OpenVPN accounts, or allows you to generate a new PPTP account. Make the capture portal page be and HTTP page that redirects to HTTPS, and you have an end to end protection method that is build on technologies designed and tested for protecting information as it goes over (relatively) public lines.

  7. Loki: there is a separate set of problems with conditioning casual users into installing easy-to-use VPN clients, or navigating pages of cryptic OS settings to configure existing facilities.

    All this can be solved with the help of OS vendors, of course; but then, it would make just as much sense to just fix 802.11. We have two viable models of mutual authentication and encryption - SSL-style PKI (admittedly sucky, but OK for commercial ventures) and SSH-style ad hoc key registration (where key fp can be displayed publicly). I suspect there is no particularly compelling reason why these weren't used in designs proposed barely 10-12 years ago, when NIC processing power wasn't that much of a constraint anymore.

  8. Michael: I guess I just don't trust the protocol designers to get security right, whereas VPN designers usually have had a good track record. Fixing the protocol is a fine idea and all - but my suggest solves it *now*, using existing and proven tech. The largest disadvantage I see is that it mostly prevents someone from connecting to any other VPN, since most OS VPN implementations don't support chaining without a lot of work.

    As for "cryptic os settings"... On both Windows and OSX, connecting to a PPTP server is *very, very* easy and fully built in, and in linux, gnome network manager has a nice PPTP plugin (not to mention, most linux users should be able to figure it out).

    OpenVPN is a bit more difficult, sure - but that is why I started with PPTP.

  9. This "problem" needs to be framed in a wider setting rather than just a "security" setting. Keeping "some" access open allows more people to participate/use the Internet and free us from Internet/Telecom monopolies. How is that a bad thing?

  10. In a broad sense, open wifi is not a bad deal for an average user. It can be abused, but just like your credit card number, most of the time, it won't; in that sense, it looks very much like many other mechanisms we rely on - see for some notes on this.

    That said, the benefits of giving people access to technology should not be used as a justification for doing it poorly: more robust public wifi is a hard problem.

    And in the context of the recent crusades for "HTTPS everywhere", it simply seems like we are to some extent trying to fix the less significant problem, while completely ignoring the more serious one.

  11. I'm just going to say that there is a very large number of devices out there that are atrociously bad at supporting anything other than basic wifi.

  12. I think PPTP is about as secure as WEP. It uses RC4 encryption and so would be vulnerable to the same cryptanalysis attacks and I don't think it can be re-keyed as often ala TKIP and other improvements that came with WPA1/2 etc. The messages have no MAC and the authentication unless down with EAP-TLS is not very secure either. VPN over WiFi is a good idea for improved security but I would stick with IPsec first or SSL-based VPN second and avoid PPTP.

  13. What do you think of this?

  14. I agree with Abuse that PPTP is terrible idea, still it would be great to implement some openvpn (rsa based) vpn capabilities to 802.11. For what i've heard there was an idea to disallow WEP support by WiFi alliance to newly produced devices. OpenVPN is a great solution to limited group of known users, but i can't imagine apply it to random, annonymous users. Still it would be nice to provide goodies like DH, HMAC to regular wifi users on airports, hotels etc.

  15. "It uses RC4 encryption and so would be vulnerable to the same cryptanalysis attacks"
    These cryptanalysis attacks require that RC4 be used in a specific way, and 128-bit MPPE don't use it that way.

  16. I run DD-WRT v24-sp2 (10/10/09) vpn with force MPPE so I can VPN on public wifi (as long as they allow VPN passthrough, many don't for whatever reason).

    Is PPTP+MPPE still crap compared to IPsec?