> With OpenVPN, you only have control of the client at time of install. True; even further, you only have control of the credentials at the time of issue, as the client software is freely available and trivial to install. However, in the environments I come from that is viewed as an acceptable risk as rather iron-fisted control is exercised over the client machines from birth to death, effectively extending the chain of trust through OS installation. In this arena that doesn't prevent them from taking their credentials and using them on a rogue machine, but we deal with that in meatspace.
> With the "clientless" solutions from Juniper, F5, et al, they usually > have the ability to check the security of the environment they're > running in, in some manner (antivirus running, up to date patches, > firewall, etc). They can then grant or deny access based on that > security - with OpenVPN, if the credentials are good, you get in. Absolutely - that's the "...attempt mitigating controls..." I glossed over. I don't think I'm up to arguing the validity of HIDS and NAC right now, but it's the same concept: the software that runs on the client can only report what the OS tells it. While we're there, I also cringe at the idea of giving a web browser sufficient access to the OS to try to sufficiently validate those items, particularly since so many of the solutions are IE-centric. > I won't argue the points as to which is better, or whether you should > even have remote access to your network, just wanted to point out some > missing information in your argument. Appreciate the clarification. I think each solution has its place given proper analysis and control, but also that the "browser VPN" is one of those magic bullet solutions too many people think is going to save the world/heal cancer/free kevin. RB --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
