Live data from Hacker News

Even with a VPN, open Wi-Fi exposes users

arstechnica.com

11–20 of 44 posts

Re: Even with a VPN, open Wi-Fi exposes users

#11
If you don't have enough control over your applications to have them connect over trusted networks and not untrusted ones, you probably don't have enough control to stop them leaking more information than you would want to the endpoints they connect to.

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.

Re: Even with a VPN, open Wi-Fi exposes users

#12
> Do you use a POP3 or IMAP e-mail client? If they check automatically, that traffic is out in the clear for all to see, including potentially the login credentials. Other programs, like instant messaging client, may try to log 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.

Re: Even with a VPN, open Wi-Fi exposes users

#13
post #4

Windows is a step ahead of OSX with it's Private/Public networks distinction. Having little snitch installed on OSX it's staggering to see how many core services are trying to access external services, most of them on port 80. 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.

You're confusing two different things. Windows still does phone home even in private network. In private network it just "locks" down access to your computer to some extent.

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.

Re: Even with a VPN, open Wi-Fi exposes users

#16
TL;DR: You usually first have to accept the WiFi network's terms of service on a special page (called a captive portal) before you get Internet access. Until you do that, VPN doesn't work, and by then your email program (or anything else) may already have checked for new messages. If you have a password for your email account (which surely you do), it may have been sent unencrypted, open for anyone nearby to see.

Re: Even with a VPN, open Wi-Fi exposes users

#18
I wish "captive portals" were more integrated into the stack somehow. It would be nice if the OS knew from DHCP or something that the connection was captive (without having to guess by trying known URLs), so it could suppress anything from getting out (or just not initialize routes, since there is not truly a route yet). The OS can automatically open a simple browser to do the auth, then allow all traffic. (Or in the case of an unsafe network, allow the VPN to initialize, then allow all.)

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.

Re: Even with a VPN, open Wi-Fi exposes users

#19
> The Wi-Fi Alliance has had a solution for this problem nearly in place for years, called Passpoint. The Passpoint protocol was created to allow for Wi-Fi "roaming" by creating a way for access points to grant access by way of a third-party credential, such as your Google ID or your ISP account.

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.

Re: Even with a VPN, open Wi-Fi exposes users

#20

I wish "captive portals" were more integrated into the stack somehow. It would be nice if the OS knew from DHCP or something that the connection was captive (without having to guess by trying known URLs), so it could suppress anything from getting out (or just not initialize routes, since there is not truly a route yet). The OS can automatically open a simple browser to do the auth, then allow all traffic. (Or in the…

Back in 2004 Microsoft had an initiative to build a smart client into XP (and future OS versions). I was in a group of people from various companies who went to Redmond and did a 3-4 day workshop where we covered their ideas, how to implement into the networks/software we were operating, etc.

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.

Post reply on HN