Transport Layer Security (TLS) and Secure Socket Layer (SSL) (Building Internet Firewalls)

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:

Strong public key authentication without the need for a globally deployed public key infrastructure.
Reasonable performance with the large number of short connections made necessary by the stateless nature of HTTP. State associated with SSL can be maintained, at the server's discretion, across a sequence of HTTP connections.
The ability for clients to remain anonymous while requiring server authentication.

Like most network protocols, SSL has undergone a number of revisions. The commonly found versions of SSL are version 2 and version 3. There are known problems with the cryptography in version 2. The cryptography used in SSL version 3 contains some significant differences from its predecessor and is considered to be free of the previous version's cryptographic weaknesses. SSL version 3 also provides a clean way to use new versions of the protocol for forward compatibility. Unless otherwise noted, this discussion refers to SSL version 3; we suggest that you avoid using SSL version 2.

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.

The TLS and SSL Protocols

The 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:

The client and server negotiate encryption and integrity protection algorithms.
The identity of the server a client is connecting to is always verified, and this identity check is performed before the optional client user authentication information is sent.
The key exchange algorithms that are used prevent man-in-the-middle attacks.
At the end of the key exchange is a checksum exchange that will detect any tampering with algorithm negotiation.
The server can check the identity of a client in a number of ways (these mechanisms are discussed in the next section). It is also possible to have anonymous clients.
All data packets exchanged include message integrity checks. An integrity check failure causes a connection to be closed.
It is possible, using certain sets of negotiated algorithms, to use temporary authentication parameters that will be discarded after a configurable time period to prevent recorded sessions from being decrypted at a later time.

Cryptography in TLS and SSL

TLS 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:

Different algorithms have different capabilities; supporting multiple ones allows an application to choose one particularly suited to the kind of data and transaction patterns that it uses.
There is frequently a trade-off between strength and speed; supporting multiple different algorithms allows applications to use faster but weaker methods when security is less important.
As time goes by, people find ways to break algorithms that were previously considered secure; supporting a range allows applications to stop using algorithms that are no longer considered secure.

The TLS protocol defines sets of algorithms that can be used together. There is only one algorithm suite that an application must implement in order to be called a TLS compliant application. Even then, if a standard for the application prevents it from using this base algorithm suite, it may implement a different one and still be called TLS compliant. The required algorithm suite is a Diffie-Hellman key exchange authenticated with the Digital Signature Standard (DSS) with triple DES used in cipher block-chaining mode with SHA cryptographic hashes. The most important thing to know about this string of cryptographic terms is that at this time, this algorithm suite provides strong encryption and authentication suitable for protecting sensitive information. For more information about specific cryptographic algorithms and key lengths, see Appendix C, "Cryptography".

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.

Use of TLS and SSL by Other Protocols

In 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.

Packet Filtering Characteristics of TLS and SSL

Neither 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 "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.

Proxying Characteristics of TLS and SSL

Because 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.

Network Address Translation Characteristics of TLS and SSL

TLS 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.

Summary of Recommendations for TLS and SSL

TLS and SSL version 3 are good choices for adding end-to-end protection to applications.
Use TLS and SSL version 3 to protect against eavesdropping, session hijacking, and Trojan servers.
Use TLS or SSL version 3 rather than SSL version 2. TLS should be preferred over SSL version 3.
When evaluating programs that use TLS or SSL to add protection to existing protocols, verify that the transition to a protected connection occurs before confidential data is exchanged. Ideally any higher-level protocol negotiation should be completely restarted once protection has been established.

Previous	Up	Next
ToolTalk	Index	The Generic Security Services API