Ask any IT Manager today what is his or her greatest issue is when it comes to secure remote access for employees and customers, and they will tell you 9 times out of 10 that it is their end users. They are faced with the problem as to how their organizations can deploy secure remote access on a scale never before undertaken, in a cost effective and manageable fashion? Of course allied to the major issue of the end user deployments are the peripheral issues such as authentication, the integrity of the users' PC, administration, etc., all of which are important, but end user deployment and ease of use is the issue.
What manufacturers frequently lose sight of is that they are so concerned about arguing that their way of solving the problem is so vastly superior to that of their competitors that frequently they don't even ask the customer what the problem is. How often have you, as a potential end user, had to sit through a tiresome presentation about Mission Statements, long-term strategy, death by buzzword, and interminable case studies that have absolutely no relevance, and find that at the end of it all the vendor is none the wiser as to why you invited them in the first place. In fact they often assume that they are better placed to explain to an IT Manager what the problem is, which by definition can only be solved effectively by that particular brand.
The Proof of The Pudding Is What's inside the Tin
When looking at SSL VPNs, the first caveat is that SSL VPNs are not like their cousin IPsec. Because IPsec is a network layer connection, it is not concerned with the applications in the tunnel, but only with ensuring the integrity of the tunnel.
SSL VPNs on the other hand not only ensure the integrity of the tunnel, but because they are "application layer VPNs" have a direct involvement in the type and nature of the application using the tunnel. Talking to any organisation considering deploying, or upgrading existing remote access environments and you very quickly discover that whatever VPN technology is used, it must serve existing applications. The problem with many SSL VPN solutions is that the vendors are trying to dictate to the customer how the customer's existing applications should work in order to comply with the limitations of the SSL VPN technology being presented.
Regardless of the type of SSL VPN technology being deployed, one key criterion that should be applied from the outset by you, the prospective user, is whether or not there are any application limitations.
Do you as a user need to change anything, or add anything, in your existing infrastructure to let you run every application you may possibly wish to run the way you always have?
Are there any applications that require an alternative VPN technology to compensate for the limitation of the so-called VPN solution that you are being presented? If so, then it is questionable as to whether or not such a solution has the right to use the term VPN, and should possibly be forced to carry a health warning - "to be used only under certain limited conditions". So examine what is "in the tin" very carefully before signing on the dotted line.
To SSL or Not SSL
The argument as to whether SSL is more or less secure than alternative technologies is to a large extent an irrelevant discussion. As far as support for authentication, encryption, access control, and all the other technology issues both technologies can make an equally strong case.