My sense of morbid curiosity got the best of me this afternoon, so I've gone through the Web sites of three vendors who provide SSL-based remote access. The general idea for each of these is that SSL is used to create a proxy connection between a remote machine and an internal application of some sort. This is sold as being more convenient and less expensive (in terms of support and software) than a "traditional" VPN solution because SSL is ubiquitous, available to any client independently of operating system cos' it's implemented in Web browsers.
Alas, it's not this simple. A traditional Web browser presents HTTP and SSL data (and maybe FTP and gopher) to a client. Web browsers do >not< normally intercept network calls from non-Web applications (like Outlook, or a database app). In order to provide access to other, non-Web protocols (like our favorites, the Microsoft networking protocols, or an email server), the SSL-based systems have to create a mechanism for intercepting those network requests.
This is typically done via a Java applet downloaded to the remote machine when it connects to the SSL VPN server; or via a client application that must be specifically loaded onto the remote machine.
But as soon as either of these client-side apps are required, you lose the advantage of the SSL VPN in the first place -- you're managing software on the client side. Java doesn't help -- anyone who has had to support Java applications across multiple desktop operating systems is familiar with the inconsistencies in Java implementations between various versions of Windows and Mac operating systems.
The only applications that any of the SSL VPN vendors claim to be able to secure without any code being loaded on a remote client are Web-based applications. Uh, hey, wait a minute -- I can turn on SSL on my Web-based application servers and do that myself.
[In case it's not perfectly clear by now, I wasn't terribly impressed by any of these solutions!]
Details below for specific comments and questions on the three vendors I "reviewed."
My requirements for the solution are: it must be able to support arbitrary custom
database applications; it has to do granular user based access control (they
all satisfied that requirement); it must
contain the equivalent of "no split tunneling" or some other mechanism for defending against piggy back attacks (none of them did that).
1) tbird's favorite bit of clueless marketing speak from web site:
"Since the IVE provides a robust security layer between the public Internet and internal resources, administrators don't need to constantly manage security policies and patch security vulnerabilities for numerous different application and Web servers deployed in the public-facing DMZ."
---> I'm going to buy a security product from a company that thinks I don't have to patch my servers if I use their gear????
2) Implication from their architecture high-level overview is that a "protocol connector" is required on the SSL VPN server to communicate with internal applications (the equivalent in firewall terms of an application proxy). There are not going to be protocol connectors for custom applications. They specifically mention protocol connectors for MS Terminal services, MS Exchange, Lotus Notes, SMTP (may also include IMAP and POP, it wasn't clear), VT100 and 3270 apps, documents on file servers, Web-based enterprise apps, and Intranet Web pages.
3) Claims that Java-based application proxy can be used to connect to proprietary client-server apps -- but see caveat above; once we're dependent on Java we get into a multitude of support issues. And anyhow, they don't clarify exactly what "proprietary client-server apps" means.
4) On the plus side, they seem to do very good system logging -- they specifically mention that they log administrative changes as well as user activity, which is rare and very pleasant.
1) Three remote access methods: browser-based allows access to Web applications and file shares; downloadable applet for client server applications (presumably also Java based); transparent agent for Windows based systems only.
Not much more information on Web site. Previous incarnations of Aventail product were TCP-only, not very flexible.
1) tbird's favorite bonehead bit of Web site, which purports to be the product technical specifications, but has no technical specifications and at least one gratuitous grammar error.
2) Like Aventail, offers clientless access mode (for Web applications only); enhanced browser mode (which isn't explained); and device-specific client access mode for access to legacy applications.
3) And boy oh boy was this annoying: they discuss all the great things you can do with their device specific client, but they don't tell you what operating systems are supported with their client...
4) Also claims that it supports SSL encrypted connections to internal applications, but this just perplexes me -- surely that only works for internal applications that are SSL aware?
None of these vendors claims to address the split tunneling issue; none of them offers convincing evidence that they can route arbitrary IP-based traffic to an internal location, which I believe is a requirement for a system to be called a VPN.