Internet & Intranet Security

15.5 CONCLUSIONS

In this chapter, we focused on some security protocols that have been proposed for the transport layer. In particular, we overviewed and discussed the SSL and TLS protocols. In addition, we mentioned the PCT protocol as being a simple derivative from SSL version 2. With the official release of the TLS protocol specification and its submission to the Internet standards track, Microsoft has abandoned the PCT protocol. In addition to SSL, PCT, and TLS, the first edition of this book also discussed the SSH protocol in the chapter referring to transport layer security protocols. This is arguably correct because SSH provides similar functionalities to SSL and TLS (i.e., it provides a mutually authenticated and encrypted session between two endpoints). Contrary to SSL and TLS, however, SSH is most often used as a replacement for more traditional terminal access protocols, such as Telnet or Rlogin. Consequently, we overview and discuss SSH when we talk about security-enhanced terminal access protocols in the following chapter.

Given the current situation on the Internet security market, it is possible and very likely that the TLS protocol will be one of the most important security protocols for the Internet. This is particularly true for the HTTP and the WWW. It is, however, also true for other applications (protocols) layered on top of TCP. For example, one can reasonably expect that future releases of software packages for Telnet, FTP, SMTP, POP3, and IMAP4 will implement and support the TLS protocol as well.

The big advantage of SSL/TLS is simplicity and wide deployment. There are, however, also two disadvantages that should be considered with care:

1. Both the SSL and the TLS protocols are layered on top of TCP. They neither address nor meet the security requirements of applications and application protocols that are layered on UDP. Unfortunately, there is an increasingly large number of applications and application protocols layered on UDP (e.g., protocols for real-time or multicast communications). For all these applications and application protocols, the SSL and the TLS protocols do not provide a viable solution. There are at least two conclusions one can draw from this situation:

   • There is room for further research to address the question of how to secure UDP-based applications on the transport layer (e.g., a preliminary study is done in [22]).

   • There is room for security protocols that operate either below or above the transport layer. This is the reason why Part III includes other chapters on Internet and application layer security.

   The second conclusion is particularly important as it counters the argument that all other security protocols have become obsolete with the wide deployment of SSL/TLS.

2. The SSL and TLS protocols work poorly with application gateways in general, and application-level gateways (i.e., proxy servers) in particular. Note that both protocols have been specifically designed to provide end-to-end security between a client and a server, and to protect against man-in-the-middle attacks accordingly. Consequently, these protocols cannot be proxied in the traditional sense (because the protocols consider a proxy server to be a man-in-the-middle). Sometimes, it is possible to use an SSL gateway. In other situations, however, the secure connection must be end-to-end and cannot be broken by an intermediary. In these situations, there are several strategies to solve (or circumvent) the problem:

   • The simple solution is to use a packet filter instead of an application-level gateway. The packet filter can be configured to allow all traffic to and from a specific port (e.g., port number 443 for HTTPS).

   • A more complicated solution is to use a circuit-level gateway (e.g., SOCKS server) to relay the data traffic that is secured using the transport layer security protocol. In this case, the client is authenticated by the circuit-level gateway on the server's behalf.

   • Finally, still another solution is to use a special tunneling protocol, such as the one we have discussed in the contect of HTTP tunneling. In this case, the client is authenticated directly by the server (contrary to the use of a circuit-level gateway).

Obviously, the use of a packet filter instead of application-level gateways is dangerous, as the trusted port numbers can always be used for applications that are not secured using SSL or TLS. If all that is needed are TCP and UDP restrictions based on client and server IP addresses, SOCKS works fine. However, most proxy servers work at the application level and have the ability to understand header information related to the application protocol as well. Under these circumstances, the use of a special tunneling protocol seems to be advantageous.

In [1] and the first edition of this book, the problem of using SSL- and TLS-enabled software with limited cryptographic strength is also addressed. Due to the liberalized U.S. export controls, this problem has become obsolete in most parts of the world. Consequently, we are not going to repeat the discussion in this edition of the book.