Even with a VPN, open Wi-Fi exposes users
arstechnica.com
arstechnica.com
One of the first things you should do if you have a VPN solution is to make sure, via HTTPS that your IP address is the actual IP address of the VPN provider:
https://www.google.com/?gws_rd=ssl#safe=off&q=what+is+my+ip+...
- host outbound traffic disabled except security updates & VMs
- non-persistent "browser VM" for captive portal login
- non-persistent VPN VM
- user data VM(s), virtual NIC routed only to VPN VM
That's not meant to be snarky; it's a real problem. I have an android phone but I am very conscious that it's doing a lot of things I don't control and I can't really trust it.
A VPN can be part of a carefully implemented security policy, or it can be a thing that might help a little on a generally insecure base, but it can't turn an insecure machine into a secure one.
The VPN simply won't connect if there is a portal because non VPN connections (eg to the portal) are forbidden, and the device won't allow any network traffic until the tunnel is up and established.
Its quite nice actually, and if you're worried about speed issues, host the server on a VPS you trust.
In both cases we're still lacking good representations of network traffic. If things didn't happen in the dark in the background users would probably be more concerned and watchful.
Do you think developers assume you will not notice or will not care?
In my experience, most if not all of this software uses DNS for the attempted dial outs. Running my own DNS makes blocking easy.
The same is also present in OS X under Firewall settings where you can go stealth mode and / or block all incoming connections.
Both phone home.
If that's too much to ask for, it would at least be nice to have some solution to the problem of HTTPS requests before the captive portal has granted access. The current choices seem to be a) drop all HTTPS packets, so the user waits for a page to load until they figure out they are captive, b) break the connection, so the user sees weird errors like "connection reset", c) MITM with a self-signed certificate or something, so the user gets cert errors, but if they go against best practice and bypass cert errors they'll get redirected to the authentication URL. Would it be crazy to have an SSL packet that the portal can inject, that tells the client to stop handshaking, and that they need to authenticate somehow? Giving a URL to redirect to would be way too open for abuse, I guess, but just getting an obvious signal that the connection isn't really up could be a step forward.
At the time, most of us agreed it was needed, but would never really take off. The implementation on the network-side was somewhat clunky and the user experience (even integrated in the OS) was just also pretty bad.
I wish I could remember what it was called to look at detail now. The idea was to make it easier for Users to connect to public WiFi networks, though had it taken off, I'm sure there would be additional security built-in now.
There are some public WiFi networks (and "Smart Clients" e.g. Boingo/iPass) that have 802.1x integration with networks. This does offer some more security, but still not a perfect solution as Users must have the software installed.
Frankly, I see everything becoming even less secure in the near future. I started building/operating WiFi & wireless networks in 2001. I was out of the industry for a few years, but now I'm back with a company enabling businesses to offer free WiFi as a marketing tool (plug: http://www.gozonewifi.com) I never would have thought the demand was so high for this type of service, but it is. People love it and use it a lot.
My very convoluted solution has been to use my phone and PDAnet [1] for the actual connection, instead of the public train's wifi (they go down with similar frequency). When my phone connection goes down, it requires a hard reset (unlike the public train wifi). Before I actually initiate the hard reset, I use Pauser [2] to manually stop my main browser, then I open my secondary browser and verify I can connect to one of several different generic sites, while Tunnelbear is active. Once I know Tunnelbear is active, I'll un-pause my main browser and go back to work.
In other words, (A) I avoid the public wifi, (B) I manually have to pause my main browser when I loose connection, (C) I have to ensure I'm not using me secondary browser for anything secure, and (D) I have to manually ensure Tunnelbear has fully secured my connection before restarting my main browser.
I'm sure this still leaves me open to attack, but less so than not using this process.
[1] http://pdanet.co/ [2] http://sdunster.com/project/pauser/
I do live in Europe though and I've never heard about a "tether plan". Is that some American weirdness maybe?
[1] https://en.wikipedia.org/wiki/Tethering#United_States_of_Ame... ; It looks like the U.K. has similar tethering charges
[2] https://en.wikipedia.org/wiki/United_States_2008_wireless_sp...
Not sure if it's been acted on.
That sounds overly pessimistic.
Most POP3/IMAP email services nowadays support TLS, and some don't even work unless you use TLS. Most email clients, likewise, are designed to use TLS by default when you first set up an account. If yours isn't, complain to the developer(s).
Likewise, I'm not aware of any popular instant messaging client that sends login credentials in the clear in this day and age. At least none of the programs I've set up to log in automatically (Dropbox, Skype, etc.) seem to be guilty of that crime.
The part about the operating system automatically connecting to various servers in the clear is a bit worrying. But for the time being, I'm pretty sure none of that traffic carries any login credentials of mine.
Using TLS isn't enough, the clients needs to check the certificate. I know that K-Mail does, but I wouldn't bet on every mail client out there doing so.
There's another risk, though: the WiFi layer and TCP/IP stacks themselves. These might be hacked and WiFi is regularly by NSA per leaks. This is why high assurance wireless VPN's they endorse use a dedicated device for secure wifi connections. It works as follows: a device/chip for trusted data with a physical connection to PC; a secure chip in middle for crypto & control logic; a device/chip for untrusted code (esp Wifi driver) and data with connection to antenna. Some use separation kernels instead of different chips these days. The device is programmed to not let "trusted" data through until (a) untrusted chip says wireless is working and (b) VPN is established in middle chip. It can be modified to deal with captive portals although that creates potential covert channels or attacks. Maybe one can tie a sandboxed browser to the untrusted chip for approving the terms. It and the channel are killed the moment Internet is reachable. More work needs to be done in this area.
Regular setups not worried about targeted hacks will probably be fine following the advice in the article. People worried about targeted attacks rarely use Windows anyway haha.
Ummm, seems like the cure is worse than the disease. So, the suggested response to leaking information via HTTP (and what security-important service uses HTTP these days?) is to…leak usage information to one's provider?!?
Moreover, Passpoint is very much built on a feudal model, where users belong to large corporations which trust one another (for roaming &c.); that seems like exactly the wrong direction to go.
I'm certainly not going to let Google or my ISP know which WiFi hotspots I connect from though. Thanks to always on VPN they only see my VPN server IP.
Also, use is about ten times faster than a web client.
That said, I use the exact same approach; and Alpine is actually pretty usable even from an Android tablet, especially since JuiceSSH lets you create shortcuts that automatically connect to the server and run "exec alpine".
Only if you're pinning the cert...
ssh does not rely on a hazy collection of 500+ middlemen that includes several rogue governments and very poorly behaved corporations to give you the "lock icon". In ssh, the key matches perfectly or it doesn't.
SSL ? Not so much ...
How do you know?