14.7. Transport Layer Security (TLS) and Secure Socket Layer (SSL)The Secure Socket Layer (SSL) was designed in 1993 by Netscape to provide end-to-end encryption, integrity protection, and server authentication for the Web. The security services libraries that were available at the time didn't provide certain features that were needed for the Web:
The SSL protocol is owned by Netscape (and they own a U.S. patent relating to SSL), but they approached the IETF to create an Internet standard. An IETF protocol definition, RFC 2246, is in the process of becoming an Internet standard. The protocol is based very heavily on SSL version 3 and is called Transport Layer Security (TLS). Both TLS and SSL use exactly the same protocol greeting and version extensibility mechanism. This allows servers to be migrated from supporting SSL to TLS, and provisions have been made so that services can be created that support both SSL version 3 and TLS. Netscape has granted a royalty-free license for the SSL patent for any applications that use TLS as part of an IETF standard protocol.
14.7.1. The TLS and SSL ProtocolsThe TLS and SSL protocols provide server and client authentication, end-to-end encryption, and integrity protection. They also allow a client to reconnect to a server it has already used without having to reauthenticate or negotiate new session keys, as long as the new connection is made shortly after the old one is closed down.
The security of TLS and SSL does not come purely from the fact that they use a specific encryption algorithm, cryptographic hash, or public key cryptography, but from the way the algorithms are used. The important characteristics of a secure private communication session are discussed in Appendix C, "Cryptography".
Both TLS and SSL meet the characteristics for providing a secure private communication session because:
14.7.2. Cryptography in TLS and SSLTLS and SSL do not depend on a single algorithm for each of the following: generating keys, encrypting data, or performing authentication. Instead, they can use a range of different algorithms. Not all combinations of algorithms are valid, and both TLS and SSL define suites of algorithms that should be used together. This flexibility provides a number of advantages:
Some algorithm suites use public key cryptography which, depending on the application, may require the use of additional network services (such as LDAP for verifying digital certificates) in order to perform server or client authentication.
TLS allows clients to be authenticated using either DSS or RSA public key cryptography. If clients wish to use other forms of authentication, such as a token card or a password, they must authenticate with the server anonymously, and then the application must negotiate to perform the additional authentication. This is the method which a web browser using TLS or SSL uses to perform HTTP basic authentication.
14.7.3. Use of TLS and SSL by Other ProtocolsIn order for TLS and SSL to be useful, they have to be used in conjunction with some higher-level protocol that actually exchanges data between applications. In some cases, this is done by integrating them into new protocols; for instance, version 2 of the Secure Shell (SSH) protocol uses TLS. However, in other situations it's useful to add TLS or SSL to an existing protocol. There are two basic mechanisms for doing this. One way is to use a new port number for the combination of the old protocol and the encrypting protocol; this is the way SSL and HTTP were originally integrated to create HTTPS. The other common way of integrating TLS or SSL into an existing protocol is to add a command to the protocol that starts up an encrypted session over the existing port; this is the approach taken by ESMTP when using the STARTTLS extension.
Neither of these approaches is perfect. Using a new port number is relatively easy to implement (you don't have to change command parsers) and allows a firewall to easily distinguish between protected and unprotected versions of the protocol (so that you can require the use of TLS, for instance). However, it uses up port numbers (and there are only 1024 in the reserved range to be allocated), and it requires changing firewall configurations to permit TLS-protected connections.
Adding a new command to start up a TLS connection makes more efficient use of port numbers and increases the chances that the upgraded protocol will work through firewalls (it may still be denied by an intelligent proxy that's watching the commands that are used). However, it's harder to implement. In particular, it's hard to make sure that no important data is exchanged before TLS is started up. Furthermore, it's critical for programmers to be cautious about failure conditions. A server or client that supports TLS needs to fail gracefully when talking to one that doesn't. However, if both the server and the client support TLS, it should not be possible for an attacker to force them to converse unprotected by interfering with the negotiation to use TLS.
In addition, once a protocol has upgraded to using TLS, it should restart all protocol negotiation from the beginning. Any information from the unprotected protocol could have been modified by an attacker and cannot be trusted.
14.7.4. Packet Filtering Characteristics of TLS and SSLNeither TLS nor SSL is associated with an assigned port, although there are a number of ports assigned to specific higher-level protocols running over one or the other. We list these ports along with any other ports assigned to the higher-level protocols (for instance, we list the port assigned to IMAP over SSL in the section on packet filtering characteristics of IMAP in Chapter 16, "Electronic Mail and News"). You will sometimes see port 443 shown as assigned to SSL, but in fact, it is assigned to HTTP over SSL.
TLS and SSL connections will always be straightforward TCP connections, but that does not prevent higher-level protocols that use them from also using other connections or protocols. Because of the end-to-end encryption, it is impossible to do intelligent packet filtering on TLS and SSL connections; there is no way for a packet filter to enforce restrictions on what higher-level protocols are being run, for instance.
14.7.5. Proxying Characteristics of TLS and SSLBecause TLS and SSL use straightforward TCP connections, they work well with generic proxies. Proxying provides very little additional protection with TLS and SSL, because there is no way for a proxy to see the content of packets to do intelligent logging, control, or content filtering; a proxy can only control where connections are made.
14.7.6. Network Address Translation Characteristics of TLS and SSLTLS and SSL will work well with network address translation. However, the end-to-end encryption will prevent the network address translation system from intercepting embedded addresses. Higher-level protocols that depend on having correct address or hostname information in their data will not work, and it will not be possible for the network address translation system to protect you from inadvertently releasing information about your internal network configuration.
14.7.7. Summary of Recommendations for TLS and SSL
Copyright © 2002 O'Reilly & Associates. All rights reserved.