The Secure Sockets Layer (SSL) protocol and its successor, the Transport Layer Security (TLS) protocol, can be used to provide strong encryption for transmitted data. In this section, we will generically refer to both protocols as SSL. Like SSH, SSL-based solutions can use standard connections, which provide protection for a single SSL-enabled application, and tunnels, which allow one or more applications, SSL-enabled or not, to be passed through public networks securely. (TLS proxy servers are another alternative discussed later in this chapter.) Although SSH and SSL-based solutions have some similarities, you shall see that SSL is far different from SSH.
SSL Standard Connections
Without a doubt, the most widely used VPN method is web-based SSL. Countless websites use SSL to provide secure connections between web browsers and web servers. Most users are unaware of SSL other than seeing a little lock or other "secure" symbol at the bottom of their browser window. All major web browsers, such as Microsoft Internet Explorer, Mozilla Firefox, and Netscape Communicator, are SSL-enabled. SSL has become the standard method of providing encryption for web communications. Standard HTTP traffic uses TCP port 80; SSL-encrypted HTTP (better known as HTTPS) uses TCP port 443.
Although SSL is most commonly associated with HTTP, it can be used to provide encryption for other protocols. In fact, default port numbers have been assigned to various protocols that can be performed over SSL, such as SMTP over TLS/SSL (SMTPS), NNTP over TLS/SSL (NNTPS), LDAP over TLS/SSL (LDAPS), IMAP over TLS/SSL (IMAPS), and POP3 over TLS/SSL (POP3S). (More information on these assignments is available at http://www.iana.org/assignments/port-numbers.)
Many standard desktop applications also have web-based versions that are easily integrated with SSL to provide secure connections. A classic example is web-based email, which allows remote employees from anywhere on the Internet to get secure email access through an SSL-enabled web browser. However, as we'll discuss later, deploying such applications securely is more complicated than it might first appear.
SSL Client Integration
SSL is easy to enable on a client if the software that needs to use it is SSL-enabled. For example, nearly all web browsers are SSL-enabled by default. Although most browsers also allow users to configure certain SSL settings, such as using only certain SSL versions, users who leave the settings at the defaults should be able to use web-based SSL without problems.
Other applications that support SSL tend to require some basic configuration changes to enable SSL. For example, an email client, such as Eudora, is probably set by default not to use SSL because most email users do not need to. However, Eudora can be set to either require SSL to be used or to use SSL only if it is supported by the email server and to connect without SSL otherwise. Configuring an SSL-enabled client to use SSL is generally a fairly simple process. If an off-the-shelf program does not provide SSL support, however, it is probably prohibitively difficult to try to integrate that application with SSL. An alternative method, such as SSL tunneling, could be used instead.
SSL Server Integration
Enabling SSL support on an SSL-capable server program, such as a web server, is a fairly straightforward task. SSL uses a signed digital certificate on the server, so the major task in establishing SSL on a server is usually getting the proper certificate created and installed. Many SSL-capable server programs make this process fairly easy. First, the administrator is prompted to enter passwords or pass phrases, and the program generates a public key pair and a certificate-signing request (CSR), which contains the public key. Next, the administrator sends the CSR to a reputable Certificate Authority (CA), who reviews the CSR and supporting information to confirm that the request is legitimate. The CA generates a digital certificate by signing the public key and sends the certificate to the administrator. Finally, the administrator installs the certificate by following the directions for that particular server program. Now the server software is SSL-enabled.
Administrators are free to use any CA they would like, or even to establish their own CA. The value of a certificate is largely dependent on how it has been signed. If SSL is needed for an application that external customers will use, you will want to use a well-known and dependable CA; if you just need SSL for an internal-only application, then creating and using your own CA might be a better option.
When setting up SSL for a server, you should keep in mind several configuration issues. Although configuration options vary among programs, one issue you should consider is what level of encryption to require. Recent web browsers support 128-bit strength or greater encryption for SSL by default, but old browsers may only support 40-bit or 56-bit encryption. On most SSL-enabled servers, you can require a minimum encryption level. If your users will be transferring sensitive data, you should be using at least 128-bit encryption. However, if you configure your server to require that encryption level, users with old browsers will be unable to use your application. In most cases, this situation does not occur, but you should always keep in mind what capabilities your users have.
Along the same lines, it is important to remember that in most cases, you will not have control over your external users or their hosts. Assume that your clients will act as insecurely as possible, and establish your SSL security accordingly. If you don't establish a sufficiently strong minimum encryption level, or if you don't require users to run SSL, you can be sure that some connections will be made with less-than-desirable security. Carefully consider your organization's security policies when determining what levels of encryption your systems should support and require.
SSL Perimeter Defense Adjustments
Adding SSL-enabled services to your environment usually requires some perimeter changes, depending on which services are being used. Because SSL-enabled services use different ports from their standard equivalents, firewalls and other filtering devices need to be modified to allow traffic involving those ports to be passed through. You also can choose to implement web proxy services, either on a firewall or on a separate dedicated proxy server. It might be possible to put a digital certificate on that device and have it provide SSL capabilities for web-based applications. Of course, you probably want to place these proxies on your perimeter, not on your internal network. See Chapter 15, "Software Architecture," for more information on where to deploy application servers, particularly web interfaces.
When to Use SSL
The most obvious case of when to use SSL is to provide encryption for HTTP sessions. However, this concept can be extended to make web-based SSL even more useful. For example, the Microsoft Outlook email client has a web-based equivalent: Outlook Web Access (OWA). If SSL support is added to a server that provides OWA, VPN-based email can be provided for remote users. Web-based SSL might be able to facilitate various applications being delivered securelyboth web-native applications and those with alternative web-based interfaces. And you're usually pretty safe in assuming that your end users have web browsers with 128-bit encryption capabilities already installed. Web-based SSL is often transparent to users.
Choosing to implement SSL for non-webbased traffic, such as POP or IMAP, is a more difficult decision. Although many POP and IMAP clients support SSL, some do not. In general, client programs that support SSL do not automatically use it; settings and options need to be adjusted to facilitate this. For example, as shown in Figure 16.2, Microsoft Outlook has options that can be enabled to use SSL to protect IMAP and SMTP traffic. Still, these changes are minor and only need to occur during initial client configuration. SSL can provide an easy way to give clients VPN capabilities for certain applications or protocols without requiring major client changes to be made.
Figure 16.2. Microsoft Outlook has options for enabling SSL protection for IMAP and SMTP traffic.
A lesser-known way of utilizing SSL is by generating an SSL tunnel, which is similar to an SSH tunnel. After an SSL tunnel has been established, many other protocols can be sent through that tunnel. To use SSL tunneling, an SSL tunnel server must be set up, and SSL tunneling software must be installed on each client. The best-known software for SSL tunneling is Stunnel. More information on Stunnel, including directions on its installation and configuration, is available from http://www.stunnel.org/. SSL tunneling utilizes the same port-forwarding methodology as SSH tunneling: Stunnel clients designate a local port to listen for traffic and forward it through the tunnel to a particular port on the remote server. Applications on the client are reconfigured to point to the local port. The Stunnel server software runs on the same server as the remote application and listens at a particular port. When the server receives traffic through the tunnel, it decrypts the traffic and forwards it to the local port where the remote application is listening.
SSL Tunnel Perimeter Defense Adjustments
Like SSH tunneling, SSL tunneling might require many perimeter defense changes because connections carried within SSL tunnels can be established to many hosts and multiple ports on those hosts. This can severely degrade the integrity of your perimeter defenses. A better alternative is to create an SSL tunneling server and have users generate a tunnel to it, then generate additional tunnels inside that tunnel. This method limits the impact of tunneling on the perimeter defenses, although it makes tunneling more complicated and also has a negative impact on performance because of the overhead in running all traffic through two levels of tunneling.
When to Use SSL Tunnels
Overall, SSL tunneling provides similar functionality to SSH tunneling. The most significant difference is that SSL tunneling can be somewhat more expensive and not deployed as rapidly if you need an external Certificate Authority to sign digital certificates for the servers. On the other hand, this also provides a hierarchical trust capability that SSH tunneling does not. Another factor is that certain operating systems might not have an SSL tunneling client available, although most do.
Generally, SSL tunneling is recommended in the same scenarios as SSH tunneling: for a group of technically savvy users who need to access a small number of protocols remotely. Although SSH and SSL tunneling can both be beneficial, they can also be misused by attackers to conceal malicious activity, particularly outbound communications from a compromised internal machine. Because many organizations are more likely to permit outbound SSL activity than SSH, SSL tunneling might be favored by attackers who want to hide their activity from detection.
Many other tunneling solutions are available besides the ones mentioned in this chapter. Although some products might work great in your environment, others might have serious issues, such as poor performance and instability. Thoroughly test any tunneling software before deploying it to users, and when in doubt, go with a well-known, proven solution.
SSL Proxy Servers
Using SSL proxy servers, also known as SSL VPNs, has become an increasingly popular way to provide secure communications for many applications through a single method. Despite the name, SSL proxy servers actually function as reverse proxy servers. (See Chapter 4, "Proxy Firewalls," for additional information on reverse proxy servers.) Users typically use a web browser to establish an SSL-protected HTTP session to the proxy server and then provide a username and password as authentication. Assuming that the authentication is valid, the user can then run applications through the proxy server, which acts as an intermediary. Based on the user's requests, the proxy server establishes connections between itself and the necessary application servers (usually web servers). These connections may or may not be protected, depending on the sensitivity of the communications and the threats the environment faces.
Although SSL proxy servers originally served only HTTP-based applications, some SSL proxy servers can now provide access to non-HTTP-based applications by tunneling their communications through SSL. However, this requires special software to be installed and configured on the client system. One of the primary advantages of an SSL VPN over an IPSec VPN is that an SSL VPN user can sit down at any computer with a web browser, type in the VPN's URL, and get connected; an IPSec VPN requires client software to be configured (and, of course, installed first if necessary). If SSL VPN users have to install and configure special software before using non-HTTP applications, the portability advantage of SSL VPNs is reduced or negated altogether.
SSL Proxy Server Perimeter Defense Adjustments
The use of an SSL proxy server requires minimal perimeter defense adjustments. Because users access all the applications on one server through one protocol, the perimeter only needs to allow incoming HTTPS connections to the proxy server. The perimeter should also be configured to restrict outgoing connections from the proxy server to only the appropriate ports on the necessary application servers. Of course, the proxy server's security is critical to the security of the whole solution, so the proxy server must be hardened as much as possible and maintained carefully.
When to Use SSL Proxy Servers
SSL proxy servers provide a relatively fast and inexpensive way to protect communications for many applications at once, when compared to the effort in adding protection to each individual application. Having only the proxy server directly accessible by users reduces the number of targets that attackers can attempt to compromise. SSL proxy servers are best suited to protecting web-based applications; when applications use a variety of protocols, SSL proxy servers are not nearly as advantageous.