SSL VPN: A Historical Background
To fully understand the business value of SSL VPN (and why it delivers certain benefits better than alternative technologies) it is wise to understand what factors influence the value of a remote access solution in general as well as how SSL VPN figures into the overall picture and history of remote computing.
We begin with a discussion of how and why SSL VPN came to be and the way it evolved. Early remote access was typically achieved using one of two methods: Direct modem-based dial up or leased lines.
- Direct modem-based dial-up: Users would connect to an organization by dialing (using a modem connected to their computers) a phone number belonging to the host office. Dialing this number connected the user to a modem bank at the site to which he wanted to connect. This type of access allowed users to connect from anywhere—as long as the user had access to a computer and modem (and perhaps some special software installed on the computer as well), and had access to a phone line. This is illustrated in the following figure:
Dial up offered the remote access that organizations wanted, and was certainly a wonderful technology in its day, but with the dawn and maturation of the Internet age, its days appear numbered as:
- It is expensive: Modem pools need to be purchased and maintained, numerous phone lines to be leased, and long-distance telephone charges are incurred for connections made by remote users. Remote users are often working in hotel rooms from which the cost of placing long distance calls can be quite exorbitant.
- Connection speeds are pitifully slow: The fastest modem connections offer communications speeds of under 56-kilobits per second. Today, significant percentages of businesspeople have DSL or Cable connections to the Internet at home (or in hotels). Such connections provide up to 200 times the maximum speed of dial up connections. Furthermore, media-rich business activities—those involving the transfer to images, voice, or video or even sending large presentations or spreadsheets—can render dial-up's performance unacceptable to most users.
- Fiscal inefficiency: In many environments, most phone lines and modems in the modem bank remain idle most of the time, but during peak usage periods (e.g., in an emergency when users cannot get to their offices), all of the modems/lines may be tied up, making remote access unavailable for some users (a self-initiated Denial-of-Service condition).
- Security: Dial up modem pools are an easy target for low-tech Denial of Service attacks—all that the hackers need to do is tie up the phone lines by dialing the modems.
- Access requires that the user have an analog dial up line: Making remote access impossible for many users. For example, consultants working on-site at customer sites often do not have a modem line available to them.
- Leased lines: Leased lines refer to private digital connections between two or more locations (In reality these lines may be over shared trunks but the bandwidth allocated is for use only by the leaser and only for connections between the two pre-determined endpoints.). Such lines have been used for secure site-to-site connectivity—for example, connecting two remote offices together on a WAN—for quite some time. But with the appearance of more modern technologies, the cost of leasing such lines is growing increasingly unattractive especially when compared with VPN connections over the Internet (which we will discuss in the next section).
Leased lines also provide connectivity only between two pre-determined endpoints. So they are not usable for remote access if a user has to travel to more than one remote location. They are rarely used for user-to-site connections (i.e. for users to gain remote access); with some notable exceptions where there is a significant need for a particular user to be able to access specific functions from specific locations, and the security is absolutely critical.
Many site-to-site connections formerly made over private leased lines are being made over various forms of VPN connections. (Of course, some sensitive situations mandate that private lines still be used.)
With the coming of the Internet age, IPsec VPN (and some other similar remote access technologies) became a viable alternative to the two aforementioned options.
IPsec VPN and other similar technologies (IPsec was the most popular) leveraged the Internet to establish a private communications channel over the public Internet (this is described in more detail in Chapter 4). By leveraging the Internet, the cost of providing site-to-site connectivity was dramatically reduced (when compared with leased lines), and user-to-site remote access became possible at much higher speeds than before (compared to dial up connections).
IPsec VPN, though, suffers from several drawbacks that are growing increasingly problematic with advances in technology:
- IPsec effectively establishes the remote device as a node on the internal network. So it should only be used from computers that an organization would allow to be plugged into their network had the machines been located within the physical confines of their facilities. Corporate-governed (and other trusted) computers may be acceptable for IPsec VPN usage in this regard but all other computers may not meet such restrictions. Properly implementing an IPsec VPN, therefore, offers remote access only from a small number of computers; most Internet-connected devices are unfit to be used for remote access. As a result of restricting access to be only from secure computers, organizations are often forced to purchase laptop computers for people to use when working remotely—even if these folks already have home computers. This translates into both the cost of purchasing and maintaining extra machines, as well as the cost differential between buying desktops and laptops—laptops are more expensive than comparable desktops.
- As mentioned in Chapter 1, IPsec VPNs typically require that users run special software on any client device used to access the network. The cost of purchasing, installing, and maintaining such software adds up quickly, especially since we are talking about maintaining software on machines that are often located in remote locations. Furthermore—because IPsec established network-type connectivity between corporate networks and remote users—antivirus software, anti-spam software, and anti-spyware software required on any computer connected to the corporate network inside an office must be installed and maintained on remote machines used for access. Ensuring that updated signature databases are installed on remote machines can be difficult and expensive. Sometimes third-party products are used to ensure that computers used for access have proper software configurations and updates. This may simplify the process of managing the remote devices but adds additional cost. Additionally, personal firewalls and other security tools must be implemented to ensure that the remote node does not become a gateway for other machines to inappropriately enter the enterprise's infrastructure. All of these technologies, required on machines used with IPsec VPNs, add further costs that can grow dramatically with time and a growing user population.
- Some Internet providers block IPsec traffic from residential customers, or at least make it difficult for home users to configure their computers to use IPsec VPNs. In environments in which this limitation is present, IPsec is clearly not a good mechanism for offering users remote access.
SSL VPN entered the marketplace as a technology intended to deliver the benefits that users derive from IPsec VPN (and more) but without many of the drawbacks. It leverages web browsers to provide access to enterprise applications, systems, files, and other resources from essentially any Internet-connected web browser abandoning the long-standing model of requiring specialized client software to enable VPN remote access. It leveraged three developments in the market that enabled its emergence:
- The rapid deployment of World Wide Web browsers and the fact that browsers are now available in an amazing number of locations worldwide (and even extra-terrestrially in the International Space Station!)
- The fact that high speed Internet is growing increasingly common
- The fact that many applications now offer web interfaces
Note
Although SSL VPNs now support access to resources other than applications with web interfaces, early SSL VPNs typically were limited in this regard. Some offered access exclusively to web applications; others had limited capabilities to offer some degree of access to other resources.
The convergence of these factors created a situation in which remote access technologies could rely on the presence of a uniform client at all locations without having to install special client software. That client is, of course, the web browser. Since 2002, as both web browsers and SSL VPN technology improved, many new capabilities have been added to SSL VPNs (these will be discussed in the remaining chapters of the book).
Note
SSL VPN technology was intended to address user-to-site access, not site-to-site connectivity. IPsec VPN is still the dominant technique for implementing secure site-to-site connectivity across the Internet.