4 ms·

The goal of removing the excuse of "oh it's behind a VPN" is in and of itself not bad, but I have a hard time getting behind the methodology. Modern VPNs aren't

The goal of removing the excuse of "oh it's behind a VPN" is in and of itself not bad, but I have a hard time getting behind the methodology. Modern VPNs aren't just ways to get around fucked up NAT disasters in organizations that can't be bothered to learn IPv6, they also have user, protocol, and application awareness that can be utilized to make fairly granular distinctions about who can access what without ever specifying a ip/mask range. In practical terms this new model is demanding a 5-10x increase in the number of security focused people at any subject organization, and there frankly aren't that many people out to be hired that are actually any good at it. (and the "cybersecurity" organizational mentality does not overlap as much as might be imagined with security research or forward-thinking computer science, those people would be bored to suicide filling out the forms all day that they know no one ever reads) Most organizations are going to find a way to out-source this to things like "government clouds" so it's mostly a major revenue windfall for existing larger players in the same vein as other defense and government contracting.

joshuamorton 5y ago
> they also have user, protocol, and application awareness that can be utilized to make fairly granular distinctions about who can access what without ever specifying a ip/mask range. Doesn't this usually require the VPN to do weird packet inspection things? Like you can't, afaik, have a VPN do application or request aware auth of an HSTS enabled endpoint. But with the beyondcorp model, you can. So you don't need to sacrifice this, you just sacrifice the bad parts of it.
- DarylZero 5y ago
  > Like you can't, afaik, have a VPN do application or request aware auth of an HSTS enabled endpoint. The application can be made aware of the VPN identity.
- reincarnate0x14 5y ago
  There is nothing weird about packet inspection, and if the VPN or whatever gateway is keyed off the auth of the end application (and not vice versa) it doesn't really matter if it can't necessarily unveil all the TLS traffic. The main concern I have is not that the same sort of protections can't exist at the application endpoint, it's that vendors and developers and IT departments have all been absolutely terrible at doing this. They're not going to get better, they're going to find ways around it. Whereas, just to pick an example and not as any sort of vendor endorsement, I can have a Palo Alto "VPN" that isn't even using private address ranges but sends user tagging data and performs traffic inspection to stop a compromised but authenticated user endpoint from performing attack attempts on the application endpoint. Comedy example: The PAs we put it as part of a protection scheme for wide area renewable energy products blocked attempts to update some shitty GE SCADA software because GE was too lazy to renew their signing certificate and was somehow still OK with shipping builds. All the end users had been trained to simply click the "WTF YES I DON'T CARE I HAVE TO WORK TO DO" button. The network control policy did not give them the option. Application layer proxies can do the same thing, sure, but that fundamentally isn't really any different other than it moves responsibility around.

joshuamorton 5y ago

> they also have user, protocol, and application awareness that can be utilized to make fairly granular distinctions about who can access what without ever specifying a ip/mask range. Doesn't this usually require the VPN to do weird packet inspection things? Like you can't, afaik, have a VPN do application or request aware auth of an HSTS enabled endpoint. But with the beyondcorp model, you can. So you don't need to sacrifice this, you just sacrifice the bad parts of it.

DarylZero 5y ago
> Like you can't, afaik, have a VPN do application or request aware auth of an HSTS enabled endpoint. The application can be made aware of the VPN identity.
reincarnate0x14 5y ago
There is nothing weird about packet inspection, and if the VPN or whatever gateway is keyed off the auth of the end application (and not vice versa) it doesn't really matter if it can't necessarily unveil all the TLS traffic. The main concern I have is not that the same sort of protections can't exist at the application endpoint, it's that vendors and developers and IT departments have all been absolutely terrible at doing this. They're not going to get better, they're going to find ways around it. Whereas, just to pick an example and not as any sort of vendor endorsement, I can have a Palo Alto "VPN" that isn't even using private address ranges but sends user tagging data and performs traffic inspection to stop a compromised but authenticated user endpoint from performing attack attempts on the application endpoint. Comedy example: The PAs we put it as part of a protection scheme for wide area renewable energy products blocked attempts to update some shitty GE SCADA software because GE was too lazy to renew their signing certificate and was somehow still OK with shipping builds. All the end users had been trained to simply click the "WTF YES I DON'T CARE I HAVE TO WORK TO DO" button. The network control policy did not give them the option. Application layer proxies can do the same thing, sure, but that fundamentally isn't really any different other than it moves responsibility around.