Two-Thirds of Tech Workers Now Use a VPN, Survey Finds (9to5mac.com)

An anonymous reader shares a report: According to a survey, 65% of U.S. tech sector workers now use a virtual private network (VPN) on either work devices, personal ones or both. While much of that usage will be because it's installed as standard on work devices, a growing number of people are choosing to use a VPN on their own devices in response to past and proposed legislative changes. The Wombat Security survey found that 41% of those surveyed use a VPN on their personal laptop, with 31% doing so on mobile devices.

Comments

Depends on use case.

[green1]

I use my work laptop to work from home over the company VPN. It's necessary to use it to do any work, and makes perfect sense.

I have a personal VPN that connects my home computer (on my xDSL connection), my server (VPS in a data centre) and my car's computer (connected by cellular data) so that I can securely transmit information between them, and not have to worry about the fact that 2 of those 3 devices are on dynamic IPs.

But I don't use a VPN for general internet use because it slows down the connection and racks up billable data usage at 2 locations (home and server) instead of just 1 location (home).

Sure, I know people are probably spying on me, but the tradeoff just isn't really worth it.

Not at Google. Google has deprecated VPNs.

[swillden]

VPNs are part of a badly broken security model: the perimeter defense model. It doesn't work very well at small scales, definitely does not scale for large enterprises and generally creates a lot of misunderstandings that result in bad security decisions.

Google had a segmented perimeter defense model for several years, but has spent the last five years or so getting rid of it. The VPNs aren't entirely gone, but nearly so. You now have to get special permission to run a service that requires VPNs to access.

The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems. The assumption is that any machine connected to the network is inherently trusted to some degree, and has access to some potentially-sensitive resources merely by virtue of being connected.

The problem is that it's cost-prohibitive to build a physically-secure network, and a management nightmare to try to ensure that only trusted systems can be connected to it. 802.11X authentication, which requires every device that connects to perform a cryptographic authentication, can help keep unauthorized devices off the network but it doesn't prevent sniffing or impersonation, and can't prevent compromised devices from exploiting the trust they're given.

That last point is a really telling one, because if you assume that there's some ambient authority available to any device on the network, you inevitably end up granting that ambient authority permission to access resources that only a subset of the connected devices should actually have. Also, for all of the systems that require more authorization than the ambient authority, you still have to have some sort of login system, either per application, or else build out some sort of single sign-on infrastructure.

The solution is a zero-trust network, where no device is assumed to have any authority merely by virtue of being connected, and all connections are end-to-end authenticated and encrypted. Then, a compromised device still can only access the resources that it is supposed to be able to access, because it doesn't have authorization for anything else. It also means there's no need to try to keep unauthorized devices off the network, and no worry about attackers having physical access to the network (other than DoS concerns). This approach does increase the importance of keeping all "legitimate" devices on the network secured and patched, but that really has to be done anyway.

Google's calls its version of this approach BeyondCorp. It's build around a set of proxies which take responsibility for user authentication and identification. User devices connect to the proxy (in the case of web apps it's a literal HTTPS proxy) and strongly authenticate themselves with username, password and two-factor auth token. The proxy then has an already strongly-secure connection to the backend system the user is trying to reach, and it forward's the user's request to the backend with the user's identity (in an HTTP header, for web requests). The backend (or a service it delegates to) can then decide whether the user is authorized to connect and use the service, and if so which parts of the service the user can use, what data the user can see, etc.

The approach divides authentication from authorization, doing the first in the proxy and the latter in the backend that knows what different users are allowed to do. The backend doesn't have to know anything about user authentication, meaning as authentication needs and approaches change, they can all be implemented in the client and proxy, without touching the backends. Meanwhile the proxy doesn't know anything about authorization; it's a backend-agnostic, general-purpose single sign-on service. And, of course, all connections are encrypted and authenticated, all the time.

What all of this means to Google employees is that there is exactly zero difference bet