4 ms·

> they also have user, protocol, and application awareness that can be utilized to make fairly granular distinctions about who can access what without ever spec

> 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.

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.